Projects suitable for new developers

This is a list of small, fairly easy projects that developers new to Mesa can use to get a start with the project.

The lists below are broken down into a logical workflow that will likely match the set of patches that you will produce. When you send patches to the mesa-dev mailing list you must use git-send-email and NO OTHER METHOD.

Enable KHR_debug for OpenGL ES contexts

This extension is already implemented for desktop OpenGL, so most of the work has already been done. See commits around 51a2792. What remains for OpenGL ES is:

  • Port existing piglit tests to use an OpenGL ES 2.0 context and the OpenGL ES names for the extension functions. Each of the functions added by the extension has a KHR suffix in OpenGL ES that is missing in desktop OpenGL.
  • Add entries to src/mapi/glapi/gen/es_EXT.xml for the KHR decorated function names. These entries will look similar to the function entries for CompressedTexImage3DOES and friends. Start by copying the existing entries from src/mapi/glapi/gen/gl_API.xml.
  • Update src/mesa/main/tests/dispatch_sanity.cpp to expect the new functions. This change should be in the same patch as the previous change to prevent make check build breaks.
  • Find every location in the Mesa code base that interacts with debug output. This isn't as hard as it sounds. grep will be your friend here. Modify all of these places to function in an OpenGL ES context. Most of these places have some code like:

     if (!_mesa_is_desktop_gl(ctx)) {
        goto invalid_enum_error;
     }
    

    Making this work in an OpenGL ES context is mostly a matter of deleting the checks for a desktop OpenGL context.

  • Update the table in src/mesa/main/extensions.c to advertise GL_KHR_debug in ES1 and ES2 contexts.

Implement NV_non_square_matrices

This extension back-ports some desktop OpenGL functionality to OpenGL ES. The shading language in OpenGL ES 2.0 was forked from desktop GLSL sometime between GLSL 1.10 and GLSL 1.20. As a result it has only a subset of the features added in GLSL 1.20. This extension adds non-square matrix (e.g., mat4x3) support added in GLSL 1.20 but not previously available in GLSL ES 1.00. This functionality is, of course, available in GLSL ES 3.00.

  • Write a negative compile test for each non-square matrix type added by the extension. The negative compile tests should look something like:

    // [config]
    // expect_result: fail
    // glsl_version: 1.00
    // [end config]
    #version 100
    uniform mat2x3 u;
    void main() { gl_Position = vec4(0.0); }
    

    These tests should go in tests/spec/nv_non_square_matrices/compiler.

  • Write a positive compile test for each non-square matrix type added by the extension. Each of these tests should try to do some basic operation (e.g., matrix multiplication) using the matrix. The positive compile tests should look something like:

    // [config]
    // expect_result: pass
    // glsl_version: 1.00
    // require_extensions: GL_NV_non_square_matrices
    // [end config]
    #version 100
    #extension GL_NV_non_square_matrices: require
    uniform mat2x3 u;
    attribute vec2 v;
    void main() { gl_Position = vec4(u * v, 1.0); }
    

    These tests should go in tests/spec/nv_non_square_matrices/compiler. Be sure to get the vector size of v correct, and be sure to include enough extra components in the vec4 constructor in main. :) You can verify your code by changing the version to 120 and removing the extension line.

  • Write a test that verifies that GL_NV_non_square_matrices is defined and has a value 1. Copy-and-edit tests/spec/amd_shader_trinary_minmax/compiler/define.vert to make the new test. This new test should be tests/spec/nv_non_square_matrices/compiler/define.vert.
  • Write a test (in C) that creates one or more shaders with each of the non-square matrix types added by this extension. Verify that glGetActiveUniform and glGetActiveAttribute each return the correct enum for type.
  • Write a test (in C) that creates one or more shaders with each of the non-square matrix types added by this extension. Call the appropriate glUniformMatrix?x?fvNV function to set each uniform, and call glGetUniformfv to verify that the correct data was set. Also verify that glGetUniformfv doesn't return too many values.
  • Either as a separate test or included with the previous test, verify that calling the wrong glUniformMatrix?x?fvNV function for each uniform generates GL_INVALID_OPERATION.

Be sure to add all piglit tests to tests/all.py!

In Mesa,

  • Create a new file src/mapi/glapi/gen/NV_non_square_matrices.xml that describes the API (functions and enums) added by this extension. xi:include include that file in src/mapi/glapi/gen/es_EXT.xml. CompressedTexImage3DOES and friends in es_EXT.xml will provide a good model for some of the markup. In the same patch, update src/mesa/main/tests/dispatch_sanity.cpp to expect the new functions in OpenGL ES 2.0 contexts.
  • Add code to _glcpp_parser_handle_version_declaration (in src/glsl/glcpp/glcpp-parse.y) to unconditionally define GL_NV_non_square_matrices in an OpenGL ES shader.
  • Add an entry to _mesa_glsl_supported_extensions (in src/glsl/glsl_parser_extras.cpp) for GL_NV_non_square_matrices. The "supported flag" should be dummy_true. Add _mesa_glsl_parse_state::NV_non_square_matrices_enable and _mesa_glsl_parse_state::NV_non_square_matrices_warn flags.
  • Modify _mesa_glsl_initialize_types (in src/glsl/builtin_types.cpp) to add the non-square matrix types if _mesa_glsl_parse_state::NV_non_square_matrices_enable is set.
  • Add an entry to extension_table (in src/mesa/main/extensions.c) to advertise GL_NV_non_square_matrices in ES2 contexts. The offset field should be o(dummy_true).

There are a few other extensions in the ES registry that could get similar treatment:

Implement ARB_clear_buffer_object

Code has landed, but tests are missing. The piglit tests should be fairly easy to add.

  • Make a big pile of "negative" tests. Basically, everywhere in the specification that says "You must do this, that, and the other thing, otherwise the error INVALID_... is generated" or "If you do this bad thing, the error INVALID_... is generated" should have a test case (or subcase) that exercises it. The "Errors" section of the extension specification is a good place to start. Look at the various files tests/spec/**/api-errors.c for examples.
  • Make a test that clears an entire buffer to a specified value. The comparison will probably implemented by glMapBuffer and a loop of memcmp. You may even put this in it's own function in a file that can be shared by other tests in the tests/spec/arb_clear_buffer_object directory.
  • Make a test that clears a subregion of a buffer to a specified value. Check that the cleared region is cleared and the rest of the buffer is not.
  • Repeat the previous test, but perform multiple overlapping and non-overlapping clears.
  • Any other mean tests that you can think of.

Driver-specific projects