Folks-- I am working up an alternative proposal for how to integrate GLES support into piglit-dispatch. The basic idea is to add annotations to the existing gl.spec file to indicate which functions are present in GLES (and in which versions of GLES they are present), have parse_glspec.py record that info in the glapi.json file, and have gen_dispatch.py use that information to generate calls to a new function "check_api(...)", so that it can dispatch differently depending on whether the GL, GLES 1.0, or GLES 2.0 API is present. I have a patch series on my github (git://<a href="http://github.com/stereotype441/piglit.git">github.com/stereotype441/piglit.git</a>) in the "gles" branch. It's not thoroughly tested yet, and I need to improve the commit comments before I send it to the list, but I wanted to give people (especially Chad and Pauli) a chance to comment early. I haven't yet written the glue logic to cause piglit-dispatch to be initialized with the same API that's being used to configure Waffle, so these patches won't have any effect yet (the code will still dispatch assuming the API is desktop GL). Tomorrow I'll try to do that integration. Here's an example of the old and new generated code for the AttachShader function: Old: /* glAttachShader (GL 2.0) */ /* glAttachObjectARB (GL_ARB_shader_objects) */ static piglit_dispatch_function_ptr resolve_glAttachShader() { if (check_version(20)) piglit_dispatch_glAttachShader = (PFNGLATTACHSHADERPROC) get_core_proc("glAttachShader", 20); else if (check_extension("GL_ARB_shader_objects")) piglit_dispatch_glAttachShader = (PFNGLATTACHOBJECTARBPROC) get_ext_proc("glAttachObjectARB"); else unsupported("AttachShader"); return (piglit_dispatch_function_ptr) piglit_dispatch_glAttachShader; } New: /* glAttachShader (GL 2.0) */ /* glAttachShader (GLES 2.0) */ /* glAttachObjectARB (GL_ARB_shader_objects) */ static piglit_dispatch_function_ptr resolve_glAttachShader() { if (check_api(PIGLIT_DISPATCH_GL) && check_gl_version(20)) piglit_dispatch_glAttachShader = (PFNGLATTACHSHADERPROC) get_core_proc("glAttachShader", 20); else if (check_api(PIGLIT_DISPATCH_ES2)) piglit_dispatch_glAttachShader = (PFNGLATTACHSHADERPROC) get_core_proc("glAttachShader", 20); else if (check_extension("GL_ARB_shader_objects")) piglit_dispatch_glAttachShader = (PFNGLATTACHOBJECTARBPROC) get_ext_proc("glAttachObjectARB"); else unsupported("AttachShader"); return (piglit_dispatch_function_ptr) piglit_dispatch_glAttachShader; } Note that currently my patch series only handles functions that are common to GLES and GL. Functions that only exist in GLES (e.g. glClearColorx) aren't handled yet--I figured it would be best to get shared functions working first since they require less effort. Also, functions that are defined in a GLES extension aren't supported yet, however I expect that the best way to do that will be to use piglit-dispatch's existing mechanism to dispatch to functions based on extensions. There's no need to educate piglit-dispatch as to which extensions go with GLES and which extensions go with GL, because (a) the GLES extensions are uniquely named, so there's no need, and (b) it's conceivable that a GL implementation might implement a GLES extension or vice versa, and if that happens we want Piglit to be able to test the extension even when it's implemented through an unexpected API. Also note that I'm not going to any effort to run EGL functions through the piglit-dispatch mechanism. I don't think that would be worth the effort, since the situation that makes piglit-dispatch worthwhile for GL functions doesn't exist with EGL (that is, there are GL functions that have identical counterparts in GLES1, GLES2, or extensions, sometimes exported under different names, so we want to be able to write a single test that tests all variations without having to manually write code in each test to call the proper functions depending on what API is in use and what extensions the implementation supports. That situation doesn't exist in EGL). Questions: - Does it seem reasonable to you folks to do the dispatch to different APIs completely at run-time like this? - What would be an appropriate set of tests to try these patches out with? I had a look at tests/all_es1.tests and tests/all_es2.tests and they are remarkably tiny. Also I noticed that there is a gles2_shader_runner executable, but it looks like it is unused. Thanks in advance for your input, Paul