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
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.