Question on UAPI for fences

[Alex Deucher]

On Fri, Sep 12, 2014 at 11:33 AM, Jerome Glisse <j.glisse at gmail.com> 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 at gmail.com> 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 at ffwll.ch> 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 at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel