To add a new GL extension to Mesa you have to do at least the following. +
glext.h doesn't define the extension, edit
+ include/GL/gl.h and add code like this:
#ifndef GL_EXT_the_extension_name
#define GL_EXT_the_extension_name 1
@@ -36,16 +41,18 @@ To add a new GL extension to Mesa you have to do at least the following.
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.
gl_extensions struct in mtypes.h
+ Add a new entry to the gl_extensions struct in
+ mtypes.h if the extension requires driver capabilities not
+ already exposed by another extension.
extensions.c file.
+ Add a new entry to the src/mesa/main/extensions_table.h file.
get.c, enable.c and attrib.c
+ will most likely require new code.
+_mesa_has_##name_str() function
+ defined in src/mesa/main/extensions.h.
+check_table.cpp and
+ dispatch_sanity.cpp should be updated with details about
+ the new extensions functions. These tests are run using
+ meson test.
-Mesa's code style has changed over the years. Here's the latest. -
- --Comment your code! It's extremely important that open-source code be -well documented. Also, strive to write clean, easily understandable code. -
- --3-space indentation -
- --If you use tabs, set them to 8 columns -
- --Line width: the preferred width to fill comments and code in Mesa is 78 -columns. Exceptions are sometimes made for clarity (e.g. tabular data is -sometimes filled to a much larger width so that extraneous carriage returns -don't obscure the table). -
- --Brace example: -
-
- if (condition) {
- foo;
- }
- else {
- bar;
- }
-
- switch (condition) {
- case 0:
- foo();
- break;
-
- case 1: {
- ...
- break;
- }
-
- default:
- ...
- break;
- }
-
-
--Here's the GNU indent command which will best approximate my preferred style: -(Note that it won't format switch statements in the preferred way) -
-- indent -br -i3 -npcs --no-tabs infile.c -o outfile.c -- - -
-Local variable name example: localVarName (no underscores) -
- --Constants and macros are ALL_UPPERCASE, with _ between words -
- --Global variables are not allowed. -
- --Function name examples: -
-- glFooBar() - a public GL entry point (in glapi_dispatch.c) - _mesa_FooBar() - the internal immediate mode function - save_FooBar() - retained mode (display list) function in dlist.c - foo_bar() - a static (private) function - _mesa_foo_bar() - an internal non-static Mesa function -- -
-Places that are not directly visible to the GL API should prefer the use -of bool, true, and -false over GLboolean, GL_TRUE, and -GL_FALSE. In C code, this may mean that -#include <stdbool.h> needs to be added. The -try_emit_* methods in src/mesa/program/ir_to_mesa.cpp and -src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples. -
- --You should always run the Mesa Testsuite before submitting patches. -The Testsuite can be run using the 'make check' command. All tests -must pass before patches will be accepted, this may mean you have -to update the tests themselves. -
- --Patches should be sent to the Mesa mailing list for review. -When submitting a patch make sure to use git send-email rather than attaching -patches to emails. Sending patches as attachments prevents people from being -able to provide in-line review comments. -
- --When submitting follow-up patches you can use --in-reply-to to make v2, v3, -etc patches show up as replies to the originals. This usually works well -when you're sending out updates to individual patches (as opposed to -re-sending the whole series). Using --in-reply-to makes -it harder for reviewers to accidentally review old patches. -
- --If you want a commit to be applied to a stable branch, -you should add an appropriate note to the commit message. -
- --Here are some examples of such a note: -
-
-Please use git cherry-pick -x <commit> for cherry-picking a commit
-from master to a stable branch.
-
-These are the instructions for making a new Mesa release. -
- --Use git to get the latest Mesa files from the git repository, from whatever -branch is relevant. -
- - --Create a docs/relnotes/x.y.z.html file. -The bin/bugzilla_mesa.sh and bin/shortlog_mesa.sh scripts can be used to -create the HTML-formatted lists of bugfixes and changes to include in the file. -Link the new docs/relnotes/x.y.z.html file into the main relnotes.html file. -
- --Update docs/index.html. -
- -
-Tag the files with the release name (in the form mesa-x.y)
-with: git tag -s mesa-x.y -m "Mesa x.y Release"
-Then: git push origin mesa-x.y
-
-Make the distribution files. From inside the Mesa directory: -
- ./autogen.sh - make tarballs -- -
-After the tarballs are created, the md5 checksums for the files will -be computed. -Add them to the docs/relnotes/x.y.html file. -
- --Copy the distribution files to a temporary directory, unpack them, -compile everything, and run some demos to be sure everything works. -
- -
-Make a new directory for the release on annarchy.freedesktop.org with:
-
-
-mkdir /srv/ftp.freedesktop.org/pub/mesa/x.y
-
-
-Basically, to upload the tarball files with:
-
-
-rsync -avP -e ssh MesaLib-x.y.* USERNAME@annarchy.freedesktop.org:/srv/ftp.freedesktop.org/pub/mesa/x.y/
-
-
-Update the web site by copying the docs/ directory's files to
-/home/users/b/br/brianp/mesa-www/htdocs/ with:
-
-
-sftp USERNAME,mesa3d@web.sourceforge.net
-
-
-Make an announcement on the mailing lists: - -mesa-dev@lists.freedesktop.org, -mesa-users@lists.freedesktop.org -and -mesa-announce@lists.freedesktop.org -
-