Am 16.02.2016 um 12:40 schrieb Jonathan Gray:
On Tue, Feb 16, 2016 at 08:13:45PM +1100, Jonathan Gray wrote:
On Tue, Feb 16, 2016 at 10:37:47AM +0200, Oded Gabbay wrote:
On Tue, Feb 16, 2016 at 9:23 AM, Jonathan Gray <j...@jsg.id.au> wrote:
On Fri, Feb 12, 2016 at 10:01:21AM +0100, Jochen Rollwagen wrote:
Hi,
i think i found & fixed a bug in mesa concerning tests for big-endian
machines. The defines tested don't exist or are wrongly defined so the test
(probably) never fires. The gcc defines on my machine concerning big-endian
are
jochen@mac-mini:~/sources/mesa$ gcc -dM -E - < /dev/null | grep BIG
#define __BIGGEST_ALIGNMENT__ 16
#define __BIG_ENDIAN__ 1
#define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
#define _BIG_ENDIAN 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
The tested values in current mesa are quite different :-)
The following patch fixes this.
I think you have this backwards.
On OpenBSD/sparc64
$ gcc -dM -E - < /dev/null | grep BIG
$
$ sysctl hw.byteorder
hw.byteorder=4321
endian.h defines BYTE_ORDER and it should be included to test it.
I was under the impression the headers on linux had similiar defines.
Look at how src/gallium/include/pipe/p_config.h does it.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
After looking at it last night, I also think a better solution will be
to just include <endian.h> in compiler.h file
Oded
Right, I suspect it will end up looking something like the following
untested diff.
It would be nice if this didn't have to be duplicated in two places
in Mesa though.
At least on OpenBSD/amd64 the only place where endian.h is not picked up
indirectly when in matters seems to be shaderimage.c, otherwise
BYTE_ORDER is defined and compiler.h somehow included.
CPU_TO_LE32 isn't used
Well, actually it is, via compiler.h:
#define LE32_TO_CPU( x ) CPU_TO_LE32( x )
Actually i only stumbled across all of this by chance, i would naively
have expected to find info’s about the CPU mesa is running on in a place
so exotic as, wait a minute, now let me see, how about…….
Mesa/main/cpuinfo.h !
Yeah I know, completely absurd. Well, at least not as absurd as
„compiler.h“ (what compiler, anyway ?). Or p_config.h.
IMHO there are three alternatives (well, actually four) on how to proceed:
1.Trying to fix compiler.h
2.Taking the Gallium code and putting it in a sane place (like for
example cpuinfo.h), nuking compiler.h and thereby eliminating the
redundant code between dri and gallium driver
3.With people doing crazy things like running little-endian kernels on
pp64 replacing the #ifdef compile-time-checks in the radeon driver by
runtime checks
4.Doing nothing
I would opt personally for number 2.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
