[Piglit] piglit-dispatch for gles

[Tom Gall]

On Fri, Jan 4, 2013 at 11:56 AM, Chad Versace
<chad.versace at linux.intel.com> wrote:
> 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.

Ok cool. I'll start coding up some patches for consideration.

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

Yup agreed. 'nuff said.

--
Regards,
Tom

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Graphics Working Group | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
h) tom_gall att mac.com