GitLab

This MR enables OES_EGL_sync for big-GL (non-ES) contexts. The use-case is for OpenGL core profile contexts to be able to use 'explicit fencing' via EGL_ANDROID_native_fence_sync, i.e. to be able to import/export sync FDs in/from EGL sync objects.

This MR follows OES_EGL_image as a precedent, where we already have an OES extension made available to GL core contexts. Here, one use case is to render into DMABUF-exported gbm_bo via a GL framebuffer -> GL texture -> EGL image -> gbm -> DMABUF chain. Enabling OES_EGL_sync supports that use case, where synchronization primitives can be sent along the DMABUF FDs, and used as explicit fences for atomic KMS operations.

There is recent KMS sample code (kms-quads) that demonstrates use of atomic KMS explicit fencing via OES_EGL_sync with both GL Core and GLES, along with OES_EGL_image. This can be used to test this MR (GL core support needs to be enabled via Meson option -Dglcore=true).

So far, in this MR I enabled OES_EGL_sync in i965 and the Gallium state tracker. I tested this with an Intel SKL based system and a Tonga AMD device (using amdgpu), both on 4.19. Both seemed to work well.

Please note that I am not very familiar with the Mesa code basis, or the lower-level driver code, and followed a rather naive approach of enabling OES_EGL_sync in the obvious places. This MR is completely ignorant to any possible side-effects this might have on a driver level. I would therefore be very grateful for early feedback / guidance on this approach, and what might be reasons to not follow this route. I do believe that enabling explicit fencing for OpenGL core profile contexts is useful in general, so it would be great if there was a way to possibly land this in Mesa master.