[Mesa-dev] [Bug 100613] Regression in Mesa 17 on s390x (zSystems)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=100613

--- Comment #22 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Ray Strode [halfline] from comment #21)
> 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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170505/06fe75c0/attachment.html>