Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • mesa mesa
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,033
    • Issues 3,033
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 984
    • Merge requests 984
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • MesaMesa
  • mesamesa
  • Merge requests
  • !624

GL_OES_EGL_sync for GL core

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Heinrich Fink requested to merge heinrich.fink/mesa:GL_OES_EGL_sync-for-Big-GL into master Apr 10, 2019
  • Overview 18
  • Commits 4
  • Pipelines 10
  • Changes 6

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.

Edited Sep 05, 2019 by Daniel Stone
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: GL_OES_EGL_sync-for-Big-GL