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. 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
