diff options
author | Brian Paul <brianp@vmware.com> | 2015-05-25 09:13:09 -0600 |
---|---|---|
committer | Brian Paul <brianp@vmware.com> | 2015-05-26 10:02:59 -0600 |
commit | 98f2f47f7a1d893bb482d508a690c417c2453c6e (patch) | |
tree | 74e268d2152544e9abfb0f0e3b095df3ddefb595 /docs/devinfo.html | |
parent | eec904d29c0d996fb05f24771a2fdd33e152f519 (diff) | |
download | external_mesa3d-98f2f47f7a1d893bb482d508a690c417c2453c6e.zip external_mesa3d-98f2f47f7a1d893bb482d508a690c417c2453c6e.tar.gz external_mesa3d-98f2f47f7a1d893bb482d508a690c417c2453c6e.tar.bz2 |
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>
Diffstat (limited to 'docs/devinfo.html')
-rw-r--r-- | docs/devinfo.html | 110 |
1 files changed, 61 insertions, 49 deletions
diff --git a/docs/devinfo.html b/docs/devinfo.html index 8d20eea..c7e4171 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -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> |