Bug 99638

I have more screenshots but can only insert one example.
Qemu sdl or gtk,gl=on gave blue color
Kubuntu task bar, desktop and icon is blue.

Created attachment 129355 [details]
more screenshots

Would be nice to establish if the issue is specific to any driver/hardware.
Do try with the classic, gallium swrast and/or others.

Fwiw there's been an ancient "all the PPC issues on radeons" report at bug 72877.

Do _not_ jump to that bug, repeating "me too", but consider the comments and see if they apply/are useful here.

Hi Emil,
yes it was present on swrast in past (i cant check now the xorg.conf with fbdev dont work on Fedora 25 PPC64 make X dont start) and yes was present in past in nouveau too, i cant say if it was fixed on nouveau, if needed i can made a clean installation on my G5 Quad where is present a nvidia gpu for check.
For sure i tested it on:
Ubuntu Mate 15.x,16.x and 17.x PPC32
Fedora 24 and 25 PPC64
OpenSuse Tumblebee PPC64
and on all this distros the color issue is present. 
Here on this machine a new ppc64 Hw i have the wrong color reported.
my gpu is a radeonhd 6570 but was reported the same issue from other users with 5450HD, 6870HD 

The old bug reported by Xeno74 bug 72877 was effecting the opengl not gles1 and gles2 and was fixed from mesa 11.x 

on my ubuntu mate partition are running mesa 17-rc2 
on Fedora mesa 13.0.3

If is need i can ask the others guys from the community to post here and report.
Im open to help .. the important is fix this issue .

Luigi

Created attachment 129396 [details]
all blue weston

Weston blue

Just tested on Ubuntu Mate 16.10 in software resterized mode Mesa 17 rc2 ... 
color issue is present there too.

At a blind guess, I'm going to say that this is because Wayland's formats are defined as DRM's are, i.e. explicitly little-endian where pixels are accessed whole, rather than GL's byte-by-byte. I suppose the conversion between GL and Wayland/DRM formats are simply broken for BE.

Thanks for your explanation, i hope will be fixed and not forget 
we have a new QorIQ machines is really unhappy cant use the desktop or have glitches there

Hi All,

I have the same problems. 

System:

A-EON AmigaOne X1000 PowerPC
Nemo board with a P.A. Semi PA6T-1682M CPU
8GB RAM
XFX Radeon HD6870 1GB VRAM
ubuntu MATE 17.04 PowerPC (PPC32) with the kernels 4.10-rc7 (DRM 2.49.0) and 4.9.8 (DRM 2.48.0)
Mesa 13.0.4

Cheers,
Christian

Hi there,

Same here on PM 11.2 G5 with Nvidia 6600LE 256MB VRAM (nouveau) and 6GB RAM
Ubuntu MATE 17.04 PowerPC (PPC32) with the kernels 4.9.0-15 
Mesa 13.0.4

Best regards,
Kris

Created attachment 129500 [details]
WebGL wrong colors - blue - Casey

Hello All, 
I'm experiencing the same issues.  

A-EON X5000 PowerPC (e5500 cores)
Sapphire Radeon HD6870 1 GB VRAM
ubuntu MATE 17.04 PowerPC (PPC32) on kernel 4.10.0-rc5
Mesa 13.0.4

Thanks! 
Casey

(In reply to Daniel Stone from comment #7)
> At a blind guess, I'm going to say that this is because Wayland's formats
> are defined as DRM's are, i.e. explicitly little-endian where pixels are
> accessed whole, rather than GL's byte-by-byte. I suppose the conversion
> between GL and Wayland/DRM formats are simply broken for BE.

A quick glance at platform_wayland.c shows this:

static EGLBoolean
dri2_wl_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *disp)
{
   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
   static const struct {
      const char *format_name;
      int has_format;
      unsigned int rgba_masks[4];
   } visuals[] = {
      { "XRGB8888", HAS_XRGB8888, { 0xff0000, 0xff00, 0x00ff, 0xff000000 } },
      { "ARGB8888", HAS_ARGB8888, { 0xff0000, 0xff00, 0x00ff, 0 } },
      { "RGB565",   HAS_RGB565,   { 0x00f800, 0x07e0, 0x001f, 0 } },
   };

Which seems like it could be off for BE...

I happen to have a PPC G5 with a NV34/AGP sitting in it. I might try to play with it later (got it all to work with X11 again a while back). Although I'd have to get help with the wayland part of it.

Thanks Ilia!
in case you need help in testing a future patch ask freely.

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.

HI Pekka,
for my first screenshot (webgl) you can check it how look like here https://playcanv.as/p/SA7hVBLt/ 
here a video where you can see how look like on BE in this case a G5 970MP 
https://www.youtube.com/watch?v=MYgFfRLYhLU 

I can do all test needed if will help

The plot thickens:
https://lists.freedesktop.org/archives/wayland-devel/2017-February/033084.html

Apparently it's even more of a mess that I thought.

I mean, simply fixing Mesa now to look right without verifying if the other graphics stack components actually got it right too might lead to another breakage later. It is even possible that we have a double confusion on some pixel path making it look right now, but break when one confusion gets fixed.

It seems to me that this would need a developer dedicated to fix it across the stack while having access to a BE machine with a recent enough GPU to run GLESv2 or whatever most compositors use.

Thanks Pekka for your infos and job :-)

If at all helpful, I'd be happy to donate and ship a G5 970MP (PCIe) to a dev

(In reply to Ilia Mirkin from comment #13)
> (In reply to Daniel Stone from comment #7)
> > At a blind guess, I'm going to say that this is because Wayland's formats
> > are defined as DRM's are, i.e. explicitly little-endian where pixels are
> > accessed whole, rather than GL's byte-by-byte. I suppose the conversion
> > between GL and Wayland/DRM formats are simply broken for BE.
> 
> A quick glance at platform_wayland.c shows this:
> 
> static EGLBoolean
> dri2_wl_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay *disp)
> {
>    struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>    static const struct {
>       const char *format_name;
>       int has_format;
>       unsigned int rgba_masks[4];
>    } visuals[] = {
>       { "XRGB8888", HAS_XRGB8888, { 0xff0000, 0xff00, 0x00ff, 0xff000000 } },
>       { "ARGB8888", HAS_ARGB8888, { 0xff0000, 0xff00, 0x00ff, 0 } },
>       { "RGB565",   HAS_RGB565,   { 0x00f800, 0x07e0, 0x001f, 0 } },
>    };
> 
> Which seems like it could be off for BE...
> 
> I happen to have a PPC G5 with a NV34/AGP sitting in it. I might try to play
> with it later (got it all to work with X11 again a while back). Although I'd
> have to get help with the wayland part of it.

Hi Ilia,
im using this thread to write the dri3 patch work on radeonhd on G5 too.
color continue be wrong but performance increase of 35% more. 
glxgears was 3100 fps on fedora ppc64 now are 3900

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/170.