<p>
The problem is a modern OpenGL driver will return a very long string
-for the glGetString(GL_EXTENSIONS) query and if the application
+for the <code>glGetString(GL_EXTENSIONS)</code> query and if the application
naively copies the string into a fixed-size buffer it can overflow the
buffer and crash the application.
</p>
<p>
-The work-around is to set the MESA_EXTENSION_MAX_YEAR environment variable
-to the approximate release year of the game.
-This will cause the glGetString(GL_EXTENSIONS) query to only report extensions
-older than the given year.
+The work-around is to set the <code>MESA_EXTENSION_MAX_YEAR</code>
+environment variable to the approximate release year of the game.
+This will cause the <code>glGetString(GL_EXTENSIONS)</code> query to only report
+extensions older than the given year.
</p>
<p>
_mesa_foo_bar() - an internal non-static Mesa function
</pre>
-<li>Constants, macros and enum names are ALL_UPPERCASE, with _ between
-words.
-<li>Mesa usually uses camel case for local variables (Ex: "localVarname")
-while gallium typically uses underscores (Ex: "local_var_name").
+<li>Constants, macros and enum names are <code>ALL_UPPERCASE</code>, with _
+between words.
+<li>Mesa usually uses camel case for local variables (Ex:
+<code>localVarname</code>) while gallium typically uses underscores (Ex:
+<code>local_var_name</code>).
<li>Global variables are almost never used because Mesa should be thread-safe.
<li>Booleans. Places that are not directly visible to the GL API
<code>false</code> over <code>GLboolean</code>, <code>GL_TRUE</code>, and
<code>GL_FALSE</code>. In C code, this may mean that
<code>#include <stdbool.h></code> needs to be added. The
-<code>try_emit_</code>* methods in src/mesa/program/ir_to_mesa.cpp and
-src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
+<code>try_emit_</code>* methods in <code>src/mesa/program/ir_to_mesa.cpp</code>
+and <code>src/mesa/state_tracker/st_glsl_to_tgsi.cpp</code> can serve as
+examples.
</ul>
Normally Mesa (and OpenGL) records but does not notify the user of
errors. It is up to the application to call
<code>glGetError</code> to check for errors. Mesa supports an
- environment variable, MESA_DEBUG, to help with debugging. If
- MESA_DEBUG is defined, a message will be printed to stdout whenever
- an error occurs.
+ environment variable, <code>MESA_DEBUG</code>, to help with debugging. If
+ <code>MESA_DEBUG</code> is defined, a message will be printed to stdout
+ whenever an error occurs.
</p>
<p>
(<code>--buildtype debug</code> for meson, <code>build=debug</code> for scons).
</p>
<p>
- In your debugger you can set a breakpoint in _mesa_error() to trap Mesa
- errors.
+ In your debugger you can set a breakpoint in <code>_mesa_error()</code> to trap
+ Mesa errors.
</p>
<p>
There is a display list printing/debugging facility. See the end of
- src/dlist.c for details.
+ <code>src/dlist.c</code> for details.
</p>
</div>
<ul>
<li>
- If glext.h doesn't define the extension, edit include/GL/gl.h and add
- code like this:
+ If <code>glext.h</code> doesn't define the extension, edit
+ <code>include/GL/gl.h</code> and add code like this:
<pre>
#ifndef GL_EXT_the_extension_name
#define GL_EXT_the_extension_name 1
</pre>
</li>
<li>
- In the src/mapi/glapi/gen/ directory, add the new extension functions and
- enums to the gl_API.xml file.
+ In the <code>src/mapi/glapi/gen/</code> directory, add the new extension
+ functions and enums to the <code>gl_API.xml</code> file.
Then, a bunch of source files must be regenerated by executing the
corresponding Python scripts.
</li>
<li>
- Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
- if the extension requires driver capabilities not already exposed by
- another extension.
+ Add a new entry to the <code>gl_extensions</code> struct in
+ <code>mtypes.h</code> if the extension requires driver capabilities not
+ already exposed by another extension.
</li>
<li>
- Add a new entry to the src/mesa/main/extensions_table.h file.
+ Add a new entry to the <code>src/mesa/main/extensions_table.h</code> file.
</li>
<li>
From this point, the best way to proceed is to find another extension,
</li>
<li>
To determine if the new extension is active in the current context,
- use the auto-generated _mesa_has_##name_str() function defined in
- src/mesa/main/extensions.h.
+ use the auto-generated <code>_mesa_has_##name_str()</code> function
+ defined in <code>src/mesa/main/extensions.h</code>.
</li>
<li>
- The dispatch tests check_table.cpp and dispatch_sanity.cpp
+ The dispatch tests check_table.cpp and <code>dispatch_sanity.cpp</code>
should be updated with details about the new extensions functions. These
- tests are run using 'meson test'
+ tests are run using <code>meson test</code>.
</li>
</ul>
<h3>3.3 Why Isn't depth buffering working at all?</h3>
<p>
-Be sure you're requesting a depth buffered-visual. If you set the MESA_DEBUG
-environment variable it will warn you about trying to enable depth testing
-when you don't have a depth buffer.
+Be sure you're requesting a depth buffered-visual. If you set the
+<code>MESA_DEBUG</code> environment variable it will warn you about trying
+to enable depth testing when you don't have a depth buffer.
</p>
<p>Specifically, make sure <code>glutInitDisplayMode</code> is being called
with <code>GLUT_DEPTH</code> or <code>glXChooseVisual</code> is being
-called with a non-zero value for GLX_DEPTH_SIZE.
+called with a non-zero value for <code>GLX_DEPTH_SIZE</code>.
</p>
<p>This discussion applies to stencil buffers, accumulation buffers and
alpha channels too.
</p>
-<h3>3.4 Why does glGetString() always return NULL?</h3>
+<h3>3.4 Why does <code>glGetString()</code> always return <code>NULL</code>?</h3>
<p>
Be sure you have an active/current OpenGL rendering context before
-calling glGetString.
+calling <code>glGetString</code>.
</p>
-<h3>3.5 GL_POINTS and GL_LINES don't touch the right pixels</h3>
+<h3>3.5 <code>GL_POINTS</code> and <code>GL_LINES</code> don't touch the
+right pixels</h3>
<p>
-If you're trying to draw a filled region by using GL_POINTS or GL_LINES
-and seeing holes or gaps it's because of a float-to-int rounding problem.
-But this is not a bug.
-See Appendix H of the OpenGL Programming Guide - "OpenGL Correctness Tips".
-Basically, applying a translation of (0.375, 0.375, 0.0) to your coordinates
-will fix the problem.
+If you're trying to draw a filled region by using <code>GL_POINTS</code> or
+<code>GL_LINES</code> and seeing holes or gaps it's because of a float-to-int
+rounding problem. But this is not a bug. See Appendix H of the OpenGL
+Programming Guide - "OpenGL Correctness Tips". Basically, applying a
+translation of (0.375, 0.375, 0.0) to your coordinates will fix the problem.
</p>
<br>
</p>
-<h3>4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?</h3>
+<h3>4.3 Why isn't <code>GL_EXT_texture_compression_s3tc</code> implemented in
+Mesa?</h3>
<p>
Oh but it is! Prior to 2nd October 2017, the Mesa project did not include s3tc
support due to intellectual property (IP) and/or patent issues around the s3tc
</p>
<ul>
<li><a href="https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/features.txt">
- <b>features.txt</b></a> - Status of OpenGL 3.x / 4.x features in Mesa.</li>
+ <code>features.txt</code></a> - Status of OpenGL 3.x / 4.x features in
+ Mesa.</li>
</ul>
<p>
</p>
<ul>
<li><a href="https://dri.freedesktop.org/wiki/R600ToDo">
- <b>r600g</b></a> - Driver for ATI/AMD R600 - Northern Island.</li>
+ <code>r600g</code></a> - Driver for ATI/AMD R600 - Northern Island.</li>
<li><a href="https://dri.freedesktop.org/wiki/R300ToDo">
- <b>r300g</b></a> - Driver for ATI R300 - R500.</li>
+ <code>r300g</code></a> - Driver for ATI R300 - R500.</li>
</ul>
<p>
projects / mesa.git / commitdiff