docs: reorganize devnotes.html file
Move "Adding Extensions" to the end. Add a simple table of contents at the top. Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
This commit is contained in:
parent
eec904d29c
commit
98f2f47f7a
|
@ -17,55 +17,15 @@
|
|||
<h1>Development Notes</h1>
|
||||
|
||||
|
||||
<h2>Adding Extensions</h2>
|
||||
|
||||
<p>
|
||||
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:
|
||||
<pre>
|
||||
#ifndef GL_EXT_the_extension_name
|
||||
#define GL_EXT_the_extension_name 1
|
||||
/* declare the new enum tokens */
|
||||
/* prototype the new functions */
|
||||
/* TYPEDEFS for the new functions */
|
||||
#endif
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
In the src/mapi/glapi/gen/ directory, add the new extension functions and
|
||||
enums to the gl_API.xml 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
|
||||
</li>
|
||||
<li>
|
||||
Update the <code>extensions.c</code> file.
|
||||
</li>
|
||||
<li>
|
||||
From this point, the best way to proceed is to find another extension,
|
||||
similar to the new one, that's already implemented in Mesa and use it
|
||||
as an example.
|
||||
</li>
|
||||
<li>
|
||||
If the new extension adds new GL state, the functions in get.c, enable.c
|
||||
and attrib.c will most likely require new code.
|
||||
</li>
|
||||
<li>
|
||||
The dispatch tests check_table.cpp and dispatch_sanity.cpp
|
||||
should be updated with details about the new extensions functions. These
|
||||
tests are run using 'make check'
|
||||
</li>
|
||||
<li><a href="#style">Coding Style</a>
|
||||
<li><a href="#submitting">Submitting Patches</a>
|
||||
<li><a href="#release">Making a New Mesa Release</a>
|
||||
<li><a href="#extensions">Adding Extensions</a>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
<h2>Coding Style</h2>
|
||||
<h2 id="style">Coding Style</h2>
|
||||
|
||||
<p>
|
||||
Mesa's code style has changed over the years. Here's the latest.
|
||||
|
@ -160,7 +120,8 @@ of <tt>bool</tt>, <tt>true</tt>, and
|
|||
src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
|
||||
</p>
|
||||
|
||||
<h2>Submitting patches</h2>
|
||||
|
||||
<h2 id="submitting">Submitting patches</h2>
|
||||
|
||||
<p>
|
||||
You should always run the Mesa Testsuite before submitting patches.
|
||||
|
@ -184,7 +145,7 @@ re-sending the whole series). Using --in-reply-to makes
|
|||
it harder for reviewers to accidentally review old patches.
|
||||
</p>
|
||||
|
||||
<h2>Marking a commit as a candidate for a stable branch</h2>
|
||||
<h3>Marking a commit as a candidate for a stable branch</h3>
|
||||
|
||||
<p>
|
||||
If you want a commit to be applied to a stable branch,
|
||||
|
@ -221,7 +182,7 @@ the upcoming stable release can always be seen on the
|
|||
<a href="http://cworth.org/~cworth/mesa-stable-queue/">Mesa Stable Queue</a>
|
||||
page.
|
||||
|
||||
<h2>Criteria for accepting patches to the stable branch</h2>
|
||||
<h3>Criteria for accepting patches to the stable branch</h3>
|
||||
|
||||
Mesa has a designated release manager for each stable branch, and the release
|
||||
manager is the only developer that should be pushing changes to these
|
||||
|
@ -306,7 +267,8 @@ be rejected:
|
|||
regression that is unaacceptable for the stable branch.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Making a New Mesa Release</h2>
|
||||
|
||||
<h2 id="release">Making a New Mesa Release</h2>
|
||||
|
||||
<p>
|
||||
These are the instructions for making a new Mesa release.
|
||||
|
@ -543,6 +505,56 @@ release announcement:
|
|||
</pre>
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="extensions">Adding Extensions</h2>
|
||||
|
||||
<p>
|
||||
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:
|
||||
<pre>
|
||||
#ifndef GL_EXT_the_extension_name
|
||||
#define GL_EXT_the_extension_name 1
|
||||
/* declare the new enum tokens */
|
||||
/* prototype the new functions */
|
||||
/* TYPEDEFS for the new functions */
|
||||
#endif
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
In the src/mapi/glapi/gen/ directory, add the new extension functions and
|
||||
enums to the gl_API.xml 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
|
||||
</li>
|
||||
<li>
|
||||
Update the <code>extensions.c</code> file.
|
||||
</li>
|
||||
<li>
|
||||
From this point, the best way to proceed is to find another extension,
|
||||
similar to the new one, that's already implemented in Mesa and use it
|
||||
as an example.
|
||||
</li>
|
||||
<li>
|
||||
If the new extension adds new GL state, the functions in get.c, enable.c
|
||||
and attrib.c will most likely require new code.
|
||||
</li>
|
||||
<li>
|
||||
The dispatch tests check_table.cpp and dispatch_sanity.cpp
|
||||
should be updated with details about the new extensions functions. These
|
||||
tests are run using 'make check'
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
|
Loading…
Reference in New Issue