[Piglit] piglit-dispatch for gles

[Chad Versace]

On 01/03/2013 01:31 PM, Tom Gall wrote:
> On Thu, Jan 3, 2013 at 12:48 PM, Chad Versace
> <chad.versace at linux.intel.com> wrote:
>> On 01/03/2013 10:00 AM, Tom Gall wrote:

> What if instead of parsing over the c source file, why not run the
> test with a --tell-me-what-you-support sort of flag?
> 
> Spit out bog standard json in response and that's that.
> 
> ex:
> 
> minmax --q-support
> 
> returns something like:
> {
>     "minmax": {
>         "api": [ 'gl', 'gles'],
>         "gl": [1.0, 3.2],
>         "gles": [2.0, 3.0]
>     }
> }

Agreed. We need something similar to that.


>> Even though there may exist many GL/GLES tests that could fall into the
>> api-specific category, for simplicity we should probably place all GL/GLES
>> into the build-once-and-dispatch-dynamically catgeory. I think that the only
>> tests that should really go into the api-specific category are those that
>> test windowing api's, such as the GLX and EGL tests.
> 
> In theory I agree. I've spent a bit of time looking at candidates for
> porting over to gles or at least seeing what either might be quite
> trivial to get working on gles.
> 
> There's common pitfalls that will hinder a build once and work
> everywhere mantra for GL/GLES beyond missing APIs. For instance, glsl
> vs glsl-es differences like no gl_Vertex, gl_ForegroundColor etc.
> Fairly simple to deal with, but a pain.

I think we have a misunderstanding, or maybe not. I agree with you that the goal
build-once-and-work-everywhere is not attainable for all tests. Instead,
I suggested that, once the final goal is achieved, that all GL and GLES tests would
be built in the same way and link against the same libraries, regardless
of whether they supported a single API or multiple APIs.

In order for a cross-API test to successfully work, it cannot be linked
against any of libGL.so, libGLESv1_CM.so, libGLESv2.so. Instead, it must
be linked against a GL-wrapper library that dynamically dispatches to one
of the above based on the runtime choice of API; that is, it must link
to libwaffle-dispatch.

However, since it's perfectly safe for a single-API test (for example, one
that supports only GL) to dynamically dispatch to libGL through a
wrapper library (in fact, all GL-only tests are currently doing exactly that through
piglit-dispatch), then, in order to keep things simple, we should link all
tests against the dispatch library, even tests that support only a single API.