-<html>
-
-<title>Mesa EGL</title>
-
-<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html lang="en">
+<head>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8">
+ <title>Mesa EGL</title>
+ <link rel="stylesheet" type="text/css" href="mesa.css">
+</head>
<body>
<h1>Mesa EGL</h1>
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>
+<p>The driver in use decides the window system to support.</p>
<h2>Build EGL</h2>
<ol>
<li>
-<p>Run <code>configure</code> with the desired state trackers and enable
-the Gallium driver for your hardware. For example</p>
+<p>Run <code>configure</code> with the desired client APIs and enable
+the driver for your hardware. For example</p>
<pre>
- $ ./configure --enable-gles-overlay --with-state-trackers=egl,vega --enable-gallium-intel
+ $ ./configure --enable-gles1 --enable-gles2 \
+ --with-dri-drivers=... \
+ --with-gallium-drivers=...
</pre>
-<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
-tracker is needed by a number of EGL drivers. EGL drivers will be covered
-later. The <a href="openvg.html">vega state tracker</a> provides OpenVG
-1.x.</p>
+<p>The main library and OpenGL is enabled by default. The first two options
+above enables <a href="opengles.html">OpenGL ES 1.x and 2.x</a>. The last two
+options enables the listed classic and and Gallium drivers respectively.</p>
+
</li>
<li>Build and install Mesa as usual.</li>
</ol>
<p>In the given example, it will build and install <code>libEGL</code>,
-<code>libGL</code>, <code>libGLESv1_CM</code>, <code>libGLESv2</code>,
-<code>libOpenVG</code>, and one or more EGL drivers.</p>
+<code>libGL</code>, <code>libGLESv1_CM</code>, <code>libGLESv2</code>, and one
+or more EGL drivers.</p>
<h3>Configure Options</h3>
</li>
+<li><code>--enable-gallium-egl</code>
+
+<p>Enable the optional <code>egl_gallium</code> driver.</p>
+
+</li>
+
<li><code>--with-egl-platforms</code>
<p>List the platforms (window systems) to support. Its argument is a comma
<p>The available platforms are <code>x11</code>, <code>drm</code>,
<code>fbdev</code>, and <code>gdi</code>. The <code>gdi</code> platform can
-only be built with SCons.</p>
+only be built with SCons. Unless for special needs, the build system should
+select the right platforms automatically.</p>
</li>
-<li><code>--with-state-trackers</code>
+<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
-<p>The argument is a comma separated string. It is usually used to specify the
-rendering APIs, such as OpenVG, to build. But it is also used to specify
-<code>egl</code> state tracker that <code>egl_gallium</code> depends on.</p>
+<p>These options enable OpenGL ES support in OpenGL. The result is one big
+internal library that supports multiple APIs.</p>
</li>
-<li><code>--enable-gles-overlay</code>
+<li><code>--enable-shared-glapi</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>
+<p>By default, <code>libGL</code> has its own copy of <code>libglapi</code>.
+This options makes <code>libGL</code> use the shared <code>libglapi</code>. This
+is required if applications mix OpenGL and OpenGL ES.</p>
</li>
-<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
+<li><code>--enable-openvg</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.</p>
+<p>OpenVG must be explicitly enabled by this option.</p>
</li>
addition to the default directory. This variable is ignored for setuid/setgid
binaries.</p>
+<p>This variable is usually set to test an uninstalled build. For example, one
+may set</p>
+
+<pre>
+ $ export LD_LIBRARY_PATH=$mesa/lib
+ $ export EGL_DRIVERS_PATH=$mesa/lib/egl
+</pre>
+
+<p>to test a build without installation</p>
+
</li>
<li><code>EGL_DRIVER</code>
-<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
-specific driver. This variable is ignored for setuid/setgid binaries.</p>
-
-<p><code>egl_gallium</code> dynamically loads hardware drivers and client API
-modules found in <code>EGL_DRIVERS_PATH</code>. Thus, specifying this variable
-alone is not sufficient for <code>egl_gallium</code> for uninstalled build.</p>
+<p>This variable specifies a full path to or the name of an EGL driver. 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.</p>
</li>
<p>This variable specifies the native platform. The valid values are the same
as those for <code>--with-egl-platforms</code>. When the variable is not set,
the main library uses the first platform listed in
-<code>--with-egl-platforms</code> as the native platform</p>
+<code>--with-egl-platforms</code> as the native platform.</p>
+
+<p>Extensions like <code>EGL_MESA_drm_display</code> define new functions to
+create displays for non-native platforms. These extensions are usually used by
+applications that support non-native platforms. Setting this variable is
+probably required only for some of the demos found in mesa/demo repository.</p>
</li>
<h2>EGL Drivers</h2>
<ul>
+<li><code>egl_dri2</code>
+
+<p>This driver supports both <code>x11</code> and <code>drm</code> platforms.
+It functions as a DRI driver loader. For <code>x11</code> support, it talks to
+the X server directly using (XCB-)DRI2 protocol.</p>
+
+<p>This driver can share DRI drivers with <code>libGL</code>.</p>
+
+</li>
+
<li><code>egl_gallium</code>
<p>This driver is based on Gallium3D. It supports all rendering APIs and
hardwares supported by Gallium3D. It is the only driver that supports OpenVG.
-The supported platforms are X11, KMS, FBDEV, and GDI.</p>
+The supported platforms are X11, DRM, FBDEV, and GDI.</p>
+
+<p>This driver comes with its own hardware drivers
+(<code>pipe_<hw></code>) and client API modules
+(<code>st_<api></code>).</p>
</li>
It is accelerated when the GLX is. As such, it cannot provide functions that
is not available in GLX or GLX extensions.</p>
</li>
+</ul>
-<li><code>egl_dri2</code>
-
-<p>This driver supports the X Window System as its window system. It functions
-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>
-
-</li>
-<li><code>egl_dri</code>
+<h2>Packaging</h2>
-<p>This driver lacks maintenance and does <em>not</em> build. It is similiar
-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>
+<p>The ABI between the main library and its drivers are not stable. Nor is
+there a plan to stabilize it at the moment. Of the EGL drivers,
+<code>egl_gallium</code> has its own hardware drivers and client API modules.
+They are considered internal to <code>egl_gallium</code> and there is also no
+stable ABI between them. These should be kept in mind when packaging for
+distribution.</p>
-</li>
-</ul>
+<p>Generally, <code>egl_dri2</code> is preferred over <code>egl_gallium</code>
+when the system already has DRI drivers. As <code>egl_gallium</code> is loaded
+before <code>egl_dri2</code> when both are available, <code>egl_gallium</code>
+is disabled by default.</p>
<h2>Developers</h2>
to an <code>EGLDisplay</code> without going through the EGL APIs, the driver
should as well lock the display before using it.
-<h3>TODOs</h3>
-
-<ul>
-<li>Pass the conformance tests</li>
-<li>Reference counting in main library?</li>
-<li>Mixed use of OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0 is supported. But
-which one of <code>libGL.so</code>, <code>libGLESv1_CM.so</code>, and
-<code>libGLESv2.so</code> should an application link to? Bad things may happen
-when, say, an application is linked to <code>libGLESv2.so</code> and
-<code>libcairo</code>, which is linked to <code>libGL.so</code> instead.</li>
-
-</ul>
-
</body>
</html>
projects / mesa.git / blobdiff