On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote: > On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > > On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: > >> On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > >> > On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > >> >> Hello everyone, > >> >> > >> >> to allow concurrent buffer access by different engines beyond the multiple > >> >> readers/single writer model that we currently use in radeon and other > >> >> drivers we need some kind of synchonization object exposed to userspace. > >> >> > >> >> My initial patch set for this used (or rather abused) zero sized GEM buffers > >> >> as fence handles. This is obviously isn't the best way of doing this (to > >> >> much overhead, rather ugly etc...), Jerome commented on this accordingly. > >> >> > >> >> So what should a driver expose instead? Android sync points? Something else? > >> > > >> > I think actually exposing the struct fence objects as a fd, using android > >> > syncpts (or at least something compatible to it) is the way to go. Problem > >> > is that it's super-hard to get the android guys out of hiding for this :( > >> > > >> > Adding a bunch of people in the hopes that something sticks. > >> > >> More people. > > > > Just to re-iterate, exposing such thing while still using command stream > > ioctl that use implicit synchronization is a waste and you can only get > > the lowest common denominator which is implicit synchronization. So i do > > not see the point of such api if you are not also adding a new cs ioctl > > with explicit contract that it does not do any kind of synchronization > > (it could be almost the exact same code modulo the do not wait for > > previous cmd to complete). > > Our thinking was to allow explicit sync from a single process, but > implicitly sync between processes. This is a BIG NAK if you are using the same ioctl as it would mean you are changing userspace API, well at least userspace expectation. Adding a new cs flag might do the trick but it should not be about inter-process, or any thing special, it's just implicit sync or no synchronization. Converting userspace is not that much of a big deal either, it can be broken into several step. Like mesa use explicit synchronization all time but ddx use implicit. Cheers, Jérôme > > Alex > > > > > Also one thing that the Android sync point does not have, AFAICT, is a > > way to schedule synchronization as part of a cs ioctl so cpu never have > > to be involve for cmd stream that deal only one gpu (assuming the driver > > and hw can do such trick). > > > > Cheers, > > Jérôme > > > >> -Daniel > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
