X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;ds=sidebyside;f=docs%2Fegl.html;h=82cc06600bd69ea5a7e4eee092809713f63aff19;hb=ccd78fed880c4c8f1fccf1d10fc46442fa146359;hp=305e5f6eab71c5222ef17566257af16d0b6fa263;hpb=a6342afe502fe52190be4d97df58eb3406b70246;p=mesa.git diff --git a/docs/egl.html b/docs/egl.html index 305e5f6eab7..82cc06600bd 100644 --- a/docs/egl.html +++ b/docs/egl.html @@ -126,10 +126,21 @@ test your build. For example,
runtimeEGL_DRIVERS_PATH
+
+By default, the main library will look for drivers in the directory where +the drivers are installed to. This variable specifies a list of +colon-separated directories where the main library will look for drivers, in +addition to the default directory. This variable is ignored for setuid/setgid +binaries.
+ +EGL_DRIVER
-This variable forces the specified EGL driver to be loaded. It comes in -handy when one wants to test a specific driver.
+This variable specifies a full path to an EGL driver and it forces the +specified EGL driver to be loaded. It comes in handy when one wants to test a +specific driver. This variable is ignored for setuid/setgid binaries.
egl_xdri
+egl_dri2
This driver supports the X Window System as its window system. It functions
-as a DRI driver loader and can load DRI/DRI2/DRISW drivers. Unlike
-egl_glx
, it has no dependency on libGL
. It talks to
-the X server directly using DRI or DRI2 protocols. It also talks minimal GLX
-protocol for things like available visuals or fbconfigs. With direct access to
-the DRI drivers, it has the potential to support more EGL functions that are
-not possible with egl_glx
.
egl_glx
, it has no dependency on
+libGL
. It talks to the X server directly using DRI2 protocol.
egl_dri
This driver lacks maintenance and does not build. It is similiar
-to egl_xdri
in that it functions as a DRI driver loader. But
-unlike egl_xdri
, it supports Linux framebuffer devices as its
-window system and supports EGL_MESA_screen_surface extension. It loads only
-DRI1 drivers. As DRI1 drivers is phasing out, it might be better to rewrite
-the driver to support KMS and DRI2.
egl_dri2
in that it functions as a DRI(1) driver loader. But
+unlike egl_dri2
, it supports Linux framebuffer devices as its
+window system and supports EGL_MESA_screen_surface extension. As DRI1 drivers
+are phasing out, it might eventually be replaced by egl_dri2
.
The sources of the main library and the classic drivers can be found at
src/egl/
. The sources of the egl
state tracker can
-be found at src/gallium/state_trackers/egl/
.
+be found at src/gallium/state_trackers/egl/
.
The suggested way to learn to write a EGL driver is to see how other drivers
+are written. egl_glx
should be a good reference. It works in any
+environment that has GLX support, and it is simpler than most drivers.
Contexts and surfaces are examples of display resources. They might live +longer than the display that creates them.
+ +In EGL, when a display is terminated through eglTerminate
, all
+display resources should be destroyed. Similarly, when a thread is released
+throught eglReleaseThread
, all current display resources should be
+released. Another way to destory or release resources is through functions
+such as eglDestroySurface
or eglMakeCurrent
.
When a resource that is current to some thread is destroyed, the resource
+should not be destroyed immediately. EGL requires the resource to live until
+it is no longer current. A driver usually calls
+eglIs<Resource>Bound
to check if a resource is bound
+(current) to any thread in the destroy callbacks. If it is still bound, the
+resource is not destroyed.
The main library will mark destroyed current resources as unlinked. In a
+driver's MakeCurrent
callback,
+eglIs<Resource>Linked
can then be called to check if a newly
+released resource is linked to a display. If it is not, the last reference to
+the resource is removed and the driver should destroy the resource. But it
+should be careful here because MakeCurrent
might be called with an
+uninitialized display.
This is the only mechanism provided by the main library to help manage the +resources. The drivers are responsible to the correct behavior as defined by +EGL.
+ +EGL_RENDER_BUFFER
In EGL, the color buffer a context should try to render to is decided by the
+binding surface. It should try to render to the front buffer if the binding
+surface has EGL_RENDER_BUFFER
set to
+EGL_SINGLE_BUFFER
; If the same context is later bound to a
+surface with EGL_RENDER_BUFFER
set to
+EGL_BACK_BUFFER
, the context should try to render to the back
+buffer. However, the context is allowed to make the final decision as to which
+color buffer it wants to or is able to render to.
For pbuffer surfaces, the render buffer is always
+EGL_BACK_BUFFER
. And for pixmap surfaces, the render buffer is
+always EGL_SINGLE_BUFFER
. Unlike window surfaces, EGL spec
+requires their EGL_RENDER_BUFFER
values to be honored. As a
+result, a driver should never set EGL_PIXMAP_BIT
or
+EGL_PBUFFER_BIT
bits of a config if the contexts created with the
+config won't be able to honor the EGL_RENDER_BUFFER
of pixmap or
+pbuffer surfaces.
It should also be noted that pixmap and pbuffer surfaces are assumed to be
+single-buffered, in that eglSwapBuffers
has no effect on them. It
+is desirable that a driver allocates a private color buffer for each pbuffer
+surface created. If the window system the driver supports has native pbuffers,
+or if the native pixmaps have more than one color buffers, the driver should
+carefully attach the native color buffers to the EGL surfaces, re-route them if
+required.
There is no defined behavior as to, for example, how
+glDrawBuffer
interacts with EGL_RENDER_BUFFER
. Right
+now, it is desired that the draw buffer in a client API be fixed for pixmap and
+pbuffer surfaces. Therefore, the driver is responsible to guarantee that the
+client API renders to the specified render buffer for pixmap and pbuffer
+surfaces.
EGLDisplay
MutexEGLDisplay
will be locked before calling any of the dispatch
+functions (well, except for GetProcAddress which does not take an
+EGLDisplay
). This guarantees that the same dispatch function will
+not be called with the sample display at the same time. If a driver has access
+to an EGLDisplay
without going through the EGL APIs, the driver
+should as well lock the display before using it.
EGL_DISPLAY
loads all
drivers and might eat too much memory.glxinit.c
and sources from src/glx/x11/