<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems" href="https://bugs.freedesktop.org/show_bug.cgi?id=72877#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems" href="https://bugs.freedesktop.org/show_bug.cgi?id=72877">bug 72877</a> from <a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>(In reply to joro-2013 from <a href="show_bug.cgi?id=72877#c16">comment #16</a>) > Allow me to add my experiences. > > Whether the colors are garbled on PPC depends on the GL color format used > (among probably a gazillion other parameters :-). Packed (16-bit) formats > have been broken on big-endian for some time, they worked fine in mesa 10.1, > in mesa 10.3 R5G5B5A1 works, R4G4B4A4 works with alpha glitches, somewhere > in the 10.3 release cycle the format stuff got completely rewritten breaking > pretty much all packed formats on big-endian (PPC). > > Unpacked (32 bits) formats seem to be working fine. > > That's on a RV280 32 bit system. No idea whether that is also valid for NV34 > on 64-bit PPC, i.e. whether the problem is in core mesa or the radeon stuff. The report in question is (was?) about the gallium radeon driver - r600g. On the classic radeon/r200 front there was a regression caused by commit 779cabfc7d022de8b7b9bc7fdac0caffa8646c51 (which itself fixing some BE issues, circa 11.0), which was resolved in 11.0.6 and 11.1.0. If things are still off, then I'd suggest opening separate bug report and if possible bisecting it down.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>