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

[Ian Romanick]

On 11/09/2012 11:58 AM, Chad Versace wrote:
> 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.

Yes.  That test will catch this error:  the app asks for a 4.9 context, 
but Mesa gives it a 2.0 context.

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

Right... and an implementation that returns a config with just the ES3 
bit set should probably be taken out behind the woodshed...