[Piglit] RFC: Alternative way of integrating GLES into piglit-dispatch

[Paul Berry]

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://
github.com/stereotype441/piglit.git) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20120530/2d763f7b/attachment.htm>