Bug 106644 - [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv
Summary: [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/llvmpipe (show other bugs)
Version: unspecified
Hardware: PowerPC All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-24 22:42 UTC by erhard_f
Modified: 2019-09-18 18:33 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
build.log (6.97 MB, text/x-log)
2018-05-24 22:42 UTC, erhard_f
Details
test-suite.log (1.53 KB, text/plain)
2018-05-24 22:43 UTC, erhard_f
Details
build.log (6.97 MB, text/plain)
2018-05-24 22:44 UTC, erhard_f
Details
coredump lp_test_arit (3.57 KB, text/plain)
2018-05-24 22:50 UTC, erhard_f
Details
coredump lp_test_blend (3.57 KB, text/plain)
2018-05-24 22:51 UTC, erhard_f
Details
coredump lp_test_format (3.58 KB, text/plain)
2018-05-24 22:52 UTC, erhard_f
Details
coredump lp_test_conv (3.57 KB, text/plain)
2018-05-24 22:54 UTC, erhard_f
Details
coredump lp_test_printf (3.58 KB, text/plain)
2018-05-24 22:55 UTC, erhard_f
Details
build.log (ppc) (6.91 MB, text/plain)
2018-07-02 14:52 UTC, erhard_f
Details
build.log (ppc64) (8.36 MB, text/plain)
2018-07-02 14:54 UTC, erhard_f
Details
test-suite.log (ppc) (1.53 KB, text/plain)
2018-07-02 14:55 UTC, erhard_f
Details
test-suite.log (ppc64) (654 bytes, text/plain)
2018-07-02 14:56 UTC, erhard_f
Details
coredump lp_test_arit (ppc) (3.57 KB, text/plain)
2018-07-02 15:02 UTC, erhard_f
Details
coredump lp_test_blend (ppc) (3.57 KB, text/plain)
2018-07-02 15:02 UTC, erhard_f
Details
coredump lp_test_format (ppc) (3.59 KB, text/plain)
2018-07-02 15:03 UTC, erhard_f
Details
coredump lp_test_conv (ppc) (3.57 KB, text/plain)
2018-07-02 15:03 UTC, erhard_f
Details
coredump lp_test_printf (ppc) (3.59 KB, text/plain)
2018-07-02 15:04 UTC, erhard_f
Details
output from lp_test_* (ppc) (12.16 KB, text/plain)
2018-07-05 17:20 UTC, erhard_f
Details
output from lp_test_* (ppc) (12.30 KB, text/plain)
2018-07-08 17:09 UTC, erhard_f
Details
output from lp_test_* (ppc64) (11.57 KB, text/plain)
2018-07-12 20:46 UTC, erhard_f
Details
test-suite.log (ppc64) standard build (11.65 KB, text/plain)
2018-07-17 19:17 UTC, erhard_f
Details
test-suite.log (ppc64) GALLIVM_MATTRS="-vsx" & GALLIVM_VSX=0 build (729.38 KB, text/plain)
2018-07-17 19:28 UTC, erhard_f
Details
test-suite.log (ppc64, Mesa 18.2.0_rc2) standard build (12.08 KB, text/plain)
2018-08-18 13:18 UTC, erhard_f
Details
test-suite.log (ppc64, Mesa 18.3.1) standard build, Talos II (281.05 KB, text/plain)
2018-12-16 14:24 UTC, erhard_f
Details
test-suite.log (ppc64, Mesa 18.3.1) standard build, G5 (777.36 KB, text/plain)
2018-12-16 14:40 UTC, erhard_f
Details
output from failed lp_tests (ppc64, Mesa 18.3.1), G5 (56.91 KB, text/plain)
2018-12-16 14:55 UTC, erhard_f
Details
output from failed lp_tests (ppc64, Mesa 18.3.1), Talos II (280.73 KB, text/plain)
2018-12-16 15:04 UTC, erhard_f
Details
coredump lp_test_format (ppc64), Talos II (5.03 KB, text/plain)
2018-12-16 15:11 UTC, erhard_f
Details
coredump lp_test_conv (ppc64), Talos II (5.11 KB, text/plain)
2018-12-16 15:12 UTC, erhard_f
Details
test-suite.log (ppc64, Mesa 19.0.0_rc4), Talos II (6.98 MB, text/plain)
2019-02-15 00:00 UTC, erhard_f
Details

Note You need to log in before you can comment on or make changes to this bug.
Description erhard_f 2018-05-24 22:42:17 UTC
Created attachment 139742 [details]
build.log

make[6]: Leaving directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/r300'
make[5]: Leaving directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/r300'
make[4]: Leaving directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/r300'
Making check in winsys/radeon/drm
make[4]: Entering directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/winsys/radeon/drm'
make[4]: Nothing to be done for 'check'.
make[4]: Leaving directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/winsys/radeon/drm'
Making check in drivers/softpipe
make[4]: Entering directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/softpipe'
make[4]: Nothing to be done for 'check'.
make[4]: Leaving directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/softpipe'
Making check in drivers/llvmpipe
make[4]: Entering directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/llvmpipe'
make  lp_test_format lp_test_arit lp_test_blend lp_test_conv lp_test_printf
make[5]: Entering directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/llvmpipe'
make[5]: 'lp_test_format' is up to date.
make[5]: 'lp_test_arit' is up to date.
make[5]: 'lp_test_blend' is up to date.
make[5]: 'lp_test_conv' is up to date.
make[5]: 'lp_test_printf' is up to date.
make[5]: Leaving directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/llvmpipe'
make  check-TESTS
make[5]: Entering directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/llvmpipe'
make[6]: Entering directory '/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0-abi_ppc_32.ppc/src/gallium/drivers/llvmpipe'
/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0/bin/test-driver: line 107: 21992 Aborted                 (core dumped) "$@" > $log_file 2>&1
FAIL: lp_test_format
/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0/bin/test-driver: line 107: 21989 Aborted                 (core dumped) "$@" > $log_file 2>&1
FAIL: lp_test_arit
/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0/bin/test-driver: line 107: 21991 Aborted                 (core dumped) "$@" > $log_file 2>&1
FAIL: lp_test_blend
/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0/bin/test-driver: line 107: 22010 Aborted                 (core dumped) "$@" > $log_file 2>&1
FAIL: lp_test_printf
/var/tmp/portage/media-libs/mesa-18.1.0/work/mesa-18.1.0/bin/test-driver: line 107: 22011 Aborted                 (core dumped) "$@" > $log_file 2>&1
FAIL: lp_test_conv
============================================================================
Testsuite summary for Mesa 18.1.0
============================================================================
# TOTAL: 5
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  5
# XPASS: 0
# ERROR: 0
============================================================================
See src/gallium/drivers/llvmpipe/test-suite.log
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
============================================================================
Comment 1 erhard_f 2018-05-24 22:43:19 UTC
Created attachment 139743 [details]
test-suite.log
Comment 2 erhard_f 2018-05-24 22:44:15 UTC
Created attachment 139744 [details]
build.log
Comment 3 erhard_f 2018-05-24 22:50:11 UTC
Created attachment 139745 [details]
coredump lp_test_arit
Comment 4 erhard_f 2018-05-24 22:51:35 UTC
Created attachment 139746 [details]
coredump lp_test_blend
Comment 5 erhard_f 2018-05-24 22:52:51 UTC
Created attachment 139747 [details]
coredump lp_test_format
Comment 6 erhard_f 2018-05-24 22:54:09 UTC
Created attachment 139748 [details]
coredump lp_test_conv
Comment 7 erhard_f 2018-05-24 22:55:55 UTC
Created attachment 139749 [details]
coredump lp_test_printf
Comment 8 Roland Scheidegger 2018-05-25 02:45:36 UTC
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?
Comment 9 Ben Crocker 2018-05-25 15:04:56 UTC
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.
Comment 10 erhard_f 2018-05-25 15:46:21 UTC
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.
Comment 11 erhard_f 2018-06-14 14:40:20 UTC
Built 18.0.5 and 17.3.9, same test failures here.
Comment 12 erhard_f 2018-07-02 14:52:53 UTC
Created attachment 140427 [details]
build.log (ppc)
Comment 13 erhard_f 2018-07-02 14:54:01 UTC
Created attachment 140428 [details]
build.log (ppc64)
Comment 14 erhard_f 2018-07-02 14:55:56 UTC
Created attachment 140429 [details]
test-suite.log (ppc)
Comment 15 erhard_f 2018-07-02 14:56:52 UTC
Created attachment 140430 [details]
test-suite.log (ppc64)
Comment 16 erhard_f 2018-07-02 15:02:06 UTC
Created attachment 140431 [details]
coredump lp_test_arit (ppc)
Comment 17 erhard_f 2018-07-02 15:02:49 UTC
Created attachment 140432 [details]
coredump lp_test_blend (ppc)
Comment 18 erhard_f 2018-07-02 15:03:15 UTC
Created attachment 140433 [details]
coredump lp_test_format (ppc)
Comment 19 erhard_f 2018-07-02 15:03:41 UTC
Created attachment 140434 [details]
coredump lp_test_conv (ppc)
Comment 20 erhard_f 2018-07-02 15:04:13 UTC
Created attachment 140435 [details]
coredump lp_test_printf (ppc)
Comment 21 erhard_f 2018-07-02 15:09:42 UTC
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.
Comment 22 Ben Crocker 2018-07-02 21:24:09 UTC
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!
Comment 23 erhard_f 2018-07-05 17:20:43 UTC
Created attachment 140477 [details]
output from lp_test_* (ppc)
Comment 24 erhard_f 2018-07-05 17:29:50 UTC
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
Comment 25 Ben Crocker 2018-07-05 22:39:40 UTC
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.
Comment 26 Ben Crocker 2018-07-05 22:45:36 UTC
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.
Comment 27 Roland Scheidegger 2018-07-05 23:57:11 UTC
(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.
Comment 28 erhard_f 2018-07-08 17:08:12 UTC
(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
Comment 29 erhard_f 2018-07-08 17:09:03 UTC
Created attachment 140508 [details]
output from lp_test_* (ppc)
Comment 30 Ben Crocker 2018-07-09 14:33:58 UTC
An LLVM developer tells me that llvmpipe on PPC32 BE doesn't work,
and probably won't ever work.

He suggests using swrast instead.
Comment 31 erhard_f 2018-07-09 17:05:55 UTC
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.
Comment 32 Ben Crocker 2018-07-09 23:51:08 UTC
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!
Comment 33 Ben Crocker 2018-07-09 23:53:36 UTC
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?
Comment 34 Ben Crocker 2018-07-11 21:15:00 UTC
Also, are you able to run this test on PPC64 BE?
(My PPC64 BE machine is out of service at the moment.)
Comment 35 erhard_f 2018-07-12 20:46:43 UTC
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. ;)
Comment 36 erhard_f 2018-07-17 19:17:30 UTC
Created attachment 140673 [details]
test-suite.log (ppc64) standard build
Comment 37 erhard_f 2018-07-17 19:28:21 UTC
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.
Comment 38 erhard_f 2018-07-17 19:42:12 UTC
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
Comment 39 Ben Crocker 2018-07-24 19:25:37 UTC
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
Comment 40 Ben Crocker 2018-07-24 20:22:36 UTC
'make check'/lp_test_arit fails in exactly the same way when I run it
on a ppc64le machine.
Comment 41 Roland Scheidegger 2018-07-24 21:37:18 UTC
(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.
Comment 42 vi 2018-08-03 07:37:30 UTC
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.
Comment 43 erhard_f 2018-08-18 13:18:33 UTC
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. ;-)
Comment 44 erhard_f 2018-12-16 14:24:20 UTC
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.
Comment 45 erhard_f 2018-12-16 14:40:27 UTC
Created attachment 142823 [details]
test-suite.log (ppc64, Mesa 18.3.1) standard build, G5
Comment 46 erhard_f 2018-12-16 14:55:35 UTC
Created attachment 142824 [details]
output from failed lp_tests (ppc64, Mesa 18.3.1), G5
Comment 47 erhard_f 2018-12-16 15:04:34 UTC
Created attachment 142825 [details]
output from failed lp_tests (ppc64, Mesa 18.3.1), Talos II
Comment 48 erhard_f 2018-12-16 15:11:23 UTC
Created attachment 142826 [details]
coredump lp_test_format (ppc64), Talos II
Comment 49 erhard_f 2018-12-16 15:12:04 UTC
Created attachment 142827 [details]
coredump lp_test_conv (ppc64), Talos II
Comment 50 erhard_f 2019-02-15 00:00:39 UTC
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.
Comment 51 GitLab Migration User 2019-09-18 18:33:26 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.