[Mesa-dev] [EGL android: accquire fence implementation] i965: Queue the buffer with a sync fence for Android OS (v2)

[Kenneth Graunke]

On Friday, July 14, 2017 10:50:39 AM PDT Rafael Antognolli wrote:
> On Sat, Jul 15, 2017 at 01:58:19AM +0900, Tomasz Figa wrote:
> > > So, the right place to do so would be inside platform_android.c,
> > > right? And since I don't see any private struct that could store such fence
> > > there, one option would be to extend the struct dri2_egl_surface for android,
> > > adding private data there. Does that make sense?
> > 
> > I'd say these fences are not 100% Android-specific anymore. They are
> > an upstream Linux feature and can be used on other platforms as well.
> > I think wiring this properly in EGL DRI2 core would make sense,
> > especially since this is the place where the context is being
> > destroyed (platform_android doesn't handle context destruction).
> 
> OK, so I'm trying to understand what "wiring this properly in EGL DRI2 core"
> really means.
> 
> Android supports receiving a fence on its enqueue_buffer function (and some
> others), but I assume not every platform does (or wants to) do that.
> 
> So would it make sense to create a fence before calling swap_buffers,
> destroy_surface, and related functions, and storing such fence so the platform
> specific code can pass it around if needed?
> 
> And I assume that's something optional, we only do that if the DRI2 fence
> extension exists, and maybe also check for some extra flag that can be set by
> the platform?
> 
> Rafael

At some point we probably want to do explicit fencing in X with
DRI3/Present, and also Wayland.  Not sure if anything would be sharable
across the EGL android/x11/wayland platforms then.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170714/854c248f/attachment-0001.sig>