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

[Chad Versace]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2012 05:06 PM, Paul Berry wrote:
> 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 <http://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.

Yes, I too think that the best way to support GLES extensions is to simply examine the extension string and ignore the API. If the extension string is present, then, regardless of API, it is safe to obtain the function pointer with *glGetProcAddress.

By the way, (a) and (b) don't hold. Several some EXT extensions exist in both GL and GLES under the same name, and some OES extensions have already been officially ported to GL.

> 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).

I agree. Dispatching EGL and GLX functions, though easy to accomplish within piglit-dispatch's framework, is really outside of its scope. Tests that rely on EGL or GLX extensions should be responsible for calling GetProcAddress(). The problem that piglit-dispatch solves for GL, like you said, is complex and difficult. An equivalent problem doesn't exist for EGL and GLX, and the complexity of resolving functions is so simple that it can be handled on a case-by-case basis by individual tests.

On a forward-looking note, Jose suggested that for Waffle to be truly useful for clients other than Piglit, it needs to implement the equivalent of piglit-dispatch, and I agree. If and when that happens, Waffle will not perform dispatch for GLX, and EGL, because those are exactly the things that Waffle is attemtping to abstract away. If piglit-dispatch were to contain code for dispatching GLX/EGL, and tests relied on it, then that would complicate the transisition of that code from Piglit into Waffle.

> 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.

Take a look at the EGL tests. The small set of GL functions used by those tests should be present in GL and GLES.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPzP+mAAoJEAIvNt057x8iN+wP/2UQeAPe3OKZCn5Csc9kTSVb
tVuR8oFFwlfejfHx5lJUnVxMmgjvdGjD+lVJk2Pjh5eKFh69gPIQD8NSwUz7QyCv
uyyYgyPEFY1VF++8q2XGimVaye1NzIY/7Quvi49sED0WFqVoG2CLw51CvgxvYWLB
JIOaL7U/2S0Fdu4cYdiJ/NpmOcSTitrPaTYcSR6GtSIndr+/pi/tUhjTKzzjstw+
/hWqz41mZkhBPhYJeYMdO+mMVBELVwSxuRpJLPoEIcLf2g0A46OCUR2fPQpWbB4b
qtnUukyiOshSFShTQJ+uKpM0xv0R0fe7wHfwbGJTICez8LRNhVCoO8WNfty5/yls
gZ3bevlWPWQ8Yd4B9C9f+kZME0SfKpwnUw+TAyye8bk0aSt9D3mjiI6wZwRrUfnJ
AvSp0vr+R2Wb+fI2jxmkCz6V6DJyhXPdf/zkb0pmCEiMPbnpuxHbDCkD5nofXBFp
FWb0GDYC2lOvfTJqmo6Y0TmjqGnF9qUtfiOtsVAbTuV/zZ3oUOC44xJQwzNBkkx5
uuJ6PH6HmVxE5XxksidYfM5mtnNm6dGH08g5x1TZAkPtS+SjW2k+aC/MohWuUPWv
GK/AQzSK1Kfzqeyur9OvXeIf528J6a8QKfQaRJ73QZcXaENjWzO9h8ygualaHAI/
nZYo8+8G3uzz9D0ewkjX
=tp2r
-----END PGP SIGNATURE-----