[Piglit] [PATCH 2/2] egl: Add more cases to egl-create-context-invalid-gl-version

Chad Versace chad.versace at linux.intel.com
Fri Nov 9 11:58:47 PST 2012


On 11/08/2012 01:29 PM, Ian Romanick wrote:
> On 11/08/2012 11:00 AM, Chad Versace wrote:
>> Fails on mesa-a196f43 with Intel Sandybridge with:
>>    Created OpenGL ES1 context with invalid version 3.9
>>
>> CC: Ian Romanick <idr at freedesktop.org>
>> CC: Matt Turner <mattst88 at gmail.com>
>> Signed-off-by: Chad Versace <chad.versace at linux.intel.com>
>> ---
>>   tests/egl/spec/egl_khr_create_context/invalid-gl-version.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/tests/egl/spec/egl_khr_create_context/invalid-gl-version.c
>> b/tests/egl/spec/egl_khr_create_context/invalid-gl-version.c
>> index 9bbce5c..c1c2def 100644
>> --- a/tests/egl/spec/egl_khr_create_context/invalid-gl-version.c
>> +++ b/tests/egl/spec/egl_khr_create_context/invalid-gl-version.c
>> @@ -85,6 +85,8 @@ int main(int argc, char **argv)
>>           pass = pass && try_version(0, 0);
>>           pass = pass && try_version(0, -1);
>>           pass = pass && try_version(1, 2);
>> +        pass = pass && try_version(2, 9);
>> +        pass = pass && try_version(3, 9);
>>
>>           EGL_KHR_create_context_teardown();
>>       }
>> @@ -93,6 +95,8 @@ int main(int argc, char **argv)
>>           ran_test = true;
>>           pass = pass && try_version(2, -1);
>>           pass = pass && try_version(2, 1);
>> +        pass = pass && try_version(3, 9);
>> +        pass = pass && try_version(4, 9);
> 
> The could still be a version 3.9 or 4.9 someday.

Fair enough. We still need to test these cases somehow, though,
because when an OpenGL ES 3.9 or 4.9 context is requested Mesa
stupidly returns an OpenGL ES 2.0 context.

Do you suggest that these cases go into my new verify-gl-flavor
test? I honestly don't care where they go as long as they get tested.

> I understand that there is
> still some debate about the use of EGL_OPENGL_ES2_BIT (vs.
> EGL_OPENGL_ES3_BIT_KHR) to create an ES3 context.  Depending on how that gets
> resolved, we may want to check that 3.0 is invalid.

True.

> I also suspect that there will be a follow-on patch that tries various versions
> with EGL_OPENGL_ES3_BIT_KHR...  I wonder what should happen when the application
> sets EGL_OPENGL_ES3_BIT_KHR and requests version 2.0.

The application doesn't set the ES3 bit; libEGL does.
The application only requests the ES3 bit. A correctly
written test should not assume that the EGL_RENDERABLE_TYPE
bitmask contains exactly the bits it requested; libEGL may set
additional unrequested bits.



More information about the Piglit mailing list