This seems to be about allowed and disallowed format combinations for glReadPixels. For some reason 'rgb8_snorm' passes but r8, rg8 and rgba8 fail. Debugging ...

Created attachment 141268 [details] [review]
fix WIP

Attached a patch that makes dEQP happy .. but this makes Piglit test to fail, as that test assumes it is OK to read GL_R8_SNORM, GL_RG8_SNORM with GL_BYTE. I'll need to dig some more to understand what combos are accepted and with what limitations.

I've sent a partial fix to the list:
https://lists.freedesktop.org/archives/mesa-dev/2018-August/203688.html

It looks like rest of the issues are about something else.

Andres, what version of the gles cts are you running?  I can't find the packed_pixels tests in our CI results.

These tests are new in glescts 3.2.5.  Mesa i965 CI was running 3.2.4.  We are updating.

(In reply to Mark Janes from comment #5)
> These tests are new in glescts 3.2.5.  Mesa i965 CI was running 3.2.4.  We
> are updating.

Sorry, I'm too late and you beat me to it.

Next time I will make sure to specify the VK-GL-CTS branch in the report.

Anyway, you are correct, the branch is "opengl-es-cts-3.2.5":
https://github.com/KhronosGroup/VK-GL-CTS/tree/opengl-es-cts-3.2.5

(In reply to Tapani Pälli from comment #3)
> I've sent a partial fix to the list:
> https://lists.freedesktop.org/archives/mesa-dev/2018-August/203688.html
> 
> It looks like rest of the issues are about something else.

Tapani, I can confirm that your patch fixes not just the 3 tests you have listed but the 9 that were failing for me.

Notice that I'm testing the branch "opengl-es-cts-3.2.5" with the wayland target:
https://github.com/KhronosGroup/VK-GL-CTS/tree/opengl-es-cts-3.2.5

(In reply to Andrés Gómez García from comment #7)
> (In reply to Tapani Pälli from comment #3)
> > I've sent a partial fix to the list:
> > https://lists.freedesktop.org/archives/mesa-dev/2018-August/203688.html
> > 
> > It looks like rest of the issues are about something else.
> 
> Tapani, I can confirm that your patch fixes not just the 3 tests you have
> listed but the 9 that were failing for me.
> 
> Notice that I'm testing the branch "opengl-es-cts-3.2.5" with the wayland
> target:
> https://github.com/KhronosGroup/VK-GL-CTS/tree/opengl-es-cts-3.2.5

Hmm OK, I was running against master, will try that branch as well. With master and using 'x11_egl' the R and RG tests still fail for me. It would seem that dEQP thinks reading R and RG is not correct:

--- 8< ------------------
Invalid format used but glReadPixels succeeded for input = [GL_RED, GL_BYTE] output = [GL_RGBA, GL_BYTE]

Invalid format used but glReadPixels succeeded for input = [GL_RG, GL_BYTE] output = [GL_RGBA, GL_BYTE]
--- 8< ------------------

I'll push that patch to Mesa now and will continue investigating why some of these tests still fail for me.

Andrés can you confirm if some of the tests are still failing for you? For Intel CI and for me the r8_snorm and rg8_snorm tests are still failing, I believe this might be actually issue in the test itself. Teh test does not seem to allow R8 and RG8 reads as RGBA output but this should be just fine as the OpenGL ES spec allows reading to to bigger component output.

FYI I've sent a patch for vk-gl-cts to allow reading from GL_BYTE surfaces to output GL_RGBA, GL_BYTE. Let's see how that one goes.

(In reply to Tapani Pälli from comment #9)
> Andrés can you confirm if some of the tests are still failing for you? For
> Intel CI and for me the r8_snorm and rg8_snorm tests are still failing, I
> believe this might be actually issue in the test itself. Teh test does not
> seem to allow R8 and RG8 reads as RGBA output but this should be just fine
> as the OpenGL ES spec allows reading to to bigger component output.

This is pretty awkward :/

Last week, I tested with mesa at 07a227f5438e63c5ebd1c49a272253a6784a69ae plus your patch in mesa-dev applied on top (and some other set of unrelated patches).

With that, all the tests were passing.


This week, with mesa at 2c1f249f2b61be50222411bc0d41c095004232ed (and a similar set of unrelated patches on top), I have similar results than you. These are still failing:
* KHR-GLES3.packed_pixels.pbo_rectangle.r8_snorm
* KHR-GLES3.packed_pixels.pbo_rectangle.rg8_snorm
* KHR-GLES3.packed_pixels.rectangle.r8_snorm
* KHR-GLES3.packed_pixels.rectangle.rg8_snorm
* KHR-GLES3.packed_pixels.varied_rectangle.r8_snorm
* KHR-GLES3.packed_pixels.varied_rectangle.rg8_snorm

--

I don't think it is worth to investigate what was going different on in my side. Let's follow up with the proposed CL for VK-GL-CTS.

As for me, if you are convinced the only problem remaining to be solved is in VK-GL-CTS, you could close this bug as FIXED. We can always reopen if that's not the case.

OK I'm happy to hear we have same results! I'll wait what happens with vk-gl-cts patch.

Following commit in vk-gl-cts should fixes rest of the issues:

--- 8< ---
commit d69355bbc4fb4b1571b4b50baefc46856e8b0911
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Mon Sep 3 10:10:04 2018 +0300

    Allow reading GL_BYTE surfaces to GL_RGBA output.
    
    EXT_render_snorm specification:
    
       "For 8bit signed normalized fixed-point rendering surfaces, the
        combination format RGBA and type BYTE is accepted. For a 16bit signed
        normalized fixed point buffer, the combination RGBA and SHORT is
        accepted.
    
    OpenGL ES 3.1 specification:
       "If G, B, or A values are not present in the internal format, they are
        taken to be zero, zero, and one respectively."
    
    Components: OpenGL ES
    
    VK-GL-CTS issue: 1338
    
    Affects: KHR-GLES3.packed_pixels*snorm
    
    Change-Id: I48df036fc3da80a06e1adef32bd59dac5b551cec
    Signed-off-by: Tapani Pälli <tapani.palli@intel.com>