Commit 392c0833 authored by Erik Faye-Lund 's avatar Erik Faye-Lund

docs: add more more code-tags

It's easier to read function-names, file-names and other
"machine"-related strings if they are formatted in a monospace font. So
let's mark these up with code-tags.
Signed-off-by: Erik Faye-Lund 's avatarErik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: default avatarEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
parent 0ee36696
......@@ -48,16 +48,16 @@ start-up because of an extension string buffer-overflow problem.
<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>
......
......@@ -120,10 +120,11 @@ the opening brace goes on the next line by itself (see above.)
_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
......@@ -131,8 +132,9 @@ should prefer the use of <code>bool</code>, <code>true</code>, and
<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 &lt;stdbool.h&gt;</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>
......
......@@ -20,9 +20,9 @@
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>
......@@ -30,12 +30,12 @@
(<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>
......
......@@ -29,8 +29,8 @@ To add a new GL extension to Mesa you have to do at least the following.
<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
......@@ -41,18 +41,18 @@ To add a new GL extension to Mesa you have to do at least the following.
</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,
......@@ -65,13 +65,13 @@ To add a new GL extension to Mesa you have to do at least the following.
</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>
......
......@@ -291,34 +291,34 @@ If you need a deeper you can modify the parameters to
<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>
......@@ -365,7 +365,8 @@ the archives) is a good way to get information.
</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
......
......@@ -48,7 +48,8 @@ You can find some further To-do lists here:
</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>
......@@ -56,9 +57,9 @@ You can find some further To-do lists here:
</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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment