Bug 106644

Created attachment 139743 [details]
test-suite.log

Created attachment 139744 [details]
build.log

Created attachment 139745 [details]
coredump lp_test_arit

Created attachment 139746 [details]
coredump lp_test_blend

Created attachment 139747 [details]
coredump lp_test_format

Created attachment 139748 [details]
coredump lp_test_conv

Created attachment 139749 [details]
coredump lp_test_printf

I suppose llvmpipe itself doesn't work neither?
Is that a new issue, which didn't happen with earlier mesa versions (but the same llvm version)?
If so can you bisect?

We note that this is a build for a PPC970, which is essentially
a big-endian ~Power4 equivalent to a G5 Mac.

Moreover, it appears to be a 32-bit build.

Correct. Should I note (potential?) ppc specific issues in the bug title too, besides selecting hardware "PowerPC"?

llvmpipe does run on my other G5 (64bit build), however a lot of piglet tests fail/segfault (see bug #105730).

Don't know yet if it's a regression, but I could build and run the tests a few major releases back on both G5. If it turns out to be a regression I will at least try to bisect it and see how far I get.

Built 18.0.5 and 17.3.9, same test failures here.

Created attachment 140427 [details]
build.log (ppc)

Created attachment 140428 [details]
build.log (ppc64)

Created attachment 140429 [details]
test-suite.log (ppc)

Created attachment 140430 [details]
test-suite.log (ppc64)

Created attachment 140431 [details]
coredump lp_test_arit (ppc)

Created attachment 140432 [details]
coredump lp_test_blend (ppc)

Created attachment 140433 [details]
coredump lp_test_format (ppc)

Created attachment 140434 [details]
coredump lp_test_conv (ppc)

Created attachment 140435 [details]
coredump lp_test_printf (ppc)

Re-done tests with 18.1.2 on both ppc 32bit (G5, 64bit kernel, 32bit userland) and 64bit (G5, 64bit kernel, 64bit userland).

With abi_ppc_64 only 4 tests fail. lp_test_printf which fails on abi_ppc_32 passes on the 64bit build.

Would you please run the lp_test_* tests with the following
environmental controls in place:


% export LIBGL_DEBUG=verbose
% export MESA_DEBUG=verbose
% export MESA_GLSL=""
% export MESA_GLSL="dump log uniform useprog errors"
% export GALLIVM_DEBUG="tgsi ir asm dumpbc"
% export ST_DEBUG=tgsi

I'd like to see the LLVM code and the PPC assembly code, if possible.

If you don't get any LLVM code, or if you get LLVM code but not PPC
assembly, that may, in itself, be telling.

Note also that these messages in the PPC32 test-suite.log (comment 14) may also be telling:

Relocation type not implemented yet!
UNREACHABLE executed at .../RuntimeDyldELF.cpp:667!

Thanks!

Created attachment 140477 [details]
output from lp_test_* (ppc)

Hope this output is helpful to you!

I am certainly no expert in this area, but could the problem be the 970 trying to execute vsx instructions?

llc -mattr option(s): +altivec,+vsx
llc -mcpu option: 970

According to the Wikipedia article, the 970 is a Power ISA v2.03 (2002-2007) CPU,
while VSX was not introduced until Power ISA v2.06 (February 2009) and POWER7.

So it seems to me that llc should recognize which version of the ISA each
CPU implements, and that it should disallow combinations like
-mcpu=970 -mattr=+altivec,+vsx

I filed the following bug against LLVM/llc:

https://bugs.llvm.org/show_bug.cgi?id=38075
(llc for Power allows illegal combinations of -mcpu and -mattr)

In the meantime, you can control VSX usage from Mesa in a couple of ways:
% export GALLIVM_MATTRS=<string>, e.g.
% export GALLIVM_MATTRS="+altivec,-vsx"
to keep AltiVec but turn off VSX code generation, or

% export GALLIVM_VSX=0
to disable VSX code generation.

I'm not seeing any assembly code in the output you posted, and I'm
wondering whether the attempt to generate VSX code might be leading to
the "Relocation type not implemented" errors and failure to generate
any assembly code.

But yes, you were exactly right in zeroing in on the combination of
-mcpu=970 -mattrs=+altivec,+vsx,
which SHOULD be caught and disallowed.

(In reply to Ben Crocker from comment #25)
> According to the Wikipedia article, the 970 is a Power ISA v2.03 (2002-2007)
> CPU,
> while VSX was not introduced until Power ISA v2.06 (February 2009) and
> POWER7.
> 
> So it seems to me that llc should recognize which version of the ISA each
> CPU implements, and that it should disallow combinations like
> -mcpu=970 -mattr=+altivec,+vsx

I don't think you can blame llvm for that. This looks perfectly acceptable to me - you're specifying the cpu model (and that governs a lot more than just cpu extensions), but then specify some extensions on top of it. It's not llvm's fault that the cpu really can't do the extensions.
(fwiw on x86 this is perfectly acceptable too, and it's even more weird there, for instance if you explicitly specify -avx but +f16c avx will get reenabled nevertheless, since the latter option actually requires avx (or more accurately, vex encoding) - you are responsible for specifying attributes which make sense.)

Env vars to specify this are ok, but we should never manually enable attributes which the cpu can't support (and certainly not by default...). Surely it's possible to recognize these cpu features?
Also, maybe llvm would recognize the availability of these features on its own nowadays correctly (as it does for x86)? Although I remember there were problems due to LE/BE differentation on ppc.

(In reply to Ben Crocker from comment #26)

I added the following exports
% export GALLIVM_MATTRS="-vsx"
% export GALLIVM_VSX=0
as you suggested, but the tests still segfault.

Config was:
./configure --enable-llvm --with-llvm-prefix=/usr/lib/llvm/5/ --disable-gles1 --with-gallium-drivers=r300,r600,swrast --enable-debug

Created attachment 140508 [details]
output from lp_test_* (ppc)

An LLVM developer tells me that llvmpipe on PPC32 BE doesn't work,
and probably won't ever work.

He suggests using swrast instead.

I see. I am in no hurry either, 'cause I don't depend on llvmpipe working on PPC32 BE. Leaves me wondering if there is PPC32 LE? I just reported this 'cause I use PPC32 BE regularly and it looked like a mesa bug.

Having said that, 4 of the 5 lp_tests fail on PPC64 BE too on my other G5 and I guess they will fail equally on my Talos II once I receive it.

I suspect that, if you run your Talos II big-endian, you will have the
same results as on your G5; big-endian machines have not had the attention
from the LLVM developers that little-endian machines have.

I have the same suggestion: try the swrast pipe.

Could you please report your results here, whether they are successful
or not?

  Thanks!

AFAIK, there IS PPC32 LE; we just don't support it in Red Hat products.
So, I can't tell you much more.  Sorry!

What are the chances you can convert to using PPC64LE across the board?

Also, are you able to run this test on PPC64 BE?
(My PPC64 BE machine is out of service at the moment.)

Created attachment 140612 [details]
output from lp_test_* (ppc64)

Here's the ouptut from my other G5's ppc64 BE setup.

I will certainly try ppc64 LE on Talos II, but the G5 can't do LE, neither my laptop, a PowerBook G4. ;)

Created attachment 140673 [details]
test-suite.log (ppc64) standard build

Created attachment 140674 [details]
test-suite.log (ppc64) GALLIVM_MATTRS="-vsx" & GALLIVM_VSX=0 build

Last time I built mesa on ppc64 BE I forgot to export GALLIVM_MATTRS="-vsx" & GALLIVM_VSX=0. I did now, and the result is interesting.

With +vsx 4 of 5 tests fail on ppc64 (segfault).
With -vsx 2 of 5 tests fail on ppc64 (no segfault).

So I suppose at least a part of the test failures originate in the 970 trying to execute VSX assembly code.

mesa 18.1.4 - ppc64 BE, standard build:

make  check-TESTS
make[5]: Verzeichnis „/root/build/mesa-18.1.4/src/gallium/drivers/llvmpipe“ wird betreten
make[6]: Verzeichnis „/root/build/mesa-18.1.4/src/gallium/drivers/llvmpipe“ wird betreten
../../../../bin/test-driver: Zeile 107:  6410 Ungültiger Maschinenbefehl   (Speicherabzug geschrieben) "$@" > $log_file 2>&1
FAIL: lp_test_format
../../../../bin/test-driver: Zeile 107:  6419 Ungültiger Maschinenbefehl   (Speicherabzug geschrieben) "$@" > $log_file 2>&1
FAIL: lp_test_arit
../../../../bin/test-driver: Zeile 107:  6432 Ungültiger Maschinenbefehl   (Speicherabzug geschrieben) "$@" > $log_file 2>&1
FAIL: lp_test_blend
../../../../bin/test-driver: Zeile 107:  6446 Ungültiger Maschinenbefehl   (Speicherabzug geschrieben) "$@" > $log_file 2>&1
FAIL: lp_test_conv
PASS: lp_test_printf
============================================================================
Testsuite summary for Mesa 18.1.4
============================================================================
# TOTAL: 5
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  4
# XPASS: 0
# ERROR: 0


mesa 18.1.4 - ppc64 BE, GALLIVM_MATTRS="-vsx" & GALLIVM_VSX=0 build:

make  check-TESTS
make[5]: Verzeichnis „/root/build/mesa-18.1.4/src/gallium/drivers/llvmpipe“ wird betreten
make[6]: Verzeichnis „/root/build/mesa-18.1.4/src/gallium/drivers/llvmpipe“ wird betreten
FAIL: lp_test_format
FAIL: lp_test_arit
PASS: lp_test_blend
PASS: lp_test_conv
PASS: lp_test_printf
============================================================================
Testsuite summary for Mesa 18.1.4
============================================================================
# TOTAL: 5
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

Note that all the lp_test_format failures seem to have to do with
packing/unpacking of "exotic: formats, while the lp_test_arit failures
have to do with rounding.
 
FAIL: lp_test_format
====================
PIPE_FORMAT_B5G5R5A1_UNORM (float)
PIPE_FORMAT_B5G5R5A1_UNORM (unorm8)
PIPE_FORMAT_B4G4R4A4_UNORM (float)
PIPE_FORMAT_B4G4R4A4_UNORM (unorm8)
PIPE_FORMAT_B5G6R5_UNORM (float)
PIPE_FORMAT_B5G6R5_UNORM (unorm8)
PIPE_FORMAT_R10G10B10A2_UNORM (float)
PIPE_FORMAT_R10G10B10A2_UNORM (unorm8)
PIPE_FORMAT_R32_FLOAT (float)
PIPE_FORMAT_R32_FLOAT (unorm8)
PIPE_FORMAT_R32G32_FLOAT (float)
PIPE_FORMAT_R32G32_FLOAT (unorm8)
PIPE_FORMAT_R32G32B32_FLOAT (float)
PIPE_FORMAT_R32G32B32_FLOAT (unorm8)
PIPE_FORMAT_R32G32B32A32_FLOAT (float)
PIPE_FORMAT_R32G32B32A32_FLOAT (unorm8)
PIPE_FORMAT_R32_USCALED (float)
PIPE_FORMAT_R32G32_USCALED (float)
PIPE_FORMAT_R32G32B32_USCALED (float)
PIPE_FORMAT_R32G32B32A32_USCALED (float
PIPE_FORMAT_R32_SNORM (float)
PIPE_FORMAT_R32_SNORM (unorm8)
PIPE_FORMAT_R32G32_SNORM (float)
PIPE_FORMAT_R32G32_SNORM (unorm8)
PIPE_FORMAT_R32G32B32_SNORM (float)
PIPE_FORMAT_R32G32B32_SNORM (unorm8)
PIPE_FORMAT_R32G32B32A32_SNORM (float)
PIPE_FORMAT_R32G32B32A32_SNORM (unorm8)
PIPE_FORMAT_R32_SSCALED (float)
PIPE_FORMAT_R32_SSCALED (unorm8)
PIPE_FORMAT_R32G32_SSCALED (float)
PIPE_FORMAT_R32G32_SSCALED (unorm8)
PIPE_FORMAT_R32G32B32_SSCALED (float)
PIPE_FORMAT_R32G32B32_SSCALED (unorm8)
PIPE_FORMAT_R32G32B32A32_SSCALED (float)
PIPE_FORMAT_R32G32B32A32_SSCALED (unorm8)
PIPE_FORMAT_R16_SNORM (float)
PIPE_FORMAT_R16_SNORM (unorm8)
PIPE_FORMAT_R16G16_SNORM (float)
PIPE_FORMAT_R16G16_SNORM (unorm8)
PIPE_FORMAT_R16G16B16_SNORM (float)
PIPE_FORMAT_R16G16B16_SNORM (unorm8)
PIPE_FORMAT_R16G16B16A16_SNORM (float)
PIPE_FORMAT_R16G16B16A16_SNORM (unorm8)
PIPE_FORMAT_R16_SSCALED (float)
PIPE_FORMAT_R16_SSCALED (unorm8)
PIPE_FORMAT_R16G16_SSCALED (float)
PIPE_FORMAT_R16G16_SSCALED (unorm8)
PIPE_FORMAT_R16G16B16_SSCALED (float)
PIPE_FORMAT_R16G16B16_SSCALED (unorm8)
PIPE_FORMAT_R16G16B16A16_SSCALED (float)
PIPE_FORMAT_R16G16B16A16_SSCALED (unorm8)
PIPE_FORMAT_R8G8B8_UNORM (unorm8)
PIPE_FORMAT_R32_FIXED (float)
PIPE_FORMAT_R32_FIXED (unorm8)
PIPE_FORMAT_R32G32_FIXED (float)
PIPE_FORMAT_R32G32_FIXED (unorm8)
PIPE_FORMAT_R32G32B32_FIXED (float)
PIPE_FORMAT_R32G32B32_FIXED (unorm8)
PIPE_FORMAT_R32G32B32A32_FIXED (float)
PIPE_FORMAT_R32G32B32A32_FIXED (unorm8)
PIPE_FORMAT_R16_FLOAT (float)
PIPE_FORMAT_R16_FLOAT (unorm8)
PIPE_FORMAT_R16G16_FLOAT (float)
PIPE_FORMAT_R16G16_FLOAT (unorm8)
PIPE_FORMAT_R16G16B16_FLOAT (float)
PIPE_FORMAT_R16G16B16_FLOAT (unorm8)
PIPE_FORMAT_R16G16B16A16_FLOAT (float)
PIPE_FORMAT_R16G16B16A16_FLOAT (unorm8)
PIPE_FORMAT_R5SG5SB6U_NORM (float)
PIPE_FORMAT_R5SG5SB6U_NORM (unorm8)
PIPE_FORMAT_B5G5R5X1_UNORM (float)
PIPE_FORMAT_B5G5R5X1_UNORM (unorm8)
PIPE_FORMAT_R10G10B10X2_USCALED (float)
PIPE_FORMAT_R10G10B10X2_USCALED (unorm8)
PIPE_FORMAT_R10G10B10X2_SNORM (float)
PIPE_FORMAT_R10G10B10X2_SNORM (unorm8)
PIPE_FORMAT_L4A4_UNORM (unorm8)
PIPE_FORMAT_B10G10R10A2_UNORM (float)
PIPE_FORMAT_B10G10R10A2_UNORM (unorm8)
PIPE_FORMAT_R10SG10SB10SA2U_NORM (float)
PIPE_FORMAT_R10SG10SB10SA2U_NORM (unorm8)
PIPE_FORMAT_B4G4R4X4_UNORM (float)
PIPE_FORMAT_B4G4R4X4_UNORM (unorm8)
PIPE_FORMAT_R10G10B10X2_UNORM (float)
PIPE_FORMAT_R10G10B10X2_UNORM (unorm8)
PIPE_FORMAT_A1B5G5R5_UNORM (float)
PIPE_FORMAT_A1B5G5R5_UNORM (unorm8)
PIPE_FORMAT_X1B5G5R5_UNORM (float)
PIPE_FORMAT_X1B5G5R5_UNORM (unorm8)

FAIL: lp_test_arit
==================
round.v1(-0.5): ref = -0, out = -1, precision = -inf bits, FAIL
round.v1(0.5): ref = 0, out = 1, precision = -inf bits, FAIL

'make check'/lp_test_arit fails in exactly the same way when I run it
on a ppc64le machine.

(In reply to Ben Crocker from comment #40)
> 'make check'/lp_test_arit fails in exactly the same way when I run it
> on a ppc64le machine.

That is sort of expected I guess. We only use "arch rounding" with either sse41 or altivec. sse2 has a special path too (as it can do float->int conversion with nearest rounding).
All other architectures will do round via float->int conversion (by doing float add with +-0.5 depending on sign first) - look at lp_build_round. This will do nearest rounding, but not nearest even, which the test expects.
I think this should not be a problem in practice. If your chip does have native rounding instructions, you could try forcing the same path as what we use with sse41 - which is using llvm.nearbyint (in theory I suppose it should work with architectures which don't support this natively, but if you're unlucky it will just try to call into some math lib which is definitely no good and will just crash, and even if it would work you don't want to do that). If it's natively supported, not only should this be more correct, but also be much faster.

I just hit what appears to be this issue today while using swrast on a G5 (PowerPC 970, 64-bit kernel, 32-bit userland). Running even glxgears would result in a SIGILL in what appears to be gallivm-generated code on a VSX instruction (xxlxor).

I have not tried to compile from source (I'm using a Debian Sid package) but I did track down this block in git: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp?h=mesa-18.1.5&id=3f1b6ef2aa9c99bebe539f1de5a5054d90fc5dc3#n626

It would appear that if compiled against a new enough LLVM, gallivm will enable VSX instructions if Altivec is present at all. There should ideally be separate checks for Altivec and VSX support instead.

I may look into this a bit deeper later but this is just the result of some quick research.

Created attachment 141179 [details]
test-suite.log (ppc64, Mesa 18.2.0_rc2) standard build

Out of curiosity I gave Mesa 18.2.0_rc2 a try. But no wonder happened, the outcome is unchanged. ;-)

Created attachment 142822 [details]
test-suite.log (ppc64, Mesa 18.3.1) standard build, Talos II

Re-tested with 18.3.1 and a more recent toolchain (gcc 7.4.0, glibc 2.27, binutils 2.30, llvm 6.0.1) on the G5 (POWER4) and addidtionally on a Talos II (POWER9).

On both machines I build with:
export LIBGL_DEBUG=verbose && export MESA_DEBUG=verbose && export MESA_GLSL="" && export MESA_GLSL="dump log uniform useprog errors" && export GALLIVM_DEBUG="tgsi ir asm dumpbc" && export ST_DEBUG=tgsi
./configure --enable-llvm --with-llvm-prefix=/usr/lib/llvm/6/ --disable-gles1 --with-gallium-drivers=r300,r600,swrast --enable-debug && make -j3 && make check

Talos II failed 3 out of 5: lp_test_format, lp_test_arit, lp_test_conv
      G5 failed 2 out of 5: lp_test_format, lp_test_arit

Which is an improvement over 18.1.4 and 18.2.0_rc2! And as lp_test_format, lp_test_arit fail on both POWER4 and POWER9 I guess it rules out the possibility that this happens because of VSX instructions.

Created attachment 142823 [details]
test-suite.log (ppc64, Mesa 18.3.1) standard build, G5

Created attachment 142824 [details]
output from failed lp_tests (ppc64, Mesa 18.3.1), G5

Created attachment 142825 [details]
output from failed lp_tests (ppc64, Mesa 18.3.1), Talos II

Created attachment 142826 [details]
coredump lp_test_format (ppc64), Talos II

Created attachment 142827 [details]
coredump lp_test_conv (ppc64), Talos II

Created attachment 143382 [details]
test-suite.log (ppc64, Mesa 19.0.0_rc4), Talos II

Re-tested with 19.0.0_rc4 and a more recent toolchain (gcc 7.4.0, glibc 2.27, binutils 2.30, llvm 7.0.1) on a Talos II (POWER9):

41/51 mesa:llvmpipe / lp_test_format          FAIL     2.80 s (exit status 1)
42/51 mesa:llvmpipe / lp_test_arit            FAIL     0.39 s (exit status 1)
48/51 mesa:gallium / u_format_test            FAIL     0.30 s (exit status 1)

OK:        48
FAIL:       3
SKIP:       0
TIMEOUT:    0

No coredumps are generated any longer, the tests just fail. Looks like not only the meson buildsystem is an improvement, also the test-suite.log got much nicher! ;)

I filed an extra bug (bug #109615) for u_format_test as this test was not included in 18.3.x tests and before.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/247.