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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
