<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Regression in Mesa 17 on s390x (zSystems)" href="https://bugs.freedesktop.org/show_bug.cgi?id=100613#c22">Comment # 22</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Regression in Mesa 17 on s390x (zSystems)" href="https://bugs.freedesktop.org/show_bug.cgi?id=100613">bug 100613</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Ray Strode [halfline] from <a href="show_bug.cgi?id=100613#c21">comment #21</a>) > Unless I'm misunderstanding something, I think this comment in u_format.h is > the crux of the issue: > > * If each channel is accessed as an individual N-byte value, X is always• > * at the lowest address in memory, Y is always next, and so on. For all• > * currently-defined formats, the N-byte value has native endianness.• > *• > * If instead a group of channels is accessed as a single N-byte value,• > * the order of the channels within that value depends on endianness.• > * For big-endian targets, X is the most significant subvalue,• > * otherwise it is the least significant one.• > *• > > I guess vector fetch is the first paragraph, and scalar fetch is the second > paragraph. So they can't behave the same on big endian unless we introduce > swaps. I think this has more to do with packed formats - for things like 10/10/10/2 you can't really access that as multiple individual bytes. But yes I suppose it's that way because scalar and vector fetches aren't the same. Maybe the logic should be simplified for soa fetch for big-endian (e.g. always use scalars or vectors). Whatever works (well ideally you'd use what generates better code but I have no idea there on big endian or specifically ppc boxes.)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>