-----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----- _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
