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