diff options
author | Ian Romanick <ian.d.romanick@intel.com> | 2015-01-20 10:21:10 -0800 |
---|---|---|
committer | Ian Romanick <ian.d.romanick@intel.com> | 2019-06-26 08:31:49 -0700 |
commit | 904645808e9fd5a9003e198670af92f274575a0d (patch) | |
tree | 1eb63bd98821935fcc6f7f60a1e7f4561e0fa146 /ci/appveyor | |
parent | 6d132bebe6adbf1e92b806a6dbf2963ea3b9a4a1 (diff) |
Once upon a time, Mesa accidentally enabled GL_ARB_vertex_program in
Core Profile. We fixed that, but continued to export the functions. We
eventually fixed that too. It turns out that, especially in the piglit
framework, it's really hard to verify that a function is not there.
The piglit framework will detect that a function is being called that is
not supported by the implementation, and it will print a friendly
message. We don't want that. We want to call the function specifically
because we know it's not supported. As a result, glXGetProcAddress has
to be used directly.
Using glXGetProcAddress poses two problems. First, it can either return
NULL or it can return a pointer to a dispatch trampoile function. Some
closed-source libGL implementations will return NULL for functions that
they and the associated drivers have never heard of. The open-source
libGL implementations will never return NULL because the application
might later load a new driver that supports the requested function. Try
glXGetProcAddress((const GLubyte *)"glHamsandwich") on your favorite
libGL.
Second, the trampoline function may or may not call a valid function.
Depending on the driver and the libGL the dispatch table entry used by
the trampoline function may:
1. Point at garbage.
2. Point at a default function that always sets GL_INVALID_OPERATION.
3. Point at a real implementation of the function that may or may not
set GL_INVALID_OPERATION.
The only way to determine which you've got is by calling the trampoline
function. In case #1, this will result in some signal (probably either
SIGSEGV or SIGILL) that leads to program termination. By the definition
of the GL spec, this is actually success, so crashing is not a good way
to reflect that. To deal with this a combination of signal and
sigsetjmp are used.
For each function to be tested,
1. Call glXGetProcAddress on the function. If glXGetProcAddress returns
NULL, the function passes.
2. Set signal handlers for every reasonable signal that calling outer
space might generate. The signal handler will siglongjmp back to the
caller.
3. Use sigsetjmp to set the location to which the signal handler should
return.
4. Call the function. If GL_INVALID_OPERATION is set, the function
passes. If the signal handler is invoked, the call to glGetError will
never happen. If any other condition is set, the function fails.
This particular test only calls a subset of the GL_ARB_vertex_program
functions. The remaining functions require that a valid vertex program
be bound. If all the functions included in this test are successful,
either the functions would be too (with possible false positives) or an
api-errors test should detect their failures. Either way, I didn't see
much point in trying them.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Albert Freeman <albertwdfreeman@gmail.com>
Reviewed-by: Albert Freeman <albertwdfreeman@gmail.com>
Diffstat (limited to 'ci/appveyor')
0 files changed, 0 insertions, 0 deletions