[Mesa-dev] [Bug 99638] Mesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC64

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Feb 14 08:55:51 UTC 2017


https://bugs.freedesktop.org/show_bug.cgi?id=99638

--- Comment #15 from Pekka Paalanen <ppaalanen at gmail.com> ---
All-blue weston looks to me like alpha and blue channels are swapped. Can't say
about red/green since the colors are gray. I couldn't say what the other
pictures are supposed to look like.

Weston has known issues on big-endian, IIRC the conversion between wl_shm and
OpenGL formats is broken on big-endian. I have a vague recollection that there
might not exist a matching GLESv2 format on big-endian, which means it would
have to be compensated in frag shaders, which I don't think we do.

While Mesa's platform_wayland.c certainly looks suspicious, there could be
similar problems in the Wayland compositors too.

Also the problem may be different between software-GL in clients (uses wl_shm)
and hardware-GL in clients (uses EGL-specific protocol, the Wayland compositor
has no room to screw that up as everything is inside the EGL implementation).

Yet one more place to possibly screw things up is GBM/KMS used by the Wayland
compositor, where the composite drawn with GL is exported via GBM as a buffer
handle to used in KMS. That involves choosing pixel formats when creating the
GBM/EGLsurface, and relaying the pixel format to KMS.

OTOH if Weston is using Pixman renderer with the DRM backend, there cannot be
confusion with GL formats in Weston. But, it is again a rarely (if ever) tested
code path on big-endian like everything. Using Pixman renderer would force
applications to use software-GL.

There are so many different combinations that one really needs to choose just
one to concentrate on at a time. If you want to work with Weston, maybe start
with DRM backend and Pixman renderer, using programs that do *not* use OpenGL,
make sure that works right, and then add complexity piece by piece. I think
weston-simple-shm would be a nice test, as getting the byte order wrong would
cause a cross to be drawn over the image which is otherwise unhelpful for
checking if colors are correct.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170214/8427b100/attachment.html>


More information about the mesa-dev mailing list