On Fri, Sep 12, 2014 at 11:33 AM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > 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. Right, you'd have to explicitly ask for it to avoid breaking old userspace. My point was just that within a single process, it's quite easy to know exactly what you are doing and handle the synchronization yourself, while for inter-process there is an assumed implicit sync. Alex > > 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
