| Summary: | Software rasterizer RGB swap | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Stefan de Konink <stefan> |
| Component: | Drivers/Gallium/softpipe | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 9.0 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Comparison between software rasterizer and nouveau_vieux
Comparison between software rasterizer and nouveau_vieux glxinfo wrong colours glxinfo right colours |
||
Created attachment 72005 [details]
Comparison between software rasterizer and nouveau_vieux
I don't have a big-endian machine available to test. Maybe you could debug this a bit further. If you look at src/gallium/state_trackers/glx/xlib/xm_api.c in the choose_pixel_format() function you'll see code that chooses a PIPE_FORMAT_x format by checking the visual's red/green/blue masks and the host/server byte orders. Maybe you can dig into that and see what's going on. (In reply to comment #2) > src/gallium/state_trackers/glx/xlib/xm_api.c Is this bug report about that, not about src/mesa/drivers/dri/swrast or src/mesa/drivers/x11 ? How can I verify this? What is the output of running glxinfo when you see the wrong colors? Created attachment 72639 [details]
glxinfo wrong colours
Created attachment 72640 [details]
glxinfo right colours
Yeah, for softpipe, src/gallium/state_trackers/glx/xlib/xm_api.c is the file to look at. (In reply to comment #2) > If you look at src/gallium/state_trackers/glx/xlib/xm_api.c in the > choose_pixel_format() function you'll see code that chooses a PIPE_FORMAT_x > format by checking the visual's red/green/blue masks and the host/server byte > orders. Maybe you can dig into that and see what's going on. I think we first need to decide what the byte order of PIPE_FORMAT_x is (supposed to be)... It was previously suggested it should be little endian, but I think there's still quite a bit of code treating it as having CPU native byte order. I tested softpipe on the PS3 (big-endian) a few years ago and remember fixing an endian issue then (and things looked good thereafter). Perhaps something's been broken since. -- 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/208. |
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.
Created attachment 72004 [details] Comparison between software rasterizer and nouveau_vieux As in the attachment is shown, the software rasterizer seems to have a problem on a big endian machine.