Big Endian seems to flip some results breaking self tests
Hi,
I have found the self tests on 0.8.1 repeatedly fail on s390x on Ubuntu builds with the following:
4/6 test_virgl_cmd FAIL 0.57 s (exit status 1)
--- command ---
/root/virglrenderer-0.8.1/obj-s390x-linux-gnu/tests/test_virgl_cmd
--- stdout ---
Running suite(s): virgl_clear
71%: Checks: 7, Failures: 2, Errors: 0
../tests/test_virgl_cmd.c:130:F:clear:virgl_test_clear:0: Assertion 'ptr[i] == 0xff00ff00' failed: ptr[i] == 16711935, 0xff00ff00 == 4278255360
../tests/test_virgl_cmd.c:219:F:clear:virgl_test_blit_simple:0: Assertion 'ptr[i] == 0xff00ff00' failed: ptr[i] == 16711935, 0xff00ff00 == 4278255360
--- stderr ---
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
GLSL feature level 330
libEGL warning: No hardware driver found, falling back to software rendering
gl_version 33 - core profile enabled
It seems broken the same way in Debian and Ubuntu
I have tried to run that individually like
$ VRENDTEST_USE_EGL_SURFACELESS=1 ./obj-x86_64-linux-gnu/tests/test_virgl_cmd
Let me know if that is wrong, but it works on x86 that way and on s390x reports the same assertions as the full test-suite.
I have LXD containers on x86 and s390x and can recreate the issue. But atm I fail to realize what I'm looking for being list int he virgl abstractions. I could modify the code or run things with gdb as needed - please let me know.
Since it is s390x could it be a big-endian issue? The biggest pointer to suggest endian are the values itself the assert reports: The result is 16711935, and expected is ff00ff00, but look at this in binary.
expected: 11111111000000001111111100000000
Result: 00000000111111110000000011111111
So the value is flipped, but is it big-endian or something else. And even if it is "just big endian", where to fix ...?
That is why I'm reaching out to you.