dri/ PartiallyAliasedFunctions

Problem Statement

There are a few functions in OpenGL that are functional aliases of each other but do not share GLX protocol. glGenTexturesEXT and glGenTextures are an example. From the point of view of an application or a direct rendering driver, these two functions are identical. From the point of view of an indirect rendering library, these two functions are as different from each other as glGenBuffers and glGenQueries.

There are a total of 17 pairs of functions that have this mismatch. They are:

  • GL_EXT_convolution:
    • glGetConvolutionFilterEXT / glGetConvolutionFilter
    • glGetConvolutionParameterfvEXT / glGetConvolutionParameterfv
    • glGetConvolutionParameterivEXT / glGetConvolutionParameteriv
    • glGetSeparableFilterEXT / glGetSeparableFilter
  • GL_EXT_histogram:
    • glGetHistogramEXT / glGetHistogram
    • glGetHistogramParameterfvEXT / glGetHistogramParameterfv
    • glGetHistogramParameterivEXT / glGetHistogramParameteriv
    • glGetMinmaxEXT / glGetMinmax
    • glGetMinmaxParameterfvEXT / glGetMinmaxParameterfv
    • glGetMinmaxParameterivEXT / glGetMinmaxParameteriv
  • GL_EXT_texture_object:
    • glAreTexturesResidentEXT / glAreTexturesResident
    • glDeleteTexturesEXT / glDeleteTextures
    • glGenTexturesEXT / glGenTextures
    • glIsTextureEXT / glIsTexture
  • GL_SGI_color_table:
    • glGetColorTableSGI / glGetColorTable
    • glGetColorTableParameterfvSGI / glGetColorTableParameterfv
    • glGetColorTableParameterivSGI / glGetColorTableParameteriv Since these functions are different for the indirect rendering case, each function has its own slot in the dispatch table. This factor must be correctly handled by drivers exposing both versions of the function. Due to the way that Mesa implements GL 1.2 and GL_ARB_imaging, nearly all of the drivers expose both functions in all 17 pairs. This results in extra, unnecessary code.

Solution

The solution has two parts. For direct rendering drivers and software-only Mesa, the EXT version of the function is treated as an alias of the core version. The indirect rendering library will generate a special stub for the EXT version. The existing dispatch stubs simply look up a function pointer in the dispatch table and jump to the function. For these EXT functions, the dispatch stub will first determine whether or not the current context is a direct rendering context. If the current context is direct rendering, the stub will look up the aliased function in the dispatch table and jump to it. if the current context is indirect rendering, the stub will emit GLX protocol for the EXT version.

Since all of these functions involve a round-trip to the server, the performance impact of the added tests should be unmeasurably small.

Implementation

At a minimum, the following code generator scripts would need to be changed:

  • gl_procs.py (Generates the table used by glXGetProcAddress) - Would need some fairly significant change. On systems where the dispatch functions are fixed-size (e.g., x86, x86-64 with TLS), a pointer to the dispatch stub is not stored in the table.
  • glX_proto_send.py (Generates code to send GLX protocol) - Needs to generate dispatch stubs for the EXT versions of the functions. These special stubs are described above.
  • glX_proto_recv.py (Generates code to receive GLX protocol) - Generate special code for the matched pairs. Since the relies are the same for both functions in the pair, the initial stub for each function would decode the inputs then call a secondary function that does the real work.
  • glX_server_table.py (Generates the server's GLX protocol decode tables) - Needs to be smart enough to treat aliased functions with different opcodes as different functions.