On Fri, Mar 17, 2017 at 7:58 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> 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. With regard to the 2D and 3D GPU case, it seems to me that a good example use case would be where the 3D GPU is used in Android for all the surface generation using OpenGL and then the 2D GPU would get used to composite all those surfaces together, leaving the 3D open to work on other stuff. As I understand it, the 2D GPU is much faster at 2D compositing than the 3D GPU would be, (not to mention less power hungry.) > > Regards, > Lucas > > _______________________________________________ > etnaviv mailing list > etnaviv@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/etnaviv _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
