2010-01-21 15:29:14 +08:00
|
|
|
<html>
|
|
|
|
|
|
|
|
<title>Mesa EGL</title>
|
|
|
|
|
|
|
|
<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
|
|
|
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
<h1>Mesa EGL</h1>
|
|
|
|
|
|
|
|
<p>The current version of EGL in Mesa implements EGL 1.4. More information
|
|
|
|
about EGL can be found at
|
2010-01-21 08:13:32 -07:00
|
|
|
<a href="http://www.khronos.org/egl/" target="_parent">
|
|
|
|
http://www.khronos.org/egl/</a>.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<p>The Mesa's implementation of EGL uses a driver architecture. The main
|
|
|
|
library (<code>libEGL</code>) is window system neutral. It provides the EGL
|
|
|
|
API entry points and helper functions for use by the drivers. Drivers are
|
|
|
|
dynamically loaded by the main library and most of the EGL API calls are
|
|
|
|
directly dispatched to the drivers.</p>
|
|
|
|
|
|
|
|
<p>The driver in use decides the window system to support. For drivers that
|
|
|
|
support hardware rendering, there are usually multiple drivers supporting the
|
|
|
|
same window system. Each one of of them supports a certain range of graphics
|
|
|
|
cards.</p>
|
|
|
|
|
|
|
|
<h2>Build EGL</h2>
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
<li>
|
2008-06-13 09:50:43 -05:00
|
|
|
<p>Run <code>configure</code> with the desired state trackers and enable
|
2010-01-21 15:29:14 +08:00
|
|
|
the Gallium driver for your hardware. For example</p>
|
|
|
|
|
|
|
|
<pre>
|
2010-05-07 14:13:08 +08:00
|
|
|
$ ./configure --enable-gles-overlay --with-state-trackers=egl,vega --enable-gallium-{swrast,intel}
|
2010-01-21 15:29:14 +08:00
|
|
|
</pre>
|
|
|
|
|
2010-05-07 14:13:08 +08:00
|
|
|
<p>The main library and OpenGL is enabled by default. The first option enables
|
|
|
|
<a href="opengles.html">OpenGL ES 1.x and 2.x</a>. The <code>egl</code> state
|
2010-01-21 15:29:14 +08:00
|
|
|
tracker is needed by a number of EGL drivers. EGL drivers will be covered
|
2010-05-07 14:13:08 +08:00
|
|
|
later. The <a href="openvg.html">vega state tracker</a> provides OpenVG
|
2010-01-21 15:29:14 +08:00
|
|
|
1.x.</p>
|
|
|
|
</li>
|
|
|
|
|
|
|
|
<li>Build and install Mesa as usual.</li>
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
<p>In the given example, it will build and install <code>libEGL</code>,
|
2010-05-07 14:13:08 +08:00
|
|
|
<code>libGL</code>, <code>libGLESv1_CM</code>, <code>libGLESv2</code>,
|
|
|
|
<code>libOpenVG</code>, and one or more EGL drivers.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<h3>Configure Options</h3>
|
|
|
|
|
|
|
|
<p>There are several options that control the build of EGL at configuration
|
|
|
|
time</p>
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
<li><code>--enable-egl</code>
|
|
|
|
|
|
|
|
<p>By default, EGL is enabled. When disabled, the main library and the drivers
|
|
|
|
will not be built.</p>
|
|
|
|
|
|
|
|
</li>
|
|
|
|
|
2010-01-26 10:54:45 +08:00
|
|
|
<li><code>--with-egl-driver-dir</code>
|
|
|
|
|
|
|
|
<p>The directory EGL drivers should be installed to. If not specified, EGL
|
|
|
|
drivers will be installed to <code>${libdir}/egl</code>.</p>
|
|
|
|
|
|
|
|
</li>
|
|
|
|
|
2010-06-17 16:07:46 +08:00
|
|
|
<li><code>--with-egl-platforms</code>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
2010-06-17 16:07:46 +08:00
|
|
|
<p>List the native platform window system(s) to support. It is by default
|
|
|
|
<code>x11</code>, which supports the X Window System. Its argument is a comma
|
|
|
|
separated string like, for example, <code>--with-egl-platforms=x11,kms</code>.
|
|
|
|
Because an EGL driver decides which window system to support, this example will
|
|
|
|
enable two (sets of) EGL drivers. One supports the X window system and the
|
|
|
|
other supports bare KMS (kernel modesetting).</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
2010-06-17 16:07:46 +08:00
|
|
|
<p>The available platforms are <code>x11</code>, <code>kms</code>,
|
|
|
|
<code>fbdev</code>, and <code>gdi</code>. The <code>gdi</code> platform can
|
2010-06-11 12:47:14 +08:00
|
|
|
only be built with SCons.</p>
|
|
|
|
|
2010-01-21 15:29:14 +08:00
|
|
|
</li>
|
|
|
|
|
|
|
|
<li><code>--with-state-trackers</code>
|
|
|
|
|
|
|
|
<p>The argument is a comma separated string. It is usually used to specify the
|
2010-05-07 14:13:08 +08:00
|
|
|
rendering APIs, such as OpenVG, to build. But it should be noted that a number
|
|
|
|
of EGL drivers depend on the <code>egl</code> state tracker. They will
|
|
|
|
<em>not</em> be built without the <code>egl</code> state tracker.</p>
|
|
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
<li><code>--enable-gles-overlay</code>
|
|
|
|
|
|
|
|
<p>OpenGL and OpenGL ES are not controlled by
|
|
|
|
<code>--with-state-trackers</code>. OpenGL is always built. To build OpenGL
|
|
|
|
ES, this option must be explicitly given.</p>
|
|
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
|
|
|
|
|
|
|
|
<p>Unlike <code>--enable-gles-overlay</code>, which builds one library for each
|
|
|
|
rendering API, these options enable OpenGL ES support in OpenGL. The result is
|
|
|
|
one big library that supports multiple APIs. This is used by DRI drivers and
|
|
|
|
<code>egl_dri2</code> EGL driver.
|
2010-01-21 15:29:14 +08:00
|
|
|
|
2010-01-22 15:51:51 +08:00
|
|
|
</li>
|
|
|
|
|
|
|
|
<li><code>--enable-gallium-swrast</code>
|
|
|
|
|
|
|
|
<p>This option is not specific to EGL. But if there is no driver for your
|
|
|
|
hardware, or you are experiencing problems with the hardware driver, you can
|
|
|
|
enable the swrast DRM driver. It is a dummy driver and EGL will fallback to
|
|
|
|
software rendering automatically.</p>
|
|
|
|
|
2010-01-21 15:29:14 +08:00
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<h2>Use EGL</h2>
|
|
|
|
|
2010-06-11 12:47:14 +08:00
|
|
|
<h3>Demos</h3>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
2010-06-11 12:47:14 +08:00
|
|
|
<p>There are demos for the client APIs supported by EGL. They can be found in
|
|
|
|
mesa/demos repository.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<h3>Environment Variables</h3>
|
|
|
|
|
|
|
|
<p>There are several environment variables that control the behavior of EGL at
|
|
|
|
runtime</p>
|
|
|
|
|
|
|
|
<ul>
|
2010-02-02 15:34:55 +08:00
|
|
|
<li><code>EGL_DRIVERS_PATH</code>
|
|
|
|
|
|
|
|
<p>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
|
2010-02-02 16:47:53 +08:00
|
|
|
addition to the default directory. This variable is ignored for setuid/setgid
|
|
|
|
binaries.</p>
|
2010-02-02 15:34:55 +08:00
|
|
|
|
|
|
|
</li>
|
|
|
|
|
2010-01-21 15:29:14 +08:00
|
|
|
<li><code>EGL_DRIVER</code>
|
|
|
|
|
2010-02-02 11:05:19 +08:00
|
|
|
<p>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
|
2010-02-02 16:47:53 +08:00
|
|
|
specific driver. This variable is ignored for setuid/setgid binaries.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
</li>
|
|
|
|
|
2010-06-17 16:07:46 +08:00
|
|
|
<li><code>EGL_PLATFORM</code>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<p>When <code>EGL_DRIVER</code> is not set, the main library loads <em>all</em>
|
2010-06-17 16:07:46 +08:00
|
|
|
EGL drivers that support a certain window system. <code>EGL_PLATFORM</code>
|
|
|
|
can be used to specify the window system and the valid values are, for example,
|
2010-01-21 15:29:14 +08:00
|
|
|
<code>x11</code> or <code>kms</code>. When the variable is not set, the main
|
|
|
|
library defaults the value to the first window system listed in
|
2010-06-17 16:07:46 +08:00
|
|
|
<code>--with-egl-platforms</code> at configuration time.
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
<li><code>EGL_LOG_LEVEL</code>
|
|
|
|
|
|
|
|
<p>This changes the log level of the main library and the drivers. The valid
|
|
|
|
values are: <code>debug</code>, <code>info</code>, <code>warning</code>, and
|
|
|
|
<code>fatal</code>.</p>
|
|
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
<li><code>EGL_SOFTWARE</code>
|
|
|
|
|
|
|
|
<p>For drivers that support both hardware and software rendering, setting this
|
|
|
|
variable to true forces the use of software rendering.</p>
|
|
|
|
|
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<h2>EGL Drivers</h2>
|
|
|
|
|
|
|
|
<p>There are two categories of EGL drivers: Gallium and classic.</p>
|
|
|
|
|
2010-06-11 12:47:14 +08:00
|
|
|
<p>Gallium EGL drivers supports all rendering APIs specified in EGL 1.4. These
|
|
|
|
drivers depend on the <code>egl</code> state tracker to build. The available
|
|
|
|
drivers are</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<ul>
|
|
|
|
<li><code>egl_<dpy>_i915</code></li>
|
|
|
|
<li><code>egl_<dpy>_i965</code></li>
|
|
|
|
<li><code>egl_<dpy>_nouveau</code></li>
|
2010-06-11 12:47:14 +08:00
|
|
|
<li><code>egl_<dpy>_radeon</code></li>
|
2010-01-22 15:51:51 +08:00
|
|
|
<li><code>egl_<dpy>_swrast</code></li>
|
2010-01-21 15:29:14 +08:00
|
|
|
<li><code>egl_<dpy>_vmwgfx</code></li>
|
|
|
|
</ul>
|
|
|
|
|
2010-06-17 16:07:46 +08:00
|
|
|
<p><code><dpy></code> is given by <code>--with-egl-platforms</code> at
|
2010-06-11 12:47:14 +08:00
|
|
|
configuration time. There is usually one EGL driver for each combination of
|
2010-06-17 16:07:46 +08:00
|
|
|
the platforms listed and the pipe drivers enabled. When the platform is pure
|
2010-06-11 12:47:14 +08:00
|
|
|
software or pure hardware, non-working combinations will not be built.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
2010-06-11 12:47:14 +08:00
|
|
|
<p>Classic EGL drivers, on the other hand, support only a subset of the
|
|
|
|
available rendering APIs. They can be found under
|
|
|
|
<code>src/egl/drivers/</code>. There are 3 of them</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<ul>
|
|
|
|
<li><code>egl_glx</code>
|
|
|
|
|
|
|
|
<p>This driver provides a wrapper to GLX. It uses exclusively GLX to implement
|
|
|
|
the EGL API. It supports both direct and indirect rendering when the GLX does.
|
|
|
|
It is accelerated when the GLX is. As such, it cannot provide functions that
|
|
|
|
is not available in GLX or GLX extensions.</p>
|
|
|
|
</li>
|
|
|
|
|
2010-02-05 11:46:28 +08:00
|
|
|
<li><code>egl_dri2</code>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
<p>This driver supports the X Window System as its window system. It functions
|
2010-02-05 11:46:28 +08:00
|
|
|
as a DRI2 driver loader. Unlike <code>egl_glx</code>, it has no dependency on
|
|
|
|
<code>libGL</code>. It talks to the X server directly using DRI2 protocol.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
</li>
|
|
|
|
<li><code>egl_dri</code>
|
|
|
|
|
|
|
|
<p>This driver lacks maintenance and does <em>not</em> build. It is similiar
|
2010-02-05 11:46:28 +08:00
|
|
|
to <code>egl_dri2</code> in that it functions as a DRI(1) driver loader. But
|
|
|
|
unlike <code>egl_dri2</code>, 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 <code>egl_dri2</code>.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<p>To use the classic drivers, one must manually set <code>EGL_DRIVER</code> at
|
|
|
|
runtime.</p>
|
|
|
|
|
|
|
|
<h2>Developers</h2>
|
|
|
|
|
2010-01-27 23:18:22 +08:00
|
|
|
<p>The sources of the main library and the classic drivers can be found at
|
2010-01-22 16:31:43 +08:00
|
|
|
<code>src/egl/</code>. The sources of the <code>egl</code> state tracker can
|
2010-01-27 23:18:22 +08:00
|
|
|
be found at <code>src/gallium/state_trackers/egl/</code>.</p>
|
|
|
|
|
|
|
|
<p>The suggested way to learn to write a EGL driver is to see how other drivers
|
|
|
|
are written. <code>egl_glx</code> should be a good reference. It works in any
|
|
|
|
environment that has GLX support, and it is simpler than most drivers.</p>
|
|
|
|
|
|
|
|
<h3>Lifetime of Display Resources</h3>
|
|
|
|
|
|
|
|
<p>Contexts and surfaces are examples of display resources. They might live
|
|
|
|
longer than the display that creates them.</p>
|
|
|
|
|
|
|
|
<p>In EGL, when a display is terminated through <code>eglTerminate</code>, all
|
|
|
|
display resources should be destroyed. Similarly, when a thread is released
|
|
|
|
throught <code>eglReleaseThread</code>, all current display resources should be
|
|
|
|
released. Another way to destory or release resources is through functions
|
|
|
|
such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p>
|
|
|
|
|
|
|
|
<p>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
|
|
|
|
<code>eglIs<Resource>Bound</code> 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.</p>
|
|
|
|
|
|
|
|
<p>The main library will mark destroyed current resources as unlinked. In a
|
|
|
|
driver's <code>MakeCurrent</code> callback,
|
|
|
|
<code>eglIs<Resource>Linked</code> 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 <code>MakeCurrent</code> might be called with an
|
|
|
|
uninitialized display.</p>
|
|
|
|
|
|
|
|
<p>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.</p>
|
2010-01-21 15:29:14 +08:00
|
|
|
|
2010-02-05 12:44:45 +08:00
|
|
|
<h3><code>EGL_RENDER_BUFFER</code></h3>
|
|
|
|
|
|
|
|
<p>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 <code>EGL_RENDER_BUFFER</code> set to
|
|
|
|
<code>EGL_SINGLE_BUFFER</code>; If the same context is later bound to a
|
|
|
|
surface with <code>EGL_RENDER_BUFFER</code> set to
|
|
|
|
<code>EGL_BACK_BUFFER</code>, 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.</p>
|
|
|
|
|
|
|
|
<p>For pbuffer surfaces, the render buffer is always
|
|
|
|
<code>EGL_BACK_BUFFER</code>. And for pixmap surfaces, the render buffer is
|
|
|
|
always <code>EGL_SINGLE_BUFFER</code>. Unlike window surfaces, EGL spec
|
|
|
|
requires their <code>EGL_RENDER_BUFFER</code> values to be honored. As a
|
|
|
|
result, a driver should never set <code>EGL_PIXMAP_BIT</code> or
|
|
|
|
<code>EGL_PBUFFER_BIT</code> bits of a config if the contexts created with the
|
|
|
|
config won't be able to honor the <code>EGL_RENDER_BUFFER</code> of pixmap or
|
|
|
|
pbuffer surfaces.</p>
|
|
|
|
|
|
|
|
<p>It should also be noted that pixmap and pbuffer surfaces are assumed to be
|
|
|
|
single-buffered, in that <code>eglSwapBuffers</code> 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.</p>
|
|
|
|
|
|
|
|
<p>There is no defined behavior as to, for example, how
|
|
|
|
<code>glDrawBuffer</code> interacts with <code>EGL_RENDER_BUFFER</code>. 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.</p>
|
|
|
|
|
2010-02-17 19:52:29 +08:00
|
|
|
<h3><code>EGLDisplay</code> Mutex</h3>
|
|
|
|
|
|
|
|
The <code>EGLDisplay</code> will be locked before calling any of the dispatch
|
|
|
|
functions (well, except for GetProcAddress which does not take an
|
|
|
|
<code>EGLDisplay</code>). 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 <code>EGLDisplay</code> without going through the EGL APIs, the driver
|
|
|
|
should as well lock the display before using it.
|
|
|
|
|
2010-01-21 15:29:14 +08:00
|
|
|
<h3>TODOs</h3>
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
<li>Pass the conformance tests</li>
|
2010-06-17 16:07:46 +08:00
|
|
|
<li>Better automatic driver selection: <code>EGL_PLATFORM</code> loads all
|
2010-01-21 15:29:14 +08:00
|
|
|
drivers and might eat too much memory.</li>
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
</body>
|
|
|
|
</html>
|