Created attachment 248268 [details]
Expected Results

Created attachment 248269 [details]
Actual Results

Thanks for the bug report. All of the tests seem to be running fine for me under Wayland. Would you be able to run one of the tests directly to see if it outputs any more information about the cause? For example, you could run one of them like this:

export COGL_RENDERER=egl_wayland
export COGL_DRIVER=gl3
./test-backface-culling

Also, note that you should be able to just run ‘make test’ from the tests directory instead of running the run-tests script directly. This should also make it run the unit tests which do white-box testing in addition to the black-box conformance tests.

Created attachment 248317 [details]
actual results - verbose

Here are more verbose test results from our test driver script.

(In reply to comment #3)
> Thanks for the bug report. All of the tests seem to be running fine for me
> under Wayland. ...

Did you try using the same s/w stack as I reported the issue for?  If you can verify that it still works fine for you on that s/w stack then I can investigate further.

Can you perhaps try rolling back just your mesa version to 15436adab0ae2d ?

Over the weekend I was seeing some big problems running Rig with mesa master and after a long git bisect I was lead to this range of bad Mesa commits:

329cd6a9b145d5b3b5a2acca1b6c2019d01c9355
b7d9478f36bde0f7b27321378c1bb799fdd4eaa1
c170c901d0f5384e5ab8b79b827663fa28439b0b
fc32d40534d1794453a71f249cadd2e1d05b692c

(A range because none of them successfully build for me)

I ended up rolling my mesa version back to 15436adab0ae2d and since it looks like the version of mesa you are using is later than that I have a sneaky suspicion you might be hitting Mesa bugs.

(In reply to comment #6)
> Can you perhaps try rolling back just your mesa version to 15436adab0ae2d ?

Hmmm... that Mesa commit doesn't compile for me:

wayland (master) 1.1.91-0-g3f3671e
fontconfig (master) heads/master-0-g04bd904
drm (master) heads/master-0-gf8f1f6e
mesa (master) heads/master-0-g15436ad
libxkbcommon (master) heads/master-0-g6f06eb5
pixman (master) heads/master-0-g279bdcd
cairo (master) heads/master-0-g2cc353c
weston (master) heads/master-0-g324b4c3
cogl (cogl-1.16) heads/cogl-1.16-0-gb2452e2

I get:

from ../../../src/mapi/entry.c:63:
../../../src/mapi/glapi/glapi_mapi_tmp.h:1203:45: error: conflicting types for 'glMultiDrawElementsEXT'
In file included from ../../../include/GL/gl.h:2070:0,
from ../../../src/mapi/glapi/glapi_mapi_tmp.h:15,
from ../../../src/mapi/mapi_tmp.h:1,
from ../../../src/mapi/entry.c:63:
../../../include/GL/glext.h:6640:45: note: previous declaration of 'glMultiDrawElementsEXT' was here
In file included from ../../../src/mapi/mapi_tmp.h:1:0,
from ../../../src/mapi/entry.c:63:
../../../src/mapi/glapi/glapi_mapi_tmp.h:9470:45: error: conflicting types for 'glMultiDrawElementsEXT'
In file included from ../../../include/GL/gl.h:2070:0,
from ../../../src/mapi/glapi/glapi_mapi_tmp.h:15,
from ../../../src/mapi/mapi_tmp.h:1,
from ../../../src/mapi/entry.c:63:
../../../include/GL/glext.h:6640:45: note: previous declaration of 'glMultiDrawElementsEXT' was here
error: status 1 from /usr/lib64/ccache/gcc
gmake[3]: *** [entry.lo] Error 1


Perhaps I'll rollback a few more

(In reply to comment #6)
> Can you perhaps try rolling back just your mesa version to 15436adab0ae2d ?
> 
> Over the weekend I was seeing some big problems running Rig with mesa master
> and after a long git bisect I was lead to this range of bad Mesa commits:
> 
> 329cd6a9b145d5b3b5a2acca1b6c2019d01c9355
> b7d9478f36bde0f7b27321378c1bb799fdd4eaa1
> c170c901d0f5384e5ab8b79b827663fa28439b0b
> fc32d40534d1794453a71f249cadd2e1d05b692c
> 
> (A range because none of them successfully build for me)
> 
> I ended up rolling my mesa version back to 15436adab0ae2d and since it looks
> like the version of mesa you are using is later than that I have a sneaky
> suspicion you might be hitting Mesa bugs.

Since I could not get Mesa to compile with 15436adab0ae2d I switched to the 9.1 Mesa branch (and keeping all else equal).  After that, all the test regressions disappeared.

Thus, your sneaking suspicion about hitting Mesa (master) bugs is likely correct.

Ok, thanks for checking.

Curious that the build error you got looks like what I remember seeing for the other bad commits that caused me a problem when bisecting, but 15436adab0ae2d built ok for me.

Anyway, I suppose this means it's ok to close this as resolved NOTABUG, but no doubt we're going to have to keep an eye on mesa development and perhaps use one of our conformance tests to file a mesa bug instead.

This mesa bug is likely related: https://bugs.freedesktop.org/show_bug.cgi?id=66292

Created attachment 251958 [details] [review]
gl: bind position attribute to location 0

It turns out there was a bug in mesa and cogl causing these failures.

Mesa had some problems dealing with the special behaviour of attribute 0 in some cases which have now been fixed in master (41eef83cc030e7) and the 9.2 branch (24d1949ddcd)

The problem in cogl was that we were always relying on the gles 2 semantics that there is nothing special about generic attribute 0. With big GL though you're required to associate attribute 0 with your position attribute.

The attached patch makes sure we always explicitly call glBindAttribLocation to bind cogl_position_in to location 0 which seems to fix the remaining failures for me.

I've re-opened this bug until the attached patch gets reviewed and landed

(In reply to comment #11)
> Created an attachment (id=251958) [details] [review]
> gl: bind position attribute to location 0
> 
> It turns out there was a bug in mesa and cogl causing these failures.
> 
> Mesa had some problems dealing with the special behaviour of attribute 0 in
> some cases which have now been fixed in master (41eef83cc030e7) and the 9.2
> branch (24d1949ddcd)
> 
> The problem in cogl was that we were always relying on the gles 2 semantics
> that there is nothing special about generic attribute 0. With big GL though
> you're required to associate attribute 0 with your position attribute.
> 
> The attached patch makes sure we always explicitly call glBindAttribLocation to
> bind cogl_position_in to location 0 which seems to fix the remaining failures
> for me.

This patch worked for me too :)

ok, I've landed this patch in master and the cogl-1.16 branch. thanks for testing.