Bug 99638 - Mesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC64
Summary: Mesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC64
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: EGL/Wayland (show other bugs)
Version: unspecified
Hardware: PowerPC Linux (All)
: medium major
Assignee: Wayland bug list
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-02 09:15 UTC by intermediadc@hotmail.com
Modified: 2017-05-08 13:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
webgl pink textature colors (401.21 KB, image/png)
2017-02-02 09:15 UTC, intermediadc@hotmail.com
Details
more screenshots (1.34 MB, application/zip)
2017-02-06 08:27 UTC, Tapani Pälli
Details
all blue weston (91.99 KB, image/png)
2017-02-07 17:18 UTC, intermediadc@hotmail.com
Details
WebGL wrong colors - blue - Casey (1022.94 KB, image/png)
2017-02-11 01:27 UTC, Casey C
Details

Note You need to log in before you can comment on or make changes to this bug.
Description intermediadc@hotmail.com 2017-02-02 09:15:18 UTC
Created attachment 129286 [details]
webgl pink textature colors

Hi,
all the applications and desktop who use opengles and opengles2 geve pink or blue color as result.
Wayland is effected too

pls fix it because kde desktop and others now are using some components for display parts of system gui and all become more worst day by day.

See the attachments.

att: webgl pink colors
Comment 1 intermediadc@hotmail.com 2017-02-02 09:19:27 UTC
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.
Comment 2 Tapani Pälli 2017-02-06 08:27:48 UTC
Created attachment 129355 [details]
more screenshots
Comment 3 Emil Velikov 2017-02-06 16:28:39 UTC
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.
Comment 4 intermediadc@hotmail.com 2017-02-06 17:47:43 UTC
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
Comment 5 intermediadc@hotmail.com 2017-02-07 17:18:55 UTC
Created attachment 129396 [details]
all blue weston

Weston blue
Comment 6 intermediadc@hotmail.com 2017-02-08 07:51:26 UTC
Just tested on Ubuntu Mate 16.10 in software resterized mode Mesa 17 rc2 ... 
color issue is present there too.
Comment 7 Daniel Stone 2017-02-08 08:58:19 UTC
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.
Comment 8 intermediadc@hotmail.com 2017-02-08 10:05:29 UTC
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
Comment 9 Christian Zigotzky 2017-02-08 11:42:27 UTC
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
Comment 10 Kris 2017-02-09 12:45:33 UTC
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
Comment 11 Casey C 2017-02-11 01:27:05 UTC
Created attachment 129500 [details]
WebGL wrong colors - blue - Casey
Comment 12 Casey C 2017-02-11 01:27:41 UTC
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
Comment 13 Ilia Mirkin 2017-02-11 01:50:14 UTC
(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.
Comment 14 intermediadc@hotmail.com 2017-02-14 08:05:53 UTC
Thanks Ilia!
in case you need help in testing a future patch ask freely.
Comment 15 Pekka Paalanen 2017-02-14 08:55:51 UTC
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.
Comment 16 intermediadc@hotmail.com 2017-02-14 09:24:28 UTC
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
Comment 17 Pekka Paalanen 2017-02-14 10:56:18 UTC
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.
Comment 18 Pekka Paalanen 2017-02-14 11:11:51 UTC
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.
Comment 19 intermediadc@hotmail.com 2017-02-14 11:45:21 UTC
Thanks Pekka for your infos and job :-)
Comment 20 Casey C 2017-02-14 18:29:53 UTC
If at all helpful, I'd be happy to donate and ship a G5 970MP (PCIe) to a dev
Comment 21 intermediadc@hotmail.com 2017-05-08 13:27:26 UTC
(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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.