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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
