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

[Lucas Stach <l.stach@pengutronix.de>]

Am Samstag, den 18.03.2017, 15:19 +0100 schrieb Christian König:
> Am 17.03.2017 um 15:58 schrieb Lucas Stach:
> > 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.
> 
> BTW: Do you still have the needs for a GPU scheduler?
> 
> The scheduler amdgpu uses is hopefully still hardware agnostic and
> has 
> all that handling already included.
> 
> Using it can avoid blocking for foreign fences during your command 
> submission and I won't mind seeing that moved into common drm code.

Yes, it's still on my list of features to enable for etnaviv. It's just
 that other things like enabling more hardware and getting performance
up had priority over this.

I've looked at the amdgpu scheduler and I agree that it's probably the
right thing to move this out into common code and make use of it in
etnaviv.

Regards,
Lucas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel