[Piglit] Piglit and GLES

Chad Versace chad.versace at linux.intel.com
Fri Jul 20 14:46:43 PDT 2012


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

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




More information about the Piglit mailing list