On Mon, Dec 17, 2012 at 12:54 PM, Chad Versace
<chad.vers...@linux.intel.com> wrote:
> On 12/14/2012 12:01 PM, Tom Gall wrote:
>> Add GLSLESParserTest class which runs the gles2/gles3
>> version of glslparsertest. Why is this needed?
>> The current GLSLParserTest class doesn't know about the
>> gles2/gles3 varient of glslparsertest. The versioning
>> of glsl_version in the config section of frags and vert
>> shaders is conceptually incompatible for the GLSL ES
>> versions.
>>
>> Consider. GLSL ES version 1.00 is approx equal to
>> GLSL 1.20. However there are situations where
>> a testcase that will pass on GLSL 1.20 but will fail
>> under GLSL ES 1.00.
>>
>> Ex: tests/glslparsertest/shaders/CorrectConstruct.vert
>> Embedded structure definitions are not allowed in GLSL ES
>> 1.00 but are perfectly legal in GLSL 1.10. For both GLSL
>> and GLSL ES this is a good testcase.
>>
>> This creates a situation where version comparisons between
>> verions 1.00, 1.10, 1.20, etc just isn't going to work and
>> expected results can be different for the same testcase.
>>
>> To deal with this situation, GLSLESParserTest looks for
>> glsles_version in the config section. If not found, the
>> test is skipped. If found, this version is passed into
>> the glsl es version of glslparsertest.
>>
>> glsles_expect_result is also added as an option entry
>> in the config section. If it is not present the
>> expect_result is the same for GLSL and GLSL ES. If
>> present the glsles_expect_result is passed into the
>> appropriate GLSL ES version of glslparsertest.
>>
>> Signed-off-by: Tom Gall <tom.g...@linaro.org>
>> ---
>> framework/glsl_es_parser_test.py | 377
>> ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 377 insertions(+)
>> create mode 100755 framework/glsl_es_parser_test.py
>
> Nak. Rather than forking glslparsertest.py for only a minimal set of changes,
> I think a better approach is to modify the existing glslparsertest.py.
> However,
> exactly which modifications are needed for glslparsertest.py will be
> determined
> by the resolution of a larger design decision: how should we add the gles2
> glslparser tests to all.tests?
Well the "fork" could extend the GLSLParserTest and a majority of what
is copied thrown away. My python is a little rusty but I think it'd be
reasonable to do and was going to get after that sometime
today/tomorrow.
> Do you already have a plan on how to add the gles2 glslparser tests to
> all.tests?
Yes. With the code as proposed in these patches, it's as simple as:
# Add all shader source files in the directories below for gles20
for filename in os.listdir(testsDir + '/glslparsertest/shaders'):
ext = filename.rsplit('.')[-1]
if ext in ['vert', 'geo', 'frag']:
add_glsl_es_parser_test(gles20, path.join(testsDir,
'glslparsertest/shaders', filename), filename)
del gles20['CorrectPreprocess11.frag']
for filename in os.listdir(testsDir + '/glslparsertest/glsl2'):
ext = filename.rsplit('.')[-1]
if ext in ['vert', 'geo', 'frag']:
add_glsl_es_parser_test(gles20, path.join(testsDir,
'glslparsertest/glsl2', filename), 'glsl2/' + filename)
> I see a ideal solution, but to achieve it will take some time. It requires
> adding
> gles support to piglit-dispatch, building only one glslparsertest executable,
> and letting the executable iterate over all GLSL versions declared in the
> config
> block, printing a result for each. In this solution, all.tests needed no
> changing.
I'm guessing to what you're referring to is setting api in
piglit_dispatch_init. Then would one pass in some sort of API flag to
switch between the GL and GLES worlds?
> Nevermind my longterm solution. You want a solution now.
It's something I think about. I want the "right thing." Thus far for
the gles2 items I've proposed I'd like to think all of this can fit
into the long term solution. I'm certainly more than willing to help
out on the long term solution.
> If all proposed shorterm solutions for adding gles2 glslparser tests to
> all.tests
> prove too difficult or too messy, then we could just postpone their addition
> until
> my proposed solution arrives.
agreed. I'm maintaining my gles2 work on git.linaro.org so it's not
like those that have an interest can't utilize it if they want to.
Still for what makes sense I'd like to see it merged.
> In that fallback scenario, we could just create a separate
> gles2_glslparsertests.tests. I don't like that fallback, but we shouldn't rule
> it out as an option. I'd rather see the gles2 glslparser tests added to
> all.tests
> as soon as possible.
I do have an all_es2.tests. That could fit the bill short term. Or
maybe it really should be all_es.tests for all versions of gles.
--
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
_______________________________________________
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
