<ol>
<li>
-<p>Run <code>configure</code> with the desired state trackers and and enable
+<p>Run <code>configure</code> with the desired state trackers and enable
the Gallium driver for your hardware. For example</p>
<pre>
- $ ./configure --with-state-trackers=egl_g3d,es,vega --enable-gallium-intel
+ $ ./configure --enable-gles-overlay --with-state-trackers=egl,vega --enable-gallium-intel
</pre>
-<p>The main library will be enabled by default. The <code>egl_g3d</code> state
+<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="opengles.html">es state tracker</a> provides OpenGL ES 1.x
-and 2.x and the <a href="openvg.html">vega state tracker</a> provides OpenVG
+later. The <a href="openvg.html">vega state tracker</a> provides OpenVG
1.x.</p>
</li>
</ol>
<p>In the given example, it will build and install <code>libEGL</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>,
+<code>libOpenVG</code>, and one or more EGL drivers.</p>
<h3>Configure Options</h3>
</li>
-<li><code>--with-egl-displays</code>
+<li><code>--with-egl-driver-dir</code>
-<p>List the 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-displays=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>
+<p>The directory EGL drivers should be installed to. If not specified, EGL
+drivers will be installed to <code>${libdir}/egl</code>.</p>
+
+</li>
+
+<li><code>--with-egl-platforms</code>
+
+<p>List the platforms (window systems) to support. Its argument is a comma
+seprated string such as <code>--with-egl-platforms=x11,drm</code>. It decides
+the platforms a driver may support. The first listed platform is also used by
+the main library to decide the native platform: the platform the EGL native
+types such as <code>EGLNativeDisplayType</code> or
+<code>EGLNativeWindowType</code> defined for.</p>
+
+<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>
</li>
<li><code>--with-state-trackers</code>
<p>The argument is a comma separated string. It is usually used to specify the
-rendering APIs, like OpenGL ES or OpenVG, to build. But it should be noted
-that a number of EGL drivers depend on the <code>egl_g3d</code> state tracker.
-They will <em>not</em> be built without the <code>egl_g3d</code> state
-tracker.</p>
+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>
</li>
-<li><code>--enable-gallium-swrast</code>
+<li><code>--enable-gles-overlay</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>
+<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>
-</ul>
-<h3>OpenGL</h3>
+<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
-<p>The OpenGL state tracker is not built in the above example. It should be
-noted that the classic <code>libGL</code> is not a state tracker and cannot be
-used with EGL (unless the EGL driver in use is <code>egl_glx</code>). To build
-the OpenGL state tracker, one may append <code>glx</code> to
-<code>--with-state-trackers</code> and manually build
-<code>src/gallium/winsys/xlib/</code>.</p>
+<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>
+
+</li>
+
+</ul>
<h2>Use EGL</h2>
-<p> The demos for OpenGL ES and OpenVG can be found in <code>progs/es1/</code>,
-<code>progs/es2/</code> and <code>progs/openvg/</code>. You can use them to
-test your build. For example,</p>
+<h3>Demos</h3>
-<pre>
- $ cd progs/es1/xegl
- $ make
- $ ./torus
-</pre>
+<p>There are demos for the client APIs supported by EGL. They can be found in
+mesa/demos repository.</p>
<h3>Environment Variables</h3>
runtime</p>
<ul>
+<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
+addition to the default directory. This variable is ignored for setuid/setgid
+binaries.</p>
+
+</li>
+
<li><code>EGL_DRIVER</code>
-<p>This variable forces the specified EGL driver to be loaded. It comes in
-handy when one wants to test a specific driver.</p>
+<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>
</li>
-<li><code>EGL_DISPLAY</code>
+<li><code>EGL_PLATFORM</code>
-<p>When <code>EGL_DRIVER</code> is not set, the main library loads <em>all</em>
-EGL drivers that support a certain window system. <code>EGL_DISPLAY</code> can
-be used to specify the window system and the valid values are, for example,
-<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
-<code>--with-egl-displays</code> at configuration time.
+<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>
</li>
<h2>EGL Drivers</h2>
-<p>There are two categories of EGL drivers: Gallium and classic.</p>
-
-<p>Gallium EGL drivers supports all rendering APIs specified in EGL 1.4. The
-support for optional EGL functions and EGL extensions is usually more complete
-than the classic ones. These drivers depend on the <code>egl_g3d</code> state
-tracker to build. The available drivers are</p>
-
<ul>
-<li><code>egl_<dpy>_i915</code></li>
-<li><code>egl_<dpy>_i965</code></li>
-<li><code>egl_<dpy>_radeon</code></li>
-<li><code>egl_<dpy>_nouveau</code></li>
-<li><code>egl_<dpy>_swrast</code></li>
-<li><code>egl_<dpy>_vmwgfx</code></li>
-</ul>
+<li><code>egl_gallium</code>
-<p><code><dpy></code> is given by <code>--with-egl-displays</code> at
-configuration time. There will be one EGL driver for each combination of the
-displays listed and the hardware drivers enabled.</p>
+<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>
-<p>Classic EGL drivers, on the other hand, supports only OpenGL as its
-rendering API. They can be found under <code>src/egl/drivers/</code>. There
-are 3 of them</p>
+</li>
-<ul>
<li><code>egl_glx</code>
<p>This driver provides a wrapper to GLX. It uses exclusively GLX to implement
is not available in GLX or GLX extensions.</p>
</li>
-<li><code>egl_xdri</code>
+<li><code>egl_dri2</code>
<p>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
-<code>egl_glx</code>, it has no dependency on <code>libGL</code>. 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 <code>egl_glx</code>.</p>
+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>
<p>This driver lacks maintenance and does <em>not</em> build. It is similiar
-to <code>egl_xdri</code> in that it functions as a DRI driver loader. But
-unlike <code>egl_xdri</code>, 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.</p>
+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>
</li>
</ul>
-<p>To use the classic drivers, one must manually set <code>EGL_DRIVER</code> at
-runtime.</p>
-
<h2>Developers</h2>
-The sources of the main library and the classic drivers can be found at
-<code>src/egl/</code>. The sources of the <code>egl_g3d</code> state tracker
-can be found at <code>src/gallium/state_trackers/egl_g3d/</code>.
+<p>The sources of the main library and the classic drivers can be found at
+<code>src/egl/</code>. The sources of the <code>egl</code> state tracker can
+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>
+
+<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>
+
+<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.
<h3>TODOs</h3>
<ul>
-<li>Thread safety</li>
<li>Pass the conformance tests</li>
-<li>Better automatic driver selection: <code>EGL_DISPLAY</code> loads all
-drivers and might eat too much memory.</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>
projects / mesa.git / blobdiff