https://bugs.freedesktop.org/show_bug.cgi?id=100613
--- Comment #22 from Roland Scheidegger <srol...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
