EGL backends
<securetransclude src="ProtectedTemplate:ReviewsComments" params="PCO (W803) : please avoid "br""></securetransclude>{{#set:Has reviews comments=true}} <securetransclude src="ProtectedTemplate:ReviewsComments" params="PCO (W803) : maybe improve the summary by simply adding the names of possible backends"></securetransclude>{{#set:Has reviews comments=true}}
The EGL backend is the EGL low level interface to define how buffer will be allocated and how display will be done.
目录
Supported backends
To be integrated into OpenSTLinux, GPU software stack should supports DRM/GBM and Wayland backends.
The GPU userland library dynamically selects the currently running EGL backend according to the information given by the application thanks to the support of the eglGetPlatformDisplayEXT extension:
- EGL_PLATFORM_GBM_KHR (selects DRM backend based on GBM) => choice made by weston compositor
- EGL_PLATFORM_WAYLAND_KHR (selects Wayland backend) => choice made by a wayland client application
Only one of the DRM backend and Wayland backends runs at a time |
EGL focus
<securetransclude src="ProtectedTemplate:ReviewsComments" params="PCO (W803) : please add a legend for colors, use the official template maybe"></securetransclude>{{#set:Has reviews comments=true}}
DRM/GBM backend
DRM/GBM backend is based on the Graphic Buffer Management interfaced (GBM) to handle buffer/surface creation.
GBM is itself based on dmabuf DRM/KMS allocator (using DRM_IOCTL_MODE_CREATE_DUMB).
The application need to set the display mode using the KMS mode setting of the DRM/KMS protocol and then should drop the DRM master token.
So that, the DRM/GBM backend could take the DRM master token and perform EGL rendering directly on the the display selected set by the KMS mode setting (done by the application).
Wayland backend
The Wayland backend implements Wayland EGL extensions:
- eglBindWaylandDisplayWL
- eglUnbindWaylandDisplayWL
- eglQueryWaylandBufferWL
- support of EGL_WAYLAND_BUFFER_WL in eglCreateKHRImage interface.
The wayland backend is used by the egl wayland clients (means application that want to display EGL surface in a wayland windows).
This back end is responsible of allocating output buffer for the GL rendering but it is up to wayland client protocol to display it.
The Wayland client uses a wl_display (recovered by wl_display_connect) to initialize EGL.
__egl_swap_buffer uses the attached/commit/flush wayland API to display the result in a wayland window.
<securetransclude src="ProtectedTemplate:ReviewsComments" params="PCO (W803) : explanations are pretty complex, we can discuss about what we should explain and what is too complex"></securetransclude>{{#set:Has reviews comments=true}}
Wayland/Weston EGL architecture
<securetransclude src="ProtectedTemplate:ReviewsComments" params="PCO (W803) : please add a legend for colors, use the official template maybe"></securetransclude>{{#set:Has reviews comments=true}}
Wayland/Weston uses both DRM and Wayland backends.
-
Weston compositor (through the gl-renderer) relies on the DRM backend (EGL_PLATFORM_GBM_KHR) to render surfaces that could not be assigned to a plane.
- DMABUF native buffers are rendered using egl_image_create in EGL_LINUX_DMA_BUF_EXT mode (texture 0-copy path)
- Wayland buffers (wl_buffer) issued by an EGL wayland application are rendered using egl_image_create in EGL_WAYLAND_BUFFER_WL mode (texture 0-copy path.
- SHM buffers are rendered using the glImage2D interface (low performance because texture is copied)
- EGL Wayland applications rely on the Wayland backend (EGL_PLATFORM_WAYLAND_KHR) to render their 3D EGL animation/UI into a wl_surface that will be then commit to weston compositor