Re: Question on UAPI for fences

From: Jerome Glisse <j.glisse@gmail.com>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: "Maarten Lankhorst" <m.b.lankhorst@gmail.com>,
	"Zach Pfeffer" <zpfeffer@audience.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	gpudriverdevsupport@amd.com,
	"Christian König" <christian.koenig@amd.com>,
	"John Harrison" <john.c.harrison@intel.com>
Subject: Re: Question on UAPI for fences
Date: Fri, 12 Sep 2014 11:33:47 -0400	[thread overview]
Message-ID: <20140912153346.GB4139@gmail.com> (raw)
In-Reply-To: <CADnq5_N1xPr+zhTGKA4HpQcJffTAS-NcVidWPE31j45H_bVRKw@mail.gmail.com>

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

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@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel