| Summary: | llvmpipe tests fail if built on skylake i7-6700k | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Timo Aaltonen <tjaalton> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 11.2 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Timo Aaltonen
2016-02-25 15:14:52 UTC
Could you show the instruction where it crashed (and the disassembly)? how exactly? I've tried gdb: (gdb) run Starting program: /home/tjaalton/src/pkg-xorg/lib/mesa.git/build/src/gallium/drivers/llvmpipe/lp_test_format [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Testing PIPE_FORMAT_B8G8R8A8_UNORM (float) ... Program received signal SIGILL, Illegal instruction. 0x00007ffff7ff5004 in ?? () (gdb) bt #0 0x00007ffff7ff5004 in ?? () #1 0x0000000000000000 in ?? () (gdb) bt full #0 0x00007ffff7ff5004 in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. Also, compiz doesn't run on SKL/KBL when using llvmpipe, it keeps restarting with 'trap: invalid opcode'. I guess these are related. (In reply to Timo Aaltonen from comment #2) > how exactly? I've tried gdb: Usually you could use x/i <address> if it's in jit code when gcc can't figure out the function (or just follow up to the caller and disassemble from there). But it looks like the stack got smashed so I don't know if that really would provide much insight. Is that a debug build? llvm-3.8 misdetects skylake features, this is fixed in 3.9-snapshot.. It's not the first time LLVM misidentifies modern CPUs. I thought that all the logic in src/gallium/auxiliary/gallivm/lp_bld_misc.cpp for setting +/-foo mattrs would save us from this sort of grief. On the other hand, I suppose that actually knowing the exact CPU model allows it to better model instruction latency/throughput. (In reply to Jose Fonseca from comment #6) > It's not the first time LLVM misidentifies modern CPUs. > > I thought that all the logic in > src/gallium/auxiliary/gallivm/lp_bld_misc.cpp for setting +/-foo mattrs > would save us from this sort of grief. For features we already know about (I think I even mentioned that back then, hoping it wouldn't be a problem)... If I look at the list of skylake features, I'd nearly bet the winner is avx512 (and/or any subvariant). Actually it wasn't avx512, that was the first one I tried :) It's enabled also on 3.7 and that version works fine. Only one that was added in 3.8 is PKU, but dropping just that didn't help. I did try dropping all non-client features (AVX512, CDI, DQI, BWI, VLX, PKU) and that worked. Maybe one of CDI/DQI/BWI/VLX is somewhat broken on 3.8? (In reply to Timo Aaltonen from comment #8) > Actually it wasn't avx512, that was the first one I tried :) It's enabled > also on 3.7 and that version works fine. Only one that was added in 3.8 is > PKU, but dropping just that didn't help. > > I did try dropping all non-client features (AVX512, CDI, DQI, BWI, VLX, PKU) > and that worked. Maybe one of CDI/DQI/BWI/VLX is somewhat broken on 3.8? Which is why I said "or any subvariant" ;-). ERI, CDI, PFI, DQI, BWI, VLX are all avx512 variants (omg naming???), though that skylake in the llvm 3.8 list doesn't suport ERI and PFI. I'm not sure, but probably dropping avx512 manually when a enhanced variant still gets enabled won't do anything. I don't think PKU would matter (but no guarantee...). I suppose we should explicitly disable all of them via mattrs too (not that it's a battle we can win, there will be some extensions at some point...). Oh, I didn't know they were subvariants :) I've dropped them from our llvm-3.8 for now at least.. Worked around by 8b66e2647d5e36e318177a460e6e586d6ca8c36b. |
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.