[regression] Software client windows appear all-black on wily desktop

Description:
After update mesa from 11.0.1-1 to 11.0.2-1 in Weston (launched from the console or 'X') all the windows black (see screenshot: https://i.imgur.com/Oe5X0en.png). After downgrading mesa package weston work fine.

Additional info:
* Problem mesa version: 11.0.2-1
* Weston 1.9
* Weston running from the 'X': http://pastebin.com/jksF4DT4
* ArchLinux
* Intel I4700HQ + Intel Graphics HD 4600 + NVIDIA 850m

Assumption:
I think that to blame the following correction in mesa:
http://mesa3d.sourceforge.net/relnotes/11.0.2.html
> i965: Respect stride and subreg_offset for ATTR registers

My mesa snapshot happened to have the commit mentioned above, but weston was okay. Updated mesa to current HEAD, and the problem described happened.

Reverting 5edd996 (mesa: Use the effective internal format instead for validation) helps, so it should be the problematic commit.

There appear to be two potential problems here. One is that Weston tries to use GL_EXT_abgr in ES even though it is not an ES extension. The second is that mesa advertises it and then falls over when you try to use it. If we weren't advertising it, Weston would fall back to other paths and be OK. I see two options:

 1) Actually support the extension even though it isn't technically an ES extension.
 2) Stop advertising it.

I'm going to hazard a guess and say that mesa is probably the only ES driver to support GL_EXT_abgr.

Thoughts?

(In reply to Jason Ekstrand from comment #2)
> I'm going to hazard a guess and say that mesa is probably the only ES driver
> to support GL_EXT_abgr.
>
Sounds about right according to ilia's glxinfo list

http://people.freedesktop.org/~imirkin/glxinfo/

*** Bug 92242 has been marked as a duplicate of this bug. ***

Spotted this report after bisecting :(

So, I can confirm the same behaviour under kde5/gentoo/qt-5.4.2: black windows, and the commit that cause the problem seems to be

commit f15a7f3c6e1bb802ae8c2a29a2dc35ff530aea4d
Author: Eduardo Lima Mitev <email address hidden>
Date: Thu Sep 24 10:57:43 2015 +0200

    mesa: Use the effective internal format instead for validation
[...]

*** Bug 92247 has been marked as a duplicate of this bug. ***

I don't think you mean GL_EXT_abgr, I don't see Weston using that.

Weston is using GL_BGRA_EXT format, when GL_EXT_texture_format_BGRA8888 extension is available. Weston's GL-renderer refuses to start without this extension.

I believe this is because GL_BGRA_EXT, GL_UNSIGNED_BYTE matches the WL_SHM_FORMAT_XRGB8888 and WL_SHM_FORMAT_ARGB8888 layouts, so we can avoid a conversion.

Eduardo, the faulty commit (breaking KDE/kwin and weston) has landed a week+ ago. Will you have a chance to look into it soon ? Alternatively I'll revert this for stable - 11.0.3 (coming in 2-3 days).

Created attachment 118744
Stderr from running weston-launch

Also hitting something like this, black screen on weston-launch. I believe this may be the same thing? Attaching stderr output for verification. I'm running on Centos 7, same versions of weston and mesa I can build an older version of mesa if necessary to test.

I just sent a patch to the list that fixes this bug:

http://lists.freedesktop.org/archives/mesa-dev/2015-October/096511.html

(In reply to Emil Velikov from comment #8)
> Eduardo, the faulty commit (breaking KDE/kwin and weston) has landed a week+
> ago. Will you have a chance to look into it soon ? Alternatively I'll revert
> this for stable - 11.0.3 (coming in 2-3 days).

I'm currently on holidays and away from my dev laptop until next Tuesday. I will tell somebody from my team to keep an eye on this.

I took a quick look at Jason patch and it looks good. Thought I would have preferred to avoid adding the check for GL_BGRA_EXT inside the block that resolves the effective internal format. I wish there was a way to do the same either inside _mesa_base_tex_format() or later down in _mesa_es3_error_check_format_and_type. But I would need more time to think on another way. So I would go ahead with that patch now.

Since I cannot test it here, I would let somebody else review it (if it is not done already).

Sorry for the regression and the bad timing with me on holidays.

I pushed the fix. Thanks to Ian for a quick review!

*** Bug 92342 has been marked as a duplicate of this bug. ***

No piglit, dEQP, or CTS tests indicated this regression. However, a major consumer of Mesa was debilitated due to this bug.

This bug cannot be marked fixed until there exists a piglit test which prevents future regressions of this type.

The KDE problem is indeed fixed in Mesa 11.0.3. Thanks!

(In reply to Mark Janes from comment #14)
> No piglit, dEQP, or CTS tests indicated this regression. However, a major
> consumer of Mesa was debilitated due to this bug.
>
> This bug cannot be marked fixed until there exists a piglit test which
> prevents future regressions of this type.

I agree we must have a piglit test for this to avoid regressions in the future. I will provide one ASAP.

I just sent for review a piglit test that checks that the combination of internalFormat=GL_BGRA_EXT, format=GL_BGRA_EXT and type=GL_UNSIGNED_BYTE is valid on TexImageXD and TexSubImageXD, as specified by the extension <https://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_format_BGRA8888.txt>:

http://lists.freedesktop.org/archives/piglit/2015-October/017535.html

This should prevent this regression in the future.

However, this test doesn't pass on master because current handling of GL_BGRA format allows for this invalid combination (which is checked in the test):

internalFormat=GL_RGBA format=GL_BGRA_EXT and type=GL_UNSIGNED_BYTE

or

internalFormat=GL_BGRA_EXT format=GL_RGBA and type=GL_UNSIGNED_BYTE

So I also sent a patch to mesa-dev that improves this and make the test pass:

http://lists.freedesktop.org/archives/mesa-dev/2015-October/097211.html