[Bug 79575] New: [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate
https://bugs.freedesktop.org/show_bug.cgi?id=79575
Priority: medium Bug ID: 79575 Assignee: dri-devel@lists.freedesktop.org Summary: [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ansla80@yahoo.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa
I'm using both mesa and llvm from git, checked out yesterday, but I could also reprodce it with mesa 10.1.4 and llvm 3.4.1.
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel (git-84e0a5c)
When I run make test -C dlls/d3d8/tests I get:
Unhandled exception: denormal float operand in 32-bit code (0x7abce773). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7abce773 ESP:00329940 EBP:00329a08 EFLAGS:00210206( R- -- I - -P- ) EAX:0000007f EBX:7b7ee000 ECX:00000020 EDX:0000008f ESI:00000000 EDI:00000008 Stack dump: 0x00329940: 00000000 ffffffff 7a8c99d9 0000007f 0x00329950: 7abce6f7 7b7ee000 00000000 7abd200b 0x00329960: 7cd69238 7cb81558 ffffffff ffffffff 0x00329970: ffffffff ffffffff ffffffff ffffffff 0x00329980: ffffffff ffffffff ffffffff 003299e4 0x00329990: 0001ffff 00000008 00000000 ffffff00 Backtrace: =>0 0x7abce773 _ZNK4llvm16SITargetLowering16analyzeImmediateEPKNS_6SDNodeE+0x83() in libllvm-3.5svn.so (0x00329a08) 1 0x7abd200b _ZNK4llvm16SITargetLowering12foldOperandsEPNS_13MachineSDNodeERNS_12SelectionDAGE+0x12a() in libllvm-3.5svn.so (0x00329a08) 2 0x7abd2cf0 _ZNK4llvm16SITargetLowering15PostISelFoldingEPNS_13MachineSDNodeERNS_12SelectionDAGE+0x7f() in libllvm-3.5svn.so (0x7cb71c80) 3 0x7ab7a915 _ZN12_GLOBAL__N_118AMDGPUDAGToDAGISel18PostprocessISelDAGEv+0x64() in libllvm-3.5svn.so (0x7cb81438) 4 0x7a981176 _ZNK4llvm14TargetLowering27EmitInstrWithCustomInserterEPNS_12MachineInstrEPNS_17MachineBasicBlockE+0x625() in libllvm-3.5svn.so (0x7cd7e848) 5 0x7a9889b1 _ZN4llvm16SelectionDAGISel17CodeGenAndEmitDAGEv+0x240() in libllvm-3.5svn.so (0x00329b5c) 6 0x7a988da4 _ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorIKNS_11InstructionEEES4_Rb+0xc3() in libllvm-3.5svn.so (0x00329bb8) 7 0x7a98bf6c _ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE+0x51b() in libllvm-3.5svn.so (0x00329cd8) 8 0x7a98d5c5 _ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE+0x474() in libllvm-3.5svn.so (0x00000005) 9 0x7b152744 _ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x73() in libllvm-3.5svn.so (0x7cd7c878) 10 0x7ad96ba3 _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x202() in libllvm-3.5svn.so (0x00329e58) 11 0x7ad96ef8 _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x37() in libllvm-3.5svn.so (0x7cd72540) 12 0x7ad97204 _ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x2f3() in libllvm-3.5svn.so (0x7cd70798) 13 0x7ad973c6 _ZN4llvm6legacy11PassManager3runERNS_6ModuleE+0x25() in libllvm-3.5svn.so (0x7cc95598) 14 0x7b325762 _ZL21LLVMTargetMachineEmitP23LLVMOpaqueTargetMachineP16LLVMOpaqueModuleRN4llvm21formatted_raw_ostreamE19LLVMCodeGenFileTypePPc+0xc1() in libllvm-3.5svn.so (0x7cc95598) 15 0x7b325980 LLVMTargetMachineEmitToMemoryBuffer+0x14f() in libllvm-3.5svn.so (0x00329fb0) 16 0x7d99f225 radeon_llvm_compile+0x1d4() in radeonsi_dri.so (0x7b7f6b20) 17 0x7d9abbbd si_compile_llvm+0xa4() in radeonsi_dri.so (0x0032e274) 18 0x7d9ac4c3 si_pipe_shader_create+0x5ea() in radeonsi_dri.so (0x0032e274) 19 0x7d9b2684 si_shader_select+0x2b3() in radeonsi_dri.so (0x7cd79040) 20 0x7d9b279c si_create_shader_state+0x7b() in radeonsi_dri.so (0x7cc80b58) 21 0x7dc22fe3 ureg_create_shader+0x62() in radeonsi_dri.so (0x7cbe4088) 22 0x7dc42932 util_make_vertex_passthrough_shader_with_so+0x2f1() in radeonsi_dri.so (0x0032ee78) 23 0x7dc2ca2d util_blitter_create+0x5bc() in radeonsi_dri.so (0x7ccb8808) 24 0x7d9a6174 si_create_context+0x143() in radeonsi_dri.so (0x7cb43950) 25 0x7db25aa7 st_api_create_context+0x76() in radeonsi_dri.so (0x7cb43414) 26 0x7d9b5829 dri_create_context+0x1d8() in radeonsi_dri.so (0x7cb43414) 27 0x7d98bfd5 driCreateContextAttribs+0x32c() in radeonsi_dri.so (0x00000001) 28 0x7e0778b3 dri2_create_context_attribs+0x1a2() in libgl.so.1 (0x7cc94cc0) 29 0x7e04b92d glXCreateContextAttribsARB+0x1ac() in libgl.so.1 (0x0032f3b8) 30 0x7e35d818 create_glxcontext+0x73() in winex11 (0x0032f408) 31 0x7e3601f5 X11DRV_wglCreateContextAttribsARB+0x34a() in winex11 (0x0032f488) 32 0x7e9ace10 wglCreateContextAttribsARB+0xa8() in opengl32 (0x0032f4c8) 33 0x7ea665cd context_create+0x7a7() in wined3d (0x0032f6e8) 34 0x7eb25585 swapchain_init+0x771() in wined3d (0x0032f828) 35 0x7eb25d54 wined3d_swapchain_create+0xed() in wined3d (0x0032f8a8) 36 0x7efea631 swapchain_init+0x5b() in d3d8 (0x0032f8f8) 37 0x7efea728 d3d8_swapchain_create+0x67() in d3d8 (0x0032f948) 38 0x7efe6b30 device_parent_create_swapchain+0xa2() in d3d8 (0x0032f9a8) 39 0x7ea757c5 wined3d_device_init_3d+0x266() in wined3d (0x0032fa68) 40 0x7efe6efc device_init+0x30e() in d3d8 (0x0032fb38) 41 0x7efe85c8 d3d8_CreateDevice+0x121() in d3d8 (0x0032fbb8) 42 0x7ebb98f2 test_fpu_setup+0x38f() in d3d8_test (0x0032fc68) 43 0x7ebce0a8 func_device+0x148() in d3d8_test (0x0032fcc8) 44 0x7ebefc17 run_test+0x9e() in d3d8_test (0x0032fd28) 45 0x7ebf0006 main+0x210() in d3d8_test (0x0032fdd8) 46 0x7ebf00a0 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/andrei/x/wine/dlls/winecrt0/exe_entry.c:36] in d3d8_test (0x0032fe18) 47 0x7b8641d4 call_process_entry+0xb() in kernel32 (0x0032fe38) 48 0x7b864321 start_process+0x14a() in kernel32 (0x0032fe98) 49 0x7bc870c0 call_thread_func_wrapper+0xb() in ntdll (0x0032feb8) 50 0x7bc87109 call_thread_func+0x3e() in ntdll (0x0032ff98) 51 0x7bc8709e call_thread_entry_point+0x11() in ntdll (0x0032ffb8) 52 0x7bc5a1f5 start_process+0x23() in ntdll (0x0032ffe8) 53 0xf7570a15 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 54 0xf75709f3 wine_switch_to_stack+0x2a() in libwine.so.1 (0xff9c1058) 55 0x7bc5a4fc LdrInitializeThunk+0x306() in ntdll (0xff9c10e8) 56 0x7b864b64 __wine_kernel_init+0x67d() in kernel32 (0xff9c1fa8) 57 0x7bc5acde __wine_process_init+0x156() in ntdll (0xff9c2008) 58 0xf756f6a0 wine_init+0x140() in libwine.so.1 (0xff9c2048) 59 0x7bf0118b main+0x132() in <wine-loader> (0xff9c2478) 60 0xf7381443 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7abce773 _ZNK4llvm16SITargetLowering16analyzeImmediateEPKNS_6SDNodeE+0x83 in libllvm-3.5svn.so: <bad instruction> Modules: Module Address Debug info Name (72 modules) ELF 7a4d0000-7b800000 Dwarf libllvm-3.5svn.so ELF 7b800000-7ba60000 Dwarf kernel32<elf> -PE 7b810000-7ba60000 \ kernel32 ELF 7bc00000-7bcef000 Dwarf ntdll<elf> -PE 7bc10000-7bcef000 \ ntdll ELF 7bf00000-7bf04000 Dwarf <wine-loader> ELF 7cf58000-7cf7d000 Deferred imm32<elf> -PE 7cf60000-7cf7d000 \ imm32 ELF 7d020000-7d026000 Deferred libtxc_dxtn.so ELF 7d828000-7d830000 Deferred libffi.so.6 ELF 7d830000-7d84b000 Deferred libgcc_s.so.1 ELF 7d940000-7d94e000 Deferred libdrm_radeon.so.1 ELF 7d950000-7d969000 Deferred libelf.so.1 ELF 7d970000-7dfda000 Dwarf radeonsi_dri.so ELF 7dfe0000-7dfe9000 Deferred librt.so.1 ELF 7dff0000-7e005000 Deferred libudev.so.1 ELF 7e008000-7e014000 Deferred libdrm.so.2 ELF 7e018000-7e01d000 Deferred libxcb-dri2.so.0 ELF 7e020000-7e037000 Deferred libxcb-glx.so.0 ELF 7e038000-7e0c1000 Dwarf libgl.so.1 ELF 7e100000-7e106000 Deferred libxfixes.so.3 ELF 7e108000-7e113000 Deferred libxcursor.so.1 ELF 7e118000-7e129000 Deferred libxi.so.6 ELF 7e130000-7e134000 Deferred libxcomposite.so.1 ELF 7e138000-7e143000 Deferred libxrandr.so.2 ELF 7e148000-7e153000 Deferred libxrender.so.1 ELF 7e158000-7e15f000 Deferred libxxf86vm.so.1 ELF 7e160000-7e164000 Deferred libxinerama.so.1 ELF 7e168000-7e189000 Deferred libxcb.so.1 ELF 7e190000-7e2c8000 Deferred libx11.so.6 ELF 7e2c8000-7e2db000 Deferred libxext.so.6 ELF 7e2e0000-7e2e2000 Deferred libx11-xcb.so.1 ELF 7e2e8000-7e2ec000 Deferred libxdamage.so.1 ELF 7e2f0000-7e309000 Deferred libglapi.so.0 ELF 7e318000-7e3bb000 Dwarf winex11<elf> -PE 7e320000-7e3bb000 \ winex11 ELF 7e3c0000-7e3e8000 Deferred libexpat.so.1 ELF 7e3e8000-7e423000 Deferred libfontconfig.so.1 ELF 7e428000-7e45f000 Deferred libpng16.so.16 ELF 7e460000-7e501000 Deferred libfreetype.so.6 ELF 7e508000-7e50f000 Deferred libxdmcp.so.6 ELF 7e510000-7e514000 Deferred libxau.so.6 ELF 7e540000-7e58e000 Deferred libncurses.so.5 ELF 7e598000-7e5a9000 Deferred libbz2.so.1 ELF 7e5b0000-7e5c6000 Deferred libz.so.1 ELF 7e5c8000-7e5e3000 Deferred version<elf> -PE 7e5d0000-7e5e3000 \ version ELF 7e5e8000-7e75a000 Deferred user32<elf> -PE 7e600000-7e75a000 \ user32 ELF 7e760000-7e7d4000 Deferred advapi32<elf> -PE 7e770000-7e7d4000 \ advapi32 ELF 7e7d8000-7e8ff000 Deferred gdi32<elf> -PE 7e7e0000-7e8ff000 \ gdi32 ELF 7e900000-7ea1d000 Dwarf opengl32<elf> -PE 7e920000-7ea1d000 \ opengl32 ELF 7ea20000-7eb95000 Dwarf wined3d<elf> -PE 7ea30000-7eb95000 \ wined3d ELF 7eb98000-7ec03000 Dwarf d3d8_test<elf> -PE 7eba0000-7ec03000 \ d3d8_test ELF 7ef78000-7ef85000 Deferred libnss_files.so.2 ELF 7ef88000-7ef94000 Deferred libnss_nis.so.2 ELF 7ef98000-7efb1000 Deferred libnsl.so.1 ELF 7efb8000-7efc1000 Deferred libnss_compat.so.2 ELF 7efc8000-7efff000 Dwarf d3d8<elf> -PE 7efd0000-7efff000 \ d3d8 ELF f7318000-f735d000 Deferred libm.so.6 ELF f7360000-f7364000 Deferred libdl.so.2 ELF f7368000-f750b000 Dwarf libc.so.6 ELF f7510000-f752b000 Deferred libpthread.so.0 ELF f7568000-f771d000 Dwarf libwine.so.1 ELF f7720000-f7742000 Deferred ld-linux.so.2 ELF f7744000-f7745000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\home\andrei\x\wine\dlls\d3d8\tests\d3d8_test.exe 00000009 0 <== 0000000e services.exe 0000001c 0 0000001b 0 00000016 0 00000014 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001f 0 00000018 0 00000017 0 00000013 0 00000019 plugplay.exe 0000001e 0 0000001d 0 0000001a 0 00000020 explorer.exe 00000021 0 System information: Wine build: wine-1.7.19-74-g1e7b8b7 Platform: i386 Host system: Linux Host version: 3.14.4-gentoo
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #1 from Tom Stellard tstellar@gmail.com --- Can you post the output of R600_DEBUG=cs ?
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #2 from Michel Dänzer michel@daenzer.net --- (In reply to comment #1)
Can you post the output of R600_DEBUG=cs ?
Make that R600_DEBUG=vs , since the crash occurs in util_make_vertex_passthrough_shader_with_so().
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #3 from Henri Verbeet hverbeet@gmail.com --- For what it's worth, test_fpu_setup() tests creating a D3D device with a custom FPU control word. (The background on that is that creating a D3D device should setup the FPU in a specific way, depending on if D3DCREATE_FPU_PRESERVE is specified or not.) My guess would be that something in llvm doesn't expect to be called with a non-default FPU control word.
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #4 from Andrei Slavoiu ansla80@yahoo.com --- Created attachment 104309 --> https://bugs.freedesktop.org/attachment.cgi?id=104309&action=edit r600_debug_vs.log
Log file with R600_DEBUG=vs
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #5 from Andrei Slavoiu ansla80@yahoo.com --- BTW, I just noticed that in the latest backtrace util_make_vertex_passthrough_shader_with_so no longer appears. Instead it starts from util_make_empty_fragment_shader. I tried adding R600_DEBUG=fs but no extra info was printed.
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #6 from Michel Dänzer michel@daenzer.net --- (In reply to comment #5)
I tried adding R600_DEBUG=fs but no extra info was printed.
That should be R600_DEBUG=ps for the pixel/fragment shader (you can see a list of supported debugging options with R600_DEBUG=help).
Anyway, this is probably related to comment #3.
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #7 from Roland Scheidegger sroland@vmware.com --- Specifically it looks like the wine test actually tries a control word which enables all fpu exceptions. Seems like nvidia drivers had the same problem at some point: http://bugs.winehq.org/show_bug.cgi?id=28634 Looks like this is happening purely for testing if a fpu control word would be preserved, the actual value used by d3d does disable them just fine (though, of course, this could also happen on any app, not just wine, if it unmasks exceptions before calling into mesa code). I vaguely remember similar issues in the past in other parts of mesa code. Though IIRC you aren't actually expected to leave the fpu control word in a non-standard state when you're calling into library code, so I'm not really sure if this qualifies as a mesa bug. In any way since this happens in llvm code finally here it might even be a bug there. I guess the only way to fix this kind of bug in mesa would be to change the fpu control word on all entry points which could trigger numerical exceptions (and when additionally also consistent results are on the wish list, would need to change it on all entrypoints which could do some fpu calculations)) which I think is not reasonable.
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #8 from Henri Verbeet hverbeet@gmail.com --- (In reply to comment #7)
Looks like this is happening purely for testing if a fpu control word would be preserved, the actual value used by d3d does disable them just fine (though, of course, this could also happen on any app, not just wine, if it unmasks exceptions before calling into mesa code).
It's perhaps important to point out that Wine isn't a single application as such, and we don't have a lot of control over how individual applications setup the FPU. The test in question exists because some applications expect us to setup the FPU in a specific way, while others expect us to leave it alone. Without having looked much into the llvm source for the backtrace, it's perhaps also a bit odd that compiling a pass-through shader is doing anything involving denormals in the first place.
Though IIRC you aren't actually expected to leave the fpu control word in a non-standard state when you're calling into library code, so I'm not really sure if this qualifies as a mesa bug. In any way since this happens in llvm code finally here it might even be a bug there. I guess the only way to fix
Mostly just for reference, regressions every now and then aside, the Wine D3D tests pretty much just pass with r600g / sb; that's currently my main development setup. (And somewhat off-topic, but not entirely unrelated to this bug, the reason that that's not a radeonsi system is because I think the llvm dependency is just painful to work with.)
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #9 from Andrei Slavoiu ansla80@yahoo.com --- Created attachment 104462 --> https://bugs.freedesktop.org/attachment.cgi?id=104462&action=edit r600_debug_ps.log
Output when ran with R600_DEBUG=ps
https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #10 from Roland Scheidegger sroland@vmware.com --- (In reply to comment #8)
(In reply to comment #7)
Looks like this is happening purely for testing if a fpu control word would be preserved, the actual value used by d3d does disable them just fine (though, of course, this could also happen on any app, not just wine, if it unmasks exceptions before calling into mesa code).
It's perhaps important to point out that Wine isn't a single application as such, and we don't have a lot of control over how individual applications setup the FPU. The test in question exists because some applications expect us to setup the FPU in a specific way, while others expect us to leave it alone. Without having looked much into the llvm source for the backtrace, it's perhaps also a bit odd that compiling a pass-through shader is doing anything involving denormals in the first place.
Well with analsysis lots of things can go on. As a simple example, llvm could for instance recognize some float const is the same as some int const, and I could easily imagine just such basic analysis throwing fpu exceptions all over the place. As far as I can tell though, if an app doesn't set that fpu preserve bit, d3d will set some single precision mode with trunc rounding, but still have all exceptions masked. And if an app does set the fpu preserve bit, the control word will be left alone - near certainly in this case fpu exceptions are still masked (but potentially rounding / precision bits different) because noone wants to bother with them (and all exceptions masked is the default). (That second case is what you'd get with "ordinary" apps outside of wine, and it doesn't look like it's really a problem in practice. So, only the test in wine really hits that.)
Though IIRC you aren't actually expected to leave the fpu control word in a non-standard state when you're calling into library code, so I'm not really sure if this qualifies as a mesa bug. In any way since this happens in llvm code finally here it might even be a bug there. I guess the only way to fix
Mostly just for reference, regressions every now and then aside, the Wine D3D tests pretty much just pass with r600g / sb; that's currently my main development setup. (And somewhat off-topic, but not entirely unrelated to this bug, the reason that that's not a radeonsi system is because I think the llvm dependency is just painful to work with.)
The dependency might be painful but home-grown optimizers will get pretty complex fast. Besides, if you really have apps which set the control word to unmask exceptions, I'm pretty sure you can trigger exceptions inside core mesa too. As said, I'm not entirely sure what the expected behavior really is if you call into library code with non-default fpu control word. On some cpus setting the fpu control word can actually be very expensive (though some have it fully pipelined now so it's cheap).
https://bugs.freedesktop.org/show_bug.cgi?id=79575
Samuel Pitoiset samuel.pitoiset@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #11 from Samuel Pitoiset samuel.pitoiset@gmail.com --- Quite old bug (almost 3 years ago). The AMD open source stack has largely evolved since 2014. Closing.
https://bugs.freedesktop.org/show_bug.cgi?id=79575
Samuel Pitoiset samuel.pitoiset@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |WONTFIX
--- Comment #12 from Samuel Pitoiset samuel.pitoiset@gmail.com --- As discussed offline with Michel Dänzer, the status should be WONTFIX rather than FIXED. Sorry for the noise.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org