aboutsummaryrefslogtreecommitdiffstats
path: root/docs/devinfo.rst
blob: 4e06bbf7e79728b538628240d07ddb9e32f21080 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Development Notes
=================

-  `Adding Extensions <#extensions>`__

.. _extensions:

Adding Extensions
-----------------

To add a new GL extension to Mesa you have to do at least the following.

-  If ``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
           /* declare the new enum tokens */
           /* prototype the new functions */
           /* TYPEDEFS for the new functions */
           #endif
         

-  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.
-  Add a new entry to the ``gl_extensions`` struct in ``mtypes.h`` if
   the extension requires driver capabilities not already exposed by
   another extension.
-  Add a new entry to the ``src/mesa/main/extensions_table.h`` file.
-  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.
-  If the new extension adds new GL state, the functions in ``get.c``,
   ``enable.c`` and ``attrib.c`` will most likely require new code.
-  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``.
-  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 ``meson test``.