[PATCH 1/3] drm/etnaviv: submit support for in-fences

[Russell King - ARM Linux]

On Fri, Mar 17, 2017 at 03:58:27PM +0100, Lucas Stach wrote:
> Am Freitag, den 17.03.2017, 14:42 +0000 schrieb Russell King - ARM
> Linux:
> > On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
> > > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
> > > > Hi Gustavo,
> > > > 
> > > > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> > > > [...]
> > > > > I was thinking on some function that would iterate over all fences in
> > > > > the fence_array and check their context. The if we find our own gpu
> > > > > context in there we fail the submit.
> > > > 
> > > > Why would we have to fail if somebody feeds us our own fences? Wouldn't
> > > > it be enough to just wait if there are foreign fences in the array?
> > > 
> > > Yes, skipping the wait if all fences are from our own context is an
> > > optimization and it's certainly not an issue if someone feeds us our own
> > > fences.
> > 
> > Are you sure about that - what if we have two GPUs, a 2D and 3D GPU,
> > and we're fed an etnaviv fence for one GPU when submitting to the
> > other GPU.
> > 
> > So we do end up being fed our own fences, and we have to respect them
> > otherwise we lose inter-GPU synchronisation, and that will break
> > existing userspace.
> > 
> The etnaviv GPUs, while being on the same DRM device, have distinct
> fence contexts. So the 3D GPU will consider a fence from the 2D GPU as
> foreign and properly wait on it.
> 
> It's only when we get an in fence that has been generated as an out
> fence by one (or multiple) submits to the same GPU, that we are able to
> skip the wait and enqueue the command without waiting for the fence to
> signal.

Sounds fine then.  Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.