Bug 58665 - Software rasterizer RGB swap
Summary: Software rasterizer RGB swap
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/softpipe (show other bugs)
Version: 9.0
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-22 23:39 UTC by Stefan de Konink
Modified: 2019-09-18 18:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Comparison between software rasterizer and nouveau_vieux (21.51 KB, text/plain)
2012-12-22 23:39 UTC, Stefan de Konink
Details
Comparison between software rasterizer and nouveau_vieux (21.51 KB, image/png)
2012-12-22 23:40 UTC, Stefan de Konink
Details
glxinfo wrong colours (18.93 KB, text/plain)
2013-01-07 17:16 UTC, Stefan de Konink
Details
glxinfo right colours (16.38 KB, text/plain)
2013-01-07 17:16 UTC, Stefan de Konink
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan de Konink 2012-12-22 23:39:25 UTC
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.
Comment 1 Stefan de Konink 2012-12-22 23:40:13 UTC
Created attachment 72005 [details]
Comparison between software rasterizer and nouveau_vieux
Comment 2 Brian Paul 2013-01-04 22:50:13 UTC
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.
Comment 3 Michel Dänzer 2013-01-07 16:48:51 UTC
(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 ?
Comment 4 Stefan de Konink 2013-01-07 16:56:50 UTC
How can I verify this?
Comment 5 Brian Paul 2013-01-07 16:59:32 UTC
What is the output of running glxinfo when you see the wrong colors?
Comment 6 Stefan de Konink 2013-01-07 17:16:04 UTC
Created attachment 72639 [details]
glxinfo wrong colours
Comment 7 Stefan de Konink 2013-01-07 17:16:25 UTC
Created attachment 72640 [details]
glxinfo right colours
Comment 8 Brian Paul 2013-01-07 17:23:58 UTC
Yeah, for softpipe, src/gallium/state_trackers/glx/xlib/xm_api.c is the file to look at.
Comment 9 Michel Dänzer 2013-01-07 17:24:30 UTC
(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.
Comment 10 Brian Paul 2013-01-07 17:31:06 UTC
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.
Comment 11 GitLab Migration User 2019-09-18 18:27:37 UTC
-- 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.