diff options
author | marha <marha@users.sourceforge.net> | 2011-06-20 09:33:04 +0200 |
---|---|---|
committer | marha <marha@users.sourceforge.net> | 2011-06-20 09:33:04 +0200 |
commit | 4703c93aaecf0d5794eca723cd5b1b72b04d04ee (patch) | |
tree | 093ee59932ea8c412a7bc42829664b9d14edc1af /mesalib/docs | |
parent | 743d2ab8160b84c62106467c50ec3871adbf5e75 (diff) | |
download | vcxsrv-4703c93aaecf0d5794eca723cd5b1b72b04d04ee.tar.gz vcxsrv-4703c93aaecf0d5794eca723cd5b1b72b04d04ee.tar.bz2 vcxsrv-4703c93aaecf0d5794eca723cd5b1b72b04d04ee.zip |
libX11 xserver mesa git update 20 June 2011
Diffstat (limited to 'mesalib/docs')
-rw-r--r-- | mesalib/docs/egl.html | 643 | ||||
-rw-r--r-- | mesalib/docs/opengles.html | 139 | ||||
-rw-r--r-- | mesalib/docs/openvg.html | 104 | ||||
-rw-r--r-- | mesalib/docs/relnotes-7.11.html | 172 |
4 files changed, 519 insertions, 539 deletions
diff --git a/mesalib/docs/egl.html b/mesalib/docs/egl.html index 9eb7b44cc..5b750070c 100644 --- a/mesalib/docs/egl.html +++ b/mesalib/docs/egl.html @@ -1,323 +1,320 @@ -<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
-<a href="http://www.khronos.org/egl/" target="_parent">
-http://www.khronos.org/egl/</a>.</p>
-
-<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.</p>
-
-<h2>Build EGL</h2>
-
-<ol>
-<li>
-<p>Run <code>configure</code> with the desired client APIs and enable
-the driver for your hardware. For example</p>
-
-<pre>
- $ ./configure --enable-gles2 --enable-openvg --enable-gallium-nouveau
-</pre>
-
-<p>The main library and OpenGL is enabled by default. The first option above
-enables <a href="opengles.html">OpenGL ES 2.x</a>. The second option enables
-<a href="openvg.html">OpenVG</a>.</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>
-
-<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>
-
-<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>
-
-<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. Unless for special needs, the build system should
-select the right platforms automatically.</p>
-
-</li>
-
-<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
-
-<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-openvg</code>
-
-<p>OpenVG must be explicitly enabled by this option.</p>
-
-</li>
-
-<li><code>--enable-gallium-egl</code>
-
-<p>Explicitly enable or disable <code>egl_gallium</code>.</p>
-
-</li>
-
-</ul>
-
-<h2>Use EGL</h2>
-
-<h3>Demos</h3>
-
-<p>There are demos for the client APIs supported by EGL. They can be found in
-mesa/demos repository.</p>
-
-<h3>Environment Variables</h3>
-
-<p>There are several environment variables that control the behavior of EGL at
-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>
-
-<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 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>
-
-<li><code>EGL_PLATFORM</code>
-
-<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>
-
-<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>
-
-<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>
-
-<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, 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>
-
-<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>
-</ul>
-
-<h2>Packaging</h2>
-
-<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>
-
-<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>
-may either be disabled with <code>--disable-gallium-egl</code> or packaged
-separately.</p>
-
-<h2>Developers</h2>
-
-<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>Pass the conformance tests</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>
+<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 +<a href="http://www.khronos.org/egl/" target="_parent"> +http://www.khronos.org/egl/</a>.</p> + +<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.</p> + +<h2>Build EGL</h2> + +<ol> +<li> +<p>Run <code>configure</code> with the desired client APIs and enable +the driver for your hardware. For example</p> + +<pre> + $ ./configure --enable-gles1 --enable-gles2 \ + --with-dri-drivers=... \ + --with-gallium-drivers=... +</pre> + +<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>, and one +or more EGL drivers.</p> + +<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> + +<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> + +<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 +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. Unless for special needs, the build system should +select the right platforms automatically.</p> + +</li> + +<li><code>--enable-gles1</code> and <code>--enable-gles2</code> + +<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-shared-glapi</code> + +<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-openvg</code> + +<p>OpenVG must be explicitly enabled by this option.</p> + +</li> + +</ul> + +<h2>Use EGL</h2> + +<h3>Demos</h3> + +<p>There are demos for the client APIs supported by EGL. They can be found in +mesa/demos repository.</p> + +<h3>Environment Variables</h3> + +<p>There are several environment variables that control the behavior of EGL at +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> + +<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 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> + +<li><code>EGL_PLATFORM</code> + +<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> + +<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> + +<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> + +<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, 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> + +<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> +</ul> + +<h2>Packaging</h2> + +<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> + +<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> + +<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. + +</body> +</html> diff --git a/mesalib/docs/opengles.html b/mesalib/docs/opengles.html index 28b0acc20..0fee488e1 100644 --- a/mesalib/docs/opengles.html +++ b/mesalib/docs/opengles.html @@ -1,78 +1,61 @@ -<html>
-
-<title>OpenGL ES</title>
-
-<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
-
-<body>
-
-<h1>OpenGL ES</h1>
-
-<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0. More informations about
-OpenGL ES can be found at <a href="http://www.khronos.org/opengles/"
-target="_parent"> http://www.khronos.org/opengles/</a>.</p>
-
-<p>OpenGL ES depends on a working EGL implementation. Please refer to
-<a href="egl.html">Mesa EGL</a> for more information about EGL.</p>
-
-<h2>Build the Libraries</h2>
-<ol>
-<li>Run <code>configure</code> with <code>--enable-gles1 --enable-gles2</code> and enable the Gallium driver for your hardware.</li>
-<li>Build and install Mesa as usual.</li>
-</ol>
-
-Alternatively, if XCB-DRI2 is installed on the system, one can use
-<code>egl_dri2</code> EGL driver with OpenGL|ES-enabled DRI drivers
-
-<ol>
-<li>Run <code>configure</code> with <code>--enable-gles1 --enable-gles2</code>.</li>
-<li>Build and install Mesa as usual.</li>
-</ol>
-
-<p>Both methods will install libGLESv1_CM, libGLESv2, libEGL, and one or more
-EGL drivers for your hardware.</p>
-
-<h2>Run the Demos</h2>
-
-<p>There are some demos in <code>progs/egl/</code>. You can use them to test
-your build. For example,</p>
-
-<pre>
- $ cd progs/egl/eglut
- $ make
- $ cd ../opengles1
- $ make
- $ ./torus_x11
-</pre>
-
-<h2>Developers</h2>
-
-<h3>Internal Libraries</h3>
-
-<table border="1" style="text-align: center;">
- <tr><td>Library Name</td><td>Used By</td><td>Enabled</td><td>OpenGL</td><td>OpenGL ES 1.x</td><td>OpenGL ES 2.x</td></tr>
- <tr><td><code>libmesa.a</td><td>Classic DRI drivers</td><td>y</td><td>y</td><td>--enable-gles1</td><td>--enable-gles2</td></tr>
- <tr><td><code>libmesagallium.a</td><td>Gallium EGL and DRI drivers</td><td>y</td><td>y</td><td>--enable-gles1</td><td>--enable-gles2</td></tr>
-</table>
-
-<h3>Dispatch Table</h3>
-
-<p>OpenGL ES has an additional indirection when dispatching fucntions</p>
-
-<pre>
- Mesa: glFoo() --> _mesa_Foo()
- OpenGL ES: glFoo() --> _es_Foo() --> _mesa_Foo()
-</pre>
-
-<p>The indirection serves several purposes</p>
-
-<ul>
-<li>When a function is in Mesa and the type matches, it checks the arguments and calls the Mesa function.</li>
-<li>When a function is in Mesa but the type mismatches, it checks and converts the arguments before calling the Mesa function.</li>
-<li>When a function is not available in Mesa, or accepts arguments that are not available in OpenGL, it provides its own implementation.</li>
-</ul>
-
-<p>Other than the last case, OpenGL ES uses <code>APIspec.xml</code> to generate functions to check and/or converts the arguments.</p>
-
-</body>
-</html>
+<html> + +<title>OpenGL ES</title> + +<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<body> + +<h1>OpenGL ES</h1> + +<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0. More informations about +OpenGL ES can be found at <a href="http://www.khronos.org/opengles/" +target="_parent"> http://www.khronos.org/opengles/</a>.</p> + +<p>OpenGL ES depends on a working EGL implementation. Please refer to +<a href="egl.html">Mesa EGL</a> for more information about EGL.</p> + +<h2>Build the Libraries</h2> +<ol> +<li>Run <code>configure</code> with <code>--enable-gles1 --enable-gles2</code> and enable the Gallium driver for your hardware.</li> +<li>Build and install Mesa as usual.</li> +</ol> + +Alternatively, if XCB-DRI2 is installed on the system, one can use +<code>egl_dri2</code> EGL driver with OpenGL|ES-enabled DRI drivers + +<ol> +<li>Run <code>configure</code> with <code>--enable-gles1 --enable-gles2</code>.</li> +<li>Build and install Mesa as usual.</li> +</ol> + +<p>Both methods will install libGLESv1_CM, libGLESv2, libEGL, and one or more +EGL drivers for your hardware.</p> + +<h2>Run the Demos</h2> + +<p>There are some demos in <code>mesa/demos</code> repository.</p> + +<h2>Developers</h2> + +<h3>Dispatch Table</h3> + +<p>OpenGL ES has an additional indirection when dispatching fucntions</p> + +<pre> + Mesa: glFoo() --> _mesa_Foo() + OpenGL ES: glFoo() --> _es_Foo() --> _mesa_Foo() +</pre> + +<p>The indirection serves several purposes</p> + +<ul> +<li>When a function is in Mesa and the type matches, it checks the arguments and calls the Mesa function.</li> +<li>When a function is in Mesa but the type mismatches, it checks and converts the arguments before calling the Mesa function.</li> +<li>When a function is not available in Mesa, or accepts arguments that are not available in OpenGL, it provides its own implementation.</li> +</ul> + +<p>Other than the last case, OpenGL ES uses <code>APIspec.xml</code> to generate functions to check and/or converts the arguments.</p> + +</body> +</html> diff --git a/mesalib/docs/openvg.html b/mesalib/docs/openvg.html index cb2e2b651..81e50b65f 100644 --- a/mesalib/docs/openvg.html +++ b/mesalib/docs/openvg.html @@ -1,52 +1,52 @@ -<HTML>
-
-<TITLE>OpenVG State Tracker</TITLE>
-
-<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
-
-<BODY>
-
-<body bgcolor="#eeeeee">
-
-<H1>OpenVG State Tracker</H1>
-
-<p>
-The current version of the OpenVG state tracker implements OpenVG 1.0.
-</p>
-<p>
-More informations about OpenVG can be found at
-<a href="http://www.khronos.org/openvg/" target="_parent">
-http://www.khronos.org/openvg/</a> .
-</p>
-<p>
-The OpenVG state tracker depends on the Gallium architecture and a working EGL implementation.
-Please refer to <a href="egl.html">Mesa EGL</a> for more information about EGL.
-</p>
-
-
-<h2>Building the library</h2>
-<ol>
-<li>Run <code>configure</code> with <code>--enable-openvg</code>. If you do
-not need OpenGL, you can add <code>--disable-opengl</code> to save the
-compilation time.</li>
-
-<li>Build and install Mesa as usual.</li>
-</ol>
-
-<h3>Sample build</h3>
-A sample build looks as follows:
-<pre>
- $ ./configure --disable-opengl --enable-openvg
- $ make
- $ make install
-</pre>
-
-<p>It will install <code>libOpenVG.so</code>, <code>libEGL.so</code>, and one
-or more EGL drivers.</p>
-
-<h2>OpenVG Demos</h2>
-
-<p>OpenVG demos can be found in mesa/demos repository.</p>
-
-</body>
-</html>
+<HTML> + +<TITLE>OpenVG State Tracker</TITLE> + +<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<BODY> + +<body bgcolor="#eeeeee"> + +<H1>OpenVG State Tracker</H1> + +<p> +The current version of the OpenVG state tracker implements OpenVG 1.1. +</p> +<p> +More informations about OpenVG can be found at +<a href="http://www.khronos.org/openvg/" target="_parent"> +http://www.khronos.org/openvg/</a> . +</p> +<p> +The OpenVG state tracker depends on the Gallium architecture and a working EGL implementation. +Please refer to <a href="egl.html">Mesa EGL</a> for more information about EGL. +</p> + + +<h2>Building the library</h2> +<ol> +<li>Run <code>configure</code> with <code>--enable-openvg</code> and +<code>--enable-gallium-egl</code>. If you do not need OpenGL, you can add +<code>--disable-opengl</code> to save the compilation time.</li> + +<li>Build and install Mesa as usual.</li> +</ol> + +<h3>Sample build</h3> +A sample build looks as follows: +<pre> + $ ./configure --disable-opengl --enable-openvg --enable-gallium-egl + $ make + $ make install +</pre> + +<p>It will install <code>libOpenVG.so</code>, <code>libEGL.so</code>, and one +or more EGL drivers.</p> + +<h2>OpenVG Demos</h2> + +<p>OpenVG demos can be found in mesa/demos repository.</p> + +</body> +</html> diff --git a/mesalib/docs/relnotes-7.11.html b/mesalib/docs/relnotes-7.11.html index b80179aaf..c81ac9f15 100644 --- a/mesalib/docs/relnotes-7.11.html +++ b/mesalib/docs/relnotes-7.11.html @@ -1,86 +1,86 @@ -<HTML>
-
-<head>
-<TITLE>Mesa Release Notes</TITLE>
-<link rel="stylesheet" type="text/css" href="mesa.css">
-<meta http-equiv="content-type" content="text/html; charset=utf-8" />
-</head>
-
-<BODY>
-
-<body bgcolor="#eeeeee">
-
-<H1>Mesa 7.11 Release Notes / (release date TBD)</H1>
-
-<p>
-Mesa 7.11 is a new development release.
-People who are concerned with stability and reliability should stick
-with a previous release or wait for Mesa 7.11.1.
-</p>
-<p>
-Mesa 7.11 implements the OpenGL 2.1 API, but the version reported by
-glGetString(GL_VERSION) depends on the particular driver being used.
-Some drivers don't support all the features required in OpenGL 2.1.
-</p>
-<p>
-See the <a href="install.html">Compiling/Installing page</a> for prerequisites
-for DRI hardware acceleration.
-</p>
-
-
-<h2>MD5 checksums</h2>
-<pre>
-tbd
-</pre>
-
-
-<h2>New features</h2>
-<ul>
-<li>GL_ARB_ES2_compatibility (gallium drivers)
-<li>GL_ARB_color_buffer_float (gallium drivers, i965)
-<li>GL_ARB_draw_buffers_blend (gallium)
-<li>GL_ARB_draw_instanced extension (gallium drivers, swrast)
-<li>GL_ARB_instanced_arrays extension (gallium drivers)
-<li>GL_ARB_occlusion_query2 (gallium drivers, swrast)
-<li>GL_ARB_robustness (all drivers)
-<li>GL_ARB_sampler_objects (gallium drivers)
-<li>GL_ARB_seamless_cube_map (gallium r600)
-<li>GL_ARB_shader_texture_lod (gallium drivers)
-<li>GL_ARB_sync (gallium drivers only, intel support was in 7.6)
-<li>GL_ARB_texture_compression_rgtc (gallium drivers, swrast, i965)
-<li>GL_ARB_texture_float (gallium, i965)
-<li>GL_EXT_packed_float (gallium r600)
-<li>GL_EXT_texture_compression_latc (gallium drivers, swrast)
-<li>GL_EXT_texture_compression_rgtc (gallium drivers, swrast, i965)
-<li>GL_EXT_texture_filter_anisotropic (swrast)
-<li>GL_EXT_texture_shared_exponent (gallium drivers, swrast)
-<li>GL_EXT_texture_sRGB_decode (gallium drivers, swrast, i965)
-<li>GL_EXT_texture_snorm (gallium drivers)
-<li>GL_AMD_draw_buffers_blend (alias of the ARB variant)
-<li>GL_AMD_seamless_cubemap_per_texture (gallium r600)
-<li>GL_AMD_shader_stencil_export (alias of the ARB variant)
-<li>GL_ATI_draw_buffers (all drivers)
-<li>GL_ATI_texture_compression_3dc (gallium drivers, swrast)
-<li>GL_ATI_texture_float (gallium, i965)
-<li>GL_NV_conditional_render (i965)
-<li>GL_NV_texture_barrier (gallium drivers)
-</ul>
-
-
-<h2>Bug fixes</h2>
-<ul>
-</ul>
-
-
-<h2>Changes</h2>
-<ul>
-<li>The Windows MSVC project files have been removed.
-They haven't been maintained in quite a while.
-Building with SCons is an alternative.
-<li>Removed GL_SGI_texture_color_table support from swrast driver - the only
-driver that implemented it.
-</ul>
-
-
-</body>
-</html>
+<HTML> + +<head> +<TITLE>Mesa Release Notes</TITLE> +<link rel="stylesheet" type="text/css" href="mesa.css"> +<meta http-equiv="content-type" content="text/html; charset=utf-8" /> +</head> + +<BODY> + +<body bgcolor="#eeeeee"> + +<H1>Mesa 7.11 Release Notes / (release date TBD)</H1> + +<p> +Mesa 7.11 is a new development release. +People who are concerned with stability and reliability should stick +with a previous release or wait for Mesa 7.11.1. +</p> +<p> +Mesa 7.11 implements the OpenGL 2.1 API, but the version reported by +glGetString(GL_VERSION) depends on the particular driver being used. +Some drivers don't support all the features required in OpenGL 2.1. +</p> +<p> +See the <a href="install.html">Compiling/Installing page</a> for prerequisites +for DRI hardware acceleration. +</p> + + +<h2>MD5 checksums</h2> +<pre> +tbd +</pre> + + +<h2>New features</h2> +<ul> +<li>GL_ARB_ES2_compatibility (gallium drivers) +<li>GL_ARB_color_buffer_float (gallium drivers, i965) +<li>GL_ARB_draw_buffers_blend (gallium) +<li>GL_ARB_draw_instanced extension (gallium drivers, swrast) +<li>GL_ARB_instanced_arrays extension (gallium drivers) +<li>GL_ARB_occlusion_query2 (gallium drivers, swrast) +<li>GL_ARB_robustness (all drivers) +<li>GL_ARB_sampler_objects (gallium drivers) +<li>GL_ARB_seamless_cube_map (gallium r600) +<li>GL_ARB_shader_texture_lod (gallium drivers, i965) +<li>GL_ARB_sync (gallium drivers only, intel support was in 7.6) +<li>GL_ARB_texture_compression_rgtc (gallium drivers, swrast, i965) +<li>GL_ARB_texture_float (gallium, i965) +<li>GL_EXT_packed_float (gallium r600) +<li>GL_EXT_texture_compression_latc (gallium drivers, swrast) +<li>GL_EXT_texture_compression_rgtc (gallium drivers, swrast, i965) +<li>GL_EXT_texture_filter_anisotropic (swrast) +<li>GL_EXT_texture_shared_exponent (gallium drivers, swrast) +<li>GL_EXT_texture_sRGB_decode (gallium drivers, swrast, i965) +<li>GL_EXT_texture_snorm (gallium drivers) +<li>GL_AMD_draw_buffers_blend (alias of the ARB variant) +<li>GL_AMD_seamless_cubemap_per_texture (gallium r600) +<li>GL_AMD_shader_stencil_export (alias of the ARB variant) +<li>GL_ATI_draw_buffers (all drivers) +<li>GL_ATI_texture_compression_3dc (gallium drivers, swrast) +<li>GL_ATI_texture_float (gallium, i965) +<li>GL_NV_conditional_render (i965) +<li>GL_NV_texture_barrier (gallium drivers) +</ul> + + +<h2>Bug fixes</h2> +<ul> +</ul> + + +<h2>Changes</h2> +<ul> +<li>The Windows MSVC project files have been removed. +They haven't been maintained in quite a while. +Building with SCons is an alternative. +<li>Removed GL_SGI_texture_color_table support from swrast driver - the only +driver that implemented it. +</ul> + + +</body> +</html> |