[Mesa-dev] [PATCH 0/5] GL_OES_required_internalformat

Mark Janes mark.a.janes at intel.com
Fri Aug 11 17:42:00 UTC 2017


Eric Anholt <eric at anholt.net> writes:

> Tapani Pälli <tapani.palli at intel.com> writes:
>
>> On 06/22/2017 02:08 AM, Eric Anholt wrote:
>>> Tapani Pälli <tapani.palli at intel.com> writes:
>>> 
>>>> On 06/14/2017 01:12 AM, Eric Anholt wrote:
>>>>> Tapani Pälli <tapani.palli at intel.com> writes:
>>>>>
>>>>>> On 06/12/2017 09:52 AM, Tapani Pälli wrote:
>>>>>>>
>>>>>>> On 05/18/2017 09:39 PM, Eric Anholt wrote:
>>>>>>>> Eric Anholt <eric at anholt.net> writes:
>>>>>>>>
>>>>>>>>> This series came out of fixing dEQP failures on vc4's GLES2 context.
>>>>>>>>> Mesa was allowing RGB565 textures, which is only valid with
>>>>>>>>> GL_OES_required_internalformat.  Rather than disable RGB565, I decided
>>>>>>>>> the extension was easy enough to support.
>>>>>>>>>
>>>>>>>>> I've sent one piglit test for renderbuffer sizing, and dEQP has tests
>>>>>>>>> for whether enums get accepted for TexImage.
>>>>>>>>>
>>>>>>>>> There's a functional question in patch #2, see the comment there, and
>>>>>>>>> there's a question of whether the extension should be dummy_true in
>>>>>>>>> patch #5.
>>>>>>>>>
>>>>>>>>> branch: https://github.com/anholt/mesa/commits/required-internalformat
>>>>>>>> I would still love review on this series.
>>>>>>>>
>>>>>>> Earlier I took a brief look at series and run through our CI, there were
>>>>>>> many failing tests but t seems I forgot to reply/report .. I'll run it
>>>>>>> again and let you know what's the result.
>>>>>>>
>>>>>> '36 failures' (many likely duplicates of some same issue), these ones ..
>>>>>>
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.bdwm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pbo.bdwm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pixelstore.hswm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.sklm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pbo.sklm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.bdwm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pixelstore.bdwm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels.hswm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pixelstore.sklm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.color0.rgb10.hswm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.hswm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.hswm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels_pbo.hswm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.color0.rgb10.bdwm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels.bdwm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.sklm64
>>>>>> ES3-CTS.functional.fbo.completeness.renderable.texture.color0.rgb10.sklm64
>>>>>> ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels.sklm64
>>>>>> ES2-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.bdwm64
>>>>>> ES2-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.sklm64
>>>>>> ES2-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.bdwm64
>>>>>> ES2-CTS.functional.fbo.completeness.renderable.texture.depth.rgb10.hswm64
>>>>>> ES2-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.hswm64
>>>>>> ES2-CTS.functional.fbo.completeness.renderable.texture.stencil.rgb10.sklm64
>>>>>>
>>>>>> piglit.spec.oes_texture_float.oes_texture_float half.g965m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float.g965m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float half linear.g965m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float linear.g965m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float half.g45m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float half linear.g45m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float linear.g45m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float.g45m64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float.ilkm64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float half linear.ilkm64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float half.ilkm64
>>>>>> piglit.spec.oes_texture_float.oes_texture_float linear.ilkm64
>>>>>>
>>>>>> Are you able to reproduce/run these tests on some machine?
>>>>> I have a SKL desktop, so I reproduced the GLES2 rgb10 failure and fixed
>>>>> it, and I think I've fixed the pre-snb failures in piglit.  New branch
>>>>> up at https://github.com/anholt/mesa/commits/required-internalformat
>>>>> which I'll piglit now.
>>>>
>>>>
>>>> OK, seems the packed_pixels ones are still failing. I'll try to debug
>>>> this a bit to see what's going on.
>>> 
>>> Have you had a chance to look at this at all?  Or could you give me a
>>> command line for reproducing failure?  I've gone through my VK-GL-CTS
>>> tree and DEQP trees trying various test runners with various manglings
>>> of the names, with no luck.
>>> 
>>
>> Sorry I've forgotten this thread .. the 'CTS' ones are from Khronos 
>> 'OpenGL & OpenGL ES CTS' (available in gitlab) which is run by Jenkins, 
>> are you able to access that suite?
>
> If you mean the "OpenGL & OpenGL ES Conformance Test Suite" in gitlab
> (git at gitlab.khronos.org:opengl/cts.git), that repository says:
>
> "This project is moved to maintenance mode.
>
> Use VK-GL-CTS for development, bug fixes"
>
> Are you sure that's the repository you're using?

My understanding is that all the cts suites will be moving into
https://gitlab.khronos.org/Tracker/vk-gl-cts

However, that repository isn't ready yet.  I tried to use it to add
OpenGL 4.6 tests to our CI, and couldn't build the suite.  I was told
that a release branch for GL CTS testing would be made when the 4.6
tests are finalized.

Intel CI is just looking for regressions, so we use the sources that
made the last CTS tarballs.  We do track dEQP and VulkanCTS development
branches, because we have found them to be stable enough for CI.  For
dEQP, we only run tests which are not duplicated in the CTS tarballs.
Since new tests are often developed in dEQP, this *should* help us
conform whenever the vk-gl-cts repo is ready.

The packed_pixel tests were part of the CTS before dEQP was added.  It's
possible that there is a bug in the tests, but we should confirm before
merging patches that could break our conformance.

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list