summaryrefslogtreecommitdiff
path: root/ci/appveyor
diff options
context:
space:
mode:
authorIan Romanick <ian.d.romanick@intel.com>2015-01-20 10:21:10 -0800
committerIan Romanick <ian.d.romanick@intel.com>2019-06-26 08:31:49 -0700
commit904645808e9fd5a9003e198670af92f274575a0d (patch)
tree1eb63bd98821935fcc6f7f60a1e7f4561e0fa146 /ci/appveyor
parent6d132bebe6adbf1e92b806a6dbf2963ea3b9a4a1 (diff)
arb_vertex_program: Verify that unsupported functions generate errorsHEADmaster
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