Gallium3D Drivers Prepped For EGL_ANDROID_native_fence_sync
Rob Clark has landed his code for supporting EGL_ANDROID_native_fence_sync in Mesa and his Freedreno Gallium3D driver is the first in-tree Mesa/Gallium3D driver to support the native fence FD support, even beating out the Intel driver.
For background information on this extension see this earlier article.
Rob yesterday landed the EGL changes, the Gallium support for supporting nativw fence file descriptors / EGL_ANDROID_native_fence_sync, and finally the Freedreno driver support. Support for the Intel driver and other Gallium3D drivers likely to follow in the weeks ahead.
Those wanting to learn more about this extension can visit the Khronos.org registry, "This extension enables the creation of EGL fence sync objects that are associated with a native synchronization fence object that is referenced using a file descriptor. These EGL fence sync objects have nearly identical semantics to those defined by the KHR_fence_sync extension, except that they have an additional attribute storing the file descriptor referring to the native fence object. This extension assumes the existence of a native fence synchronization object that behaves similarly to an EGL fence sync object. These native objects must have a signal status like that of an EGLSyncKHR object that indicates whether the fence has ever been signaled. Once signaled the native object's signal status may not change again."
For background information on this extension see this earlier article.
Rob yesterday landed the EGL changes, the Gallium support for supporting nativw fence file descriptors / EGL_ANDROID_native_fence_sync, and finally the Freedreno driver support. Support for the Intel driver and other Gallium3D drivers likely to follow in the weeks ahead.
Those wanting to learn more about this extension can visit the Khronos.org registry, "This extension enables the creation of EGL fence sync objects that are associated with a native synchronization fence object that is referenced using a file descriptor. These EGL fence sync objects have nearly identical semantics to those defined by the KHR_fence_sync extension, except that they have an additional attribute storing the file descriptor referring to the native fence object. This extension assumes the existence of a native fence synchronization object that behaves similarly to an EGL fence sync object. These native objects must have a signal status like that of an EGLSyncKHR object that indicates whether the fence has ever been signaled. Once signaled the native object's signal status may not change again."
Add A Comment