[Piglit] Piglit and GLES

[Ian Romanick]

On 07/20/2012 02:46 PM, Chad Versace wrote:
> (Redirecting to the piglit list).
>
> On 07/20/2012 01:03 PM, Stuart Abercrombie wrote:
>> Hi,
>>
>> I was trying to get shader_runner doing something useful with GLES.
>>
>> I see there's gles2_shader_runner.c, but that seems to be old and not
>> under active development.  Is it worth working with this source or is
>> the GL shader_runner.c a better starting point?
>
> gles2_shader_runner.c was abandoned by its author. If possible, I would like to
> see shader_runner.c work with GLES shaders.
>
>> One issue I hit was with GLSL versions.  Given the divergence of
>> GL/GLES GLSL, I'm assuming each shader_test file would need a new
>> "GLES2 GLSL" field to specify what it needs.  (There's a minor bug
>> with parsing the GLES GLSL version string but that's easily solved.)
>>
>> What seems to be more of a problem is the use of built-in attributes.
>> All the shader tests seem to use gl_Vertex, etc. for basic drawing.  I
>> am not sure how to approach this problem.  It seems it might work to
>> define the same names as user attributes, but gles2_shader_runner
>> binds PIGLIT_ATTRIB_POS to "piglit_Position".cv p
>>
>> I suppose the most basic question is whether you envisaged some subset
>> of the shader_test files working with both APIs, or a new set of
>> shader_test files dedicated to GLES.
>
> I would like to see reuse of tests wherever possible. However, with GLSL,
> sometimes that's difficult to achieve.
>
> With some massaging and preprocessing, we should be able to get many of the GL
> shader runner files compatible with GLES. I don't have a firm idea of what the
> approach should look like, and no one I speak to seems to either.
>
> One idea is to remove the #version statements from shader runner files that we
> wish to be portable, and let shader_runner insert the #version statement in a
> preprocessing stage. We could modify the requirements section to allow
> specification of multiple language versions, and shader_runner would insert the
> #version statement appropiately. This doesn't solve the builtin variable
> problem, though...
>
> To solve the builtin variable problem, perhaps we can systematically, in those
> shader runner files we wish to be portable, replace builtin variables like
> gl_Vertex with piglit_Vertex. Again, shader_runner would patch the shader source
> if necessary during preprocessing.

This is another thing we had talked about automating.  We want to be 
able to test built-in names and user-defined names in most shaders. 
Having $VERTEX$ or $TEXCOORD0$ be automatically replaced would be useful.

> If you better ideas, though, let's go with them instead.
>
> -Chad
>
>
>
>> On Thu, Jul 19, 2012 at 5:58 PM, Chad Versace
>> <chad.versace at linux.intel.com> wrote:
>>> On 07/19/2012 02:00 PM, Stéphane Marchesin wrote:
>>>> Hi Chad,
>>>>
>>>> Stuart (CC'd) has been working on bringing up some GLES testing coverage. He ran
>>>> into some problems while trying to run shaders in a more portable fashion (he
>>>> can fill in on the details). Do you think it's doable and a worthy goal?
>>>>
>>>> Stéphane
>>>
>>> This goal is definitely worthy. It has been on our team's wishlist for over a year.
>>>
>>> A closely related goal that I and Paul Berry have been working towards this year
>>> is to enable a single test source file to be able to run under GL and GLES.
>>> We're still working slowly towards that when we find time between high-priority
>>> tasks. A prerequisite for that goal, of course, is to use portable shaders for
>>> common tasks.
>>>
>>> Stuart, please share the details.
>>>
>>> -Chad