[Bug 73320] New: [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation
https://bugs.freedesktop.org/show_bug.cgi?id=73320
Priority: medium Bug ID: 73320 Assignee: dri-devel@lists.freedesktop.org Summary: [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation Severity: major Classification: Unclassified OS: Linux (All) Reporter: freedesktop.org@inequation.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa
(this is possibly a duplicate of bug #72228)
First of all, this report is based on a user's report - I do not have the software/hardware combo to reproduce. I can, however, provide Steam keys for the game to Mesa developers for free if it is needed, just shoot me an email.
A user of Painkiller Hell & Damnation has reported crashes when using radeonsi from Mesa 10.1.0-devel (git-5a51c1b saucy-oibaf-ppa). LLVM aborts with the following message:
LLVM ERROR: ran out of registers during register allocation
Relevant part of the backtrace:
#7 0xb7a20791 in __run_exit_handlers (status=status@entry=1, listp=0xb7b9d3e4 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77 #8 0xb7a2081d in __GI_exit (status=1) at exit.c:99 #9 0xb5d28ee3 in llvm::report_fatal_error(llvm::Twine const&, bool) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #10 0xb5d28fdb in llvm::report_fatal_error(char const*, bool) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #11 0xb54cf6de in llvm::RegAllocBase::allocatePhysRegs() () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #12 0xb54dec28 in ?? () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #13 0xb545781e in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #14 0xb5638974 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #15 0xb5638a28 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #16 0xb563b195 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #17 0xb563b336 in llvm::legacy::PassManager::run(llvm::Module&) () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #18 0xb5da1bb9 in ?? () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #19 0xb5da1f30 in LLVMTargetMachineEmitToMemoryBuffer () from /usr/lib/i386-linux-gnu/libLLVM-3.4.so.1 #20 0xb6b92b17 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #21 0xb6b80f30 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #22 0xb6b81a9e in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #23 0xb6b8a382 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #24 0xb6b8a4e3 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #25 0xb698f60e in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #26 0xb6990966 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #27 0xb6956443 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #28 0xb695339e in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #29 0xb6968230 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #30 0xb6937891 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #31 0xb6938e4c in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #32 0xb6939254 in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #33 0xb693934f in ?? () from /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so #34 0x08b65086 in FMeshDrawingPolicy::DrawMesh(FMeshBatch const&, int) const ()
Anything I can do to improve the diagnostics?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #1 from Jakob Nixdorf flocke@shadowice.org --- I can confirm the same error with Deadfall Adventures on the current git version of Mesa with LLVM 3.4.
The error is the same, I will try to provide a backtrace later today and maybe Leszek can also get his hands on some Steam keys for Deadfall for the Mesa developers.
Should I open a new report for Deadfall or can we assume this is the same bug?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #2 from Tom Stellard tstellar@gmail.com --- Are you using the released version of LLVM 3.4 or an older git snapshot? If you are using the released version of LLVM 3.4, can you run the game with the environment variable: R600_DEBUG=ps,vs and post the output?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #3 from Jakob Nixdorf flocke@shadowice.org --- I'm using the release version of LLVM 3.4 and ran the game with your debug option:
'R600_DEBUG=ps,vs ./ADVGame.sh > ADVGame_R600_DEBUG.log 1>&2'
Since I could not upload the file here (to big) I stored it on my server: http://shadowice.org/~flocke/linux/misc/ADVGame_R600_DEBUG.log
I hope this helps a little, I can try to provide additional information if needed.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #4 from ubu ubuntuaddictedubu@gmail.com --- I'm experiencing the same crash but with Deadfall Adventures. A Farm51 and Nordic games are the same people who made PKHD. I have the entire terminal output from launching the game here: http://pastebin.com/5GqDnYjQ
I was using Xubuntu 13.10 with a 3.13 kernel and this PPA for the graphics drivers. https://launchpad.net/~oibaf/+archive/graphics-drivers
System info per steam:Processor Information: Vendor: AuthenticAMD CPU Family: 0x12 CPU Model: 0x1 CPU Stepping: 0x0 CPU Type: 0x0 Speed: 2999 Mhz 4 logical processors 4 physical processors HyperThreading: Unsupported FCMOV: Supported SSE2: Supported SSE3: Supported SSSE3: Unsupported SSE4a: Supported SSE41: Unsupported SSE42: Unsupported
Network Information: Network Speed:
Operating System Version: Ubuntu 13.10 (64 bit) Kernel Name: Linux Kernel Version: 3.13.0-031300-generic X Server Vendor: The X.Org Foundation X Server Release: 11405000 X Window Manager: Xfwm4 Steam Runtime Version: steam-runtime-release_2013-10-23
Video Card: Driver: X.Org Gallium oibaf PPA
Driver Version: oibaf PPA OpenGL Version: oibaf PPA Desktop Color Depth: 24 bits per pixel Monitor Refresh Rate: 59 Hz VendorID: 0x1002 DeviceID: 0x683d Number of Monitors: 1 Number of Logical Video Cards: 1 Primary Display Resolution: 1680 x 1050 Desktop Resolution: 1680 x 1050 Primary Display Size: 18.66" x 11.65" (21.97" diag) 47.4cm x 29.6cm (55.8cm diag) Primary VRAM Not Detected
Sound card: Audio device: Realtek ALC892
Memory: RAM: 7977 Mb
Miscellaneous: UI Language: English LANG: en_US.UTF-8 Microphone: Not set Total Hard Disk Space Available: 413941 Mb Largest Free Hard Disk Block: 385886 Mb
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #5 from ubu ubuntuaddictedubu@gmail.com --- sorry, i thought steam info would've listed my model gpu but i notice now it didn't. I have an XFX HD7770 Black Edition
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #6 from Leszek Godlewski freedesktop.org@inequation.org --- I will gladly provide free Steam keys for both Painkiller Hell & Damnation and Deadfall Adventures for developers who step up and try to tackle this! Just shoot me an email at the address I'm posting this from!
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #7 from farmboy0+freedesktop@googlemail.com --- I am getting the same error with LLVM 3.4, Mesa Git and using radeonsi when I try running 3D Mark 2000 under wine.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
Tom Stellard tstellar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |75276
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #8 from Dan Ziemba zman0900@gmail.com --- Same "LLVM ERROR: ran out of registers during register allocation" here when running Brutal Legend from Steam. The crash doesn't happen until part way through the loading screen when loading a save. Works fine in the main menus. This game was working before when I had an nvidia gtx260 card, but crashes now that I have switched to radeon hd 7850.
Software: Kernel 3.13.6 Mesa 10.0.3 Xen 4.3.1 (running under dom0)
Hardware: Intel i7 3770 AMD Radeon HD 7850: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850]
I will upgrade to the latest versions available in Arch this weekend to see if mesa 10.1 / linux 3.13 fixes it. If not, I'll attempt git versions.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #9 from Dan Ziemba zman0900@gmail.com --- Sorry, that was kernel 3.12.6, not 3.13.6
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #10 from shadedarkken@gmail.com --- (In reply to comment #8)
Same "LLVM ERROR: ran out of registers during register allocation" here when running Brutal Legend from Steam. The crash doesn't happen until part way through the loading screen when loading a save. Works fine in the main menus. This game was working before when I had an nvidia gtx260 card, but crashes now that I have switched to radeon hd 7850.
Software: Kernel 3.13.6 Mesa 10.0.3 Xen 4.3.1 (running under dom0)
Hardware: Intel i7 3770 AMD Radeon HD 7850: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850]
I will upgrade to the latest versions available in Arch this weekend to see if mesa 10.1 / linux 3.13 fixes it. If not, I'll attempt git versions.
Got the same on Arch with linux 3.13 and mesa-git from aur. Installing from aur llvm-svn and lib32-llvm-snv fixed this problem. My card is Radeon R9 270X 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn [1002:6810].
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #11 from Tom Stellard tstellar@gmail.com --- Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #12 from Jakob Nixdorf flocke@shadowice.org --- I tried your patch with the newest SVN version of LLVM but got a different error (http://shadowice.org/~flocke/linux/misc/ADVGame_crash_backtrace.log).
Can I safely apply your patch to LLVM 3.4 to find out if the error comes from the SVN version?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #13 from Tom Stellard tstellar@gmail.com --- (In reply to comment #12)
I tried your patch with the newest SVN version of LLVM but got a different error (http://shadowice.org/~flocke/linux/misc/ADVGame_crash_backtrace.log).
Can I safely apply your patch to LLVM 3.4 to find out if the error comes from the SVN version?
Can you post the output of R600_DEBUG=ps,vs with the patch applied?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #14 from Jakob Nixdorf flocke@shadowice.org --- This is the log for the patched LLVM (SVN) with R600_DEBUG=ps,vs enabled: http://shadowice.org/~flocke/linux/misc/ADVGame_R600_DEBUG_patched.log
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #15 from Dan Ziemba zman0900@gmail.com --- (In reply to comment #11)
Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675
I didn't try this patch, but I did build LLVM from svn (202114) and mesa from git (61630). Also upgraded my kernel to 3.13.5. Brutal Legend runs now, and seems to work fine. Performance is pretty good too.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #16 from farmboy0+freedesktop@googlemail.com --- The patch doesnt apply cleanly to llvm 3.4 nor to the git master of llvm. I also had trouble rebuilding mesa git master when I switched to llvm git master to try without the patch first.
I found 2 more occurences of the error. The first one is random crashes in Antichamber. The 2nd is a crash near the beginning of the Syberia game running under wine.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #17 from Tom Stellard tstellar@gmail.com --- Can you try this branch:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #18 from Jakob Nixdorf flocke@shadowice.org --- On the first try the game didn't crash immediately but caused a GPU lockup before the title-screen appeared. I will try to debug it later today.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #19 from farmboy0+freedesktop@googlemail.com --- (In reply to comment #17)
Can you try this branch:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes
I cannot compile your repo with current clang git repo checked out in tools. Not sure if I am doing something wrong here or something else is.
Heres the first part of the error message:
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0, from HeaderMap.cpp:16: /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57: error: expected template-name before ‘<’ token /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57: error: expected ‘{’ before ‘<’ token /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57: error: expected unqualified-id before ‘<’ token In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0, from HeaderMap.cpp:16: /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:130:34: error: invalid use of incomplete type ‘class clang::vfs::FileSystem’ In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0, from HeaderMap.cpp:16: /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7: error: forward declaration of ‘class clang::vfs::FileSystem’ In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0, from HeaderMap.cpp:16: /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:150:25: error: ‘llvm::ErrorOrclang::vfs::Status clang::vfs::OverlayFileSystem::status(const llvm::Twine&)’ marked override, but does not override /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:151:20: error: ‘llvm::error_code clang::vfs::OverlayFileSystem::openFileForRead(const llvm::Twine&, llvm::OwningPtrclang::vfs::File&)’ marked override, but does not override In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:17:0, from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20, from HeaderMap.cpp:16: /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In instantiation of ‘static void llvm::IntrusiveRefCntPtrInfo<T>::release(T*) [with T = clang::vfs::FileSystem]’: /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:176:31: required from ‘void llvm::IntrusiveRefCntPtr<T>::release() [with T = clang::vfs::FileSystem]’ /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:146:29: required from ‘llvm::IntrusiveRefCntPtr<T>::~IntrusiveRefCntPtr() [with T = clang::vfs::FileSystem]’ /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:166:78: required from here /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:89:35: error: invalid use of incomplete type ‘class clang::vfs::FileSystem’ In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0, from HeaderMap.cpp:16: /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7: error: forward declaration of ‘class clang::vfs::FileSystem’ In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:17:0, from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20, from HeaderMap.cpp:16: /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In instantiation of ‘static void llvm::IntrusiveRefCntPtrInfo<T>::retain(T*) [with T = clang::vfs::FileSystem]’: /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:175:30: required from ‘void llvm::IntrusiveRefCntPtr<T>::retain() [with T = clang::vfs::FileSystem]’ /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:123:7: required from ‘llvm::IntrusiveRefCntPtr<T>::IntrusiveRefCntPtr(const llvm::IntrusiveRefCntPtr<T>&) [with T = clang::vfs::FileSystem; llvm::IntrusiveRefCntPtr<T> = llvm::IntrusiveRefCntPtrclang::vfs::FileSystem]’ /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:231:12: required from here /home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:88:34: error: invalid use of incomplete type ‘class clang::vfs::FileSystem’ In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0, from HeaderMap.cpp:16: /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7: error: forward declaration of ‘class clang::vfs::FileSystem’
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #20 from Tom Stellard tstellar@gmail.com --- You don't need clang for graphics, so you can remove it from the tools directory. If you do want to build clang for some reason you need to make sure your checkout of clang is from roughly the same date and time as the LLVM checkout you are using.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #21 from farmboy0+freedesktop@googlemail.com --- I amanaged to build llvm and mesa.
Here's my test results: As for both wine applications 3D Mark 2000 and Syberia, the error is gone and both applications continue past normally.
But Antichamber will crash the system hard. I have found place in the game where the llvm error always happens. When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont exit with the error it will instead deadlock the whole system, only option is reboot.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #22 from rainyday26@gmail.com --- I'm also getting this same error when trying to run Diablo III: Reaper of Souls via Wine. My setup is identical to ubu's with the only differences being that I'm using Netrunner (KDE) and that my graphics card is a HD 7750. When running the game, it consistently crashes after retrieving the character list with the "LLVM runs out of registers" error.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #23 from Sean Rhone Espionage724@gmail.com --- (In reply to comment #22)
I'm also getting this same error when trying to run Diablo III: Reaper of Souls via Wine. My setup is identical to ubu's with the only differences being that I'm using Netrunner (KDE) and that my graphics card is a HD 7750. When running the game, it consistently crashes after retrieving the character list with the "LLVM runs out of registers" error.
Can also confirm a similar scenario with Diablo III (using Radeon HD 7850, Kernel 3.14.0-999-generic #201404020331, Xubuntu 14.04, oibaf's PPA, Wine 1.7.15).
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #24 from Tom Stellard tstellar@gmail.com --- DId yo(In reply to comment #21)
I amanaged to build llvm and mesa.
Here's my test results: As for both wine applications 3D Mark 2000 and Syberia, the error is gone and both applications continue past normally.
But Antichamber will crash the system hard. I have found place in the game where the llvm error always happens. When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont exit with the error it will instead deadlock the whole system, only option is reboot.
Did you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #25 from farmboy0+freedesktop@googlemail.com --- (In reply to comment #24)
DId yo(In reply to comment #21)
I amanaged to build llvm and mesa.
Here's my test results: As for both wine applications 3D Mark 2000 and Syberia, the error is gone and both applications continue past normally.
But Antichamber will crash the system hard. I have found place in the game where the llvm error always happens. When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont exit with the error it will instead deadlock the whole system, only option is reboot.
Did you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes
~/workspace/llvm $ git --no-pager log -1 commit 14e6c5b9e0a0bf05afcaf4f1154f0cf82c4b5fd2 Author: Tom Stellard thomas.stellard@amd.com Date: Mon Mar 3 14:27:38 2014 -0500
R600/SI: Implement VGPR register spilling
VGPRs are spilled to LDS.
Antichamber doesnt crash right away. When it happens it looks to me like the graphics card became very very busy suddenly. Then the screen goes black like it doesnt get a signal anymore. After that it crashes.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #26 from Jakob Nixdorf flocke@shadowice.org --- Like I said in my last comment, with your branch the GPU locks up after a (very) short while. I don't have time at the moment (final exams), but I will try to debug it as soon as I get the time (maybe in 4 weeks), if it isn't fixed until then.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #27 from Tom Stellard tstellar@gmail.com --- Created attachment 97521 --> https://bugs.freedesktop.org/attachment.cgi?id=97521&action=edit Work around for crash
Hi can you try this LLVM patch. You will need to apply it on top of the very latest LLVM tree and also use the latest Mesa from git.
You will likely experience mis-rendering with this patch, but hopefully the crash and hang will be gone.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
Tom Stellard tstellar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #97521|0 |1 is obsolete| |
--- Comment #28 from Tom Stellard tstellar@gmail.com --- Created attachment 97522 --> https://bugs.freedesktop.org/attachment.cgi?id=97522&action=edit Work Around
Sorry, I posted the wrong patch before. Try this one.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #29 from farmboy0+freedesktop@googlemail.com --- Patch doesnt compile: SIInstrInfo.cpp:198:41: error: invalid use of incomplete type ‘const class llvm::Function’
https://bugs.freedesktop.org/show_bug.cgi?id=73320
Tom Stellard tstellar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #97522|0 |1 is obsolete| |
--- Comment #30 from Tom Stellard tstellar@gmail.com --- Created attachment 97539 --> https://bugs.freedesktop.org/attachment.cgi?id=97539&action=edit Work around v2
This one should compile.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #31 from farmboy0+freedesktop@googlemail.com --- LLVM triggered Diagnostic Handler: SIInstrInfo::storeRegToStackSlot - Can't spill VGPR! <several times the above message> ./Antichamber.sh: line 3: 3074 Segmentation fault ./UDKGame-Linux $@
Crash is gone.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #32 from Tom Stellard tstellar@gmail.com --- (In reply to comment #31)
LLVM triggered Diagnostic Handler: SIInstrInfo::storeRegToStackSlot - Can't spill VGPR!
<several times the above message> ./Antichamber.sh: line 3: 3074 Segmentation fault ./UDKGame-Linux $@
Crash is gone.
The crash is gone, but you are now seeing a segfault? Can you get a backtrace?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #33 from farmboy0+freedesktop@googlemail.com --- Program received signal SIGSEGV, Segmentation fault. 0xf4ba33e1 in llvm::SIInstrInfo::copyPhysReg (this=0x43f6b140, MBB=..., MI=..., DL=..., DestReg=0, SrcReg=106, KillSrc=true) at SIInstrInfo.cpp:160 160 while (unsigned SubIdx = *SubIndices++) { (gdb) bt #0 0xf4ba33e1 in llvm::SIInstrInfo::copyPhysReg (this=0x43f6b140, MBB=..., MI=..., DL=..., DestReg=0, SrcReg=106, KillSrc=true) at SIInstrInfo.cpp:160 #1 0xf50766b8 in (anonymous namespace)::ExpandPostRA::LowerCopy (this=0x44b60e00, MI=0x45013d20) at ExpandPostRAPseudos.cpp:165 #2 0xf50768b3 in (anonymous namespace)::ExpandPostRA::runOnMachineFunction (this=0x44b60e00, MF=...) at ExpandPostRAPseudos.cpp:213 #3 0xf50f264f in llvm::MachineFunctionPass::runOnFunction (this=0x44b60e00, F=...) at MachineFunctionPass.cpp:33 #4 0xf4dc053f in llvm::FPPassManager::runOnFunction (this=0x446590c0, F=...) at LegacyPassManager.cpp:1540 #5 0xf4dc06e0 in llvm::FPPassManager::runOnModule (this=0x446590c0, M=...) at LegacyPassManager.cpp:1560 #6 0xf4dc09e4 in (anonymous namespace)::MPPassManager::runOnModule (this=0x431b3380, M=...) at LegacyPassManager.cpp:1618 #7 0xf4dc0f53 in llvm::legacy::PassManagerImpl::run (this=0x44803000, M=...) at LegacyPassManager.cpp:1725 #8 0xf4dc1147 in llvm::legacy::PassManager::run (this=0xffff6b08, M=...) at LegacyPassManager.cpp:1760 #9 0xf5291a59 in LLVMTargetMachineEmit (T=0x44d746c0, M=0x445881c0, OS=..., codegen=LLVMObjectFile, ErrorMessage=0xffff6be8) at TargetMachineC.cpp:233 #10 0xf5291bed in LLVMTargetMachineEmitToMemoryBuffer (T=0x44d746c0, M=0x445881c0, codegen=LLVMObjectFile, ErrorMessage=0xffff6be8, OutMemBuf=0xffff6be0) at TargetMachineC.cpp:259 #11 0xf5bab1f8 in radeon_llvm_compile (M=0x445881c0, binary=0xffff6c70, gpu_family=0xf5fb96f1 "verde", dump=0) at radeon_llvm_emit.c:148 #12 0xf5b8c7d5 in si_compile_llvm (sctx=0xc148100, shader=0x44db9800, mod=0x445881c0) at si_shader.c:2306 #13 0xf5b8d448 in si_pipe_shader_create (ctx=0xc148100, shader=0x44db9800) at si_shader.c:2583 #14 0xf5b92660 in si_shader_select (ctx=0xc148100, sel=0x448adc80) at si_state.c:2114 #15 0xf5b9279f in si_create_shader_state (ctx=0xc148100, state=0x43f6b508, pipe_shader_type=1) at si_state.c:2146 #16 0xf5b927e8 in si_create_fs_state (ctx=0xc148100, state=0x43f6b508) at si_state.c:2158 #17 0xf5da395a in st_translate_fragment_program (st=0xbf90000, stfp=0x44c01680, key=0xffffb970) at state_tracker/st_program.c:782 #18 0xf5da3a55 in st_get_fp_variant (st=0xbf90000, stfp=0x44c01680, key=0xffffb970) at state_tracker/st_program.c:819 #19 0xf5d60b4b in update_fp (st=0xbf90000) at state_tracker/st_atom_shader.c:92 #20 0xf5d5b80d in st_validate_state (st=0xbf90000) at state_tracker/st_atom.c:212 #21 0xf5d7b220 in st_draw_vbo (ctx=0xcf2f000, prims=0xffffbb1c, nr_prims=1, ib=0xffffbb38, index_bounds_valid=1 '\001', min_index=0, max_index=4, tfb_vertcount=0x0, indirect=0x0) at state_tracker/st_draw.c:198 #22 0xf5d3aadf in vbo_handle_primitive_restart (ctx=0xcf2f000, prim=0xffffbb1c, nr_prims=1, ib=0xffffbb38, index_bounds_valid=1 '\001', min_index=0, max_index=4) at vbo/vbo_exec_array.c:591 #23 0xf5d3b6a5 in vbo_validated_drawrangeelements (ctx=0xcf2f000, mode=4, index_bounds_valid=1 '\001', start=0, end=4, count=6, type=5123, indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:1014 #24 0xf5d3b90e in vbo_exec_DrawRangeElementsBaseVertex (mode=4, start=0, end=4, count=6, type=5123, indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0) at vbo/vbo_exec_array.c:1122 #25 0xf5d3b9cf in vbo_exec_DrawRangeElements (mode=4, start=0, end=4, count=6, type=5123, ---Type <return> to continue, or q <return> to quit--- indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>) at vbo/vbo_exec_array.c:1142 #26 0x08baac6b in RHIDrawIndexedPrimitiveUP (VertexDataStride=32, VertexData=0xffffbc40, IndexDataStride=2, IndexData=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, NumPrimitives=2, NumVertices=4, MinVertexIndex=0, PrimitiveType=0) at ../../Development/Src/Engine/Inc/RHIMethods.h:1658 #27 DrawDenormalizedQuad (X=0, Y=0, SizeX=420, SizeY=247, U=0, V=0, SizeU=420, SizeV=247, TargetSizeX=TargetSizeX@entry=422, TargetSizeY=258, TextureSizeX=TextureSizeX@entry=422, TextureSizeY=258, ClipSpaceQuadZ=ClipSpaceQuadZ@entry=0) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneFilterRendering.cpp:199 #28 0x08b76416 in ApplyRadialBlur (SourceFilterBuffer=SRTI_FilterColor1, DestFilterBuffer=SRTI_FilterColor0, BlurVectorScale=1, LightSceneInfo=0x42a63c00, View=...) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:872 #29 FSceneRenderer::RenderLightShafts (this=this@entry=0x44d3c900) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:1113 #30 0x08bb6500 in FSceneRenderer::RenderDPGEnd (this=this@entry=0x44d3c900, DPGIndex=DPGIndex@entry=1, bDeferPrePostProcessResolve=bDeferPrePostProcessResolve@entry=1, bSceneColorDirty=@0xffffbf80: 1, bIsOcclusionTesting=1) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2194 #31 0x08bc15ee in FSceneRenderer::Render (this=this@entry=0x44d3c900) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2670 #32 0x08bc16c4 in RenderViewFamily_RenderThread (SceneRenderer=SceneRenderer@entry=0x44d3c900) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4166 #33 0x08bc1877 in Execute (this=<synthetic pointer>) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381 #34 BeginRenderingViewFamily (Canvas=0xffffc6a4, ViewFamily=0xffffc4f0) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381 #35 0x0882652e in UGameViewportClient::Draw (this=0xbf14700, Viewport=0xa03bb44, Canvas=0xffffc6a4) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnPlayer.cpp:1081 #36 0x08564935 in FViewport::Draw (this=0xa03bb44, bShouldPresent=bShouldPresent@entry=1) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnClient.cpp:823 #37 0x08643249 in UGameEngine::RedrawViewports (this=0xb20e800, bShouldPresent=1) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:76 #38 0x08649ae5 in UGameEngine::Tick (this=0xb20e800, DeltaSeconds=0.0317840576) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:4249 #39 0x08e7b6a2 in FEngineLoop::Tick (this=this@entry=0x95c6900 <GEngineLoop>) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/LaunchEngineLoop.cpp:3970 ---Type <return> to continue, or q <return> to quit--- #40 0x08e8328c in EngineTick () at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:193 #41 GuardedMain (CmdLine=0x90cfaf0 L"", hInInstance=hInInstance@entry=0x0, hPrevInstance=hPrevInstance@entry=0x0, nCmdShow=nCmdShow@entry=0) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:290 #42 0x08e37f7d in main (argc=1, argv=0xffffcbd4) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Linux/Src/Linux.cpp:727
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #34 from filipp.andjelo@gmail.com --- Unfortunately, most of the games are affected by this bug. I'm running on HD7850 and get this error on Metro, Serious Sam 3, Xonotic (with Ultra settings), whole bunch of games on Wine (tested with Risen, Star Wars: Republic Commando and others). There are almost no (modern) games which are running currently on radeionSI. I'm using ArchLinux with Kernel 3.14.1, LLVM 3.4 everything's updated from the repos to the most recent version. Don't really want to go back to catalyst, so how can I help?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #35 from Tom Stellard tstellar@gmail.com --- Can you test this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v2
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #36 from Tom Stellard tstellar@gmail.com --- Updated v3 branch here: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #37 from filipp.andjelo@gmail.com --- Hi,
I'm new to this and doing something wrong. Do I need to compile the patched LLVM and the latest Mesa from git? Or is it sufficient to recompile Mesa 10.1.... also not quite sure, how to force my system to use the modified stuf without breaking things.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #38 from Tom Stellard tstellar@gmail.com --- (In reply to comment #37)
Hi,
I'm new to this and doing something wrong. Do I need to compile the patched LLVM and the latest Mesa from git? Or is it sufficient to recompile Mesa 10.1.... also not quite sure, how to force my system to use the modified stuf without breaking things.
I would recommend using the LLVM branch plus the latest Mesa code from git. To avoid breaking your current system, you can install LLVM to a non-standard path and then pass the --with-llvm-prefix=/path/to/llvm to mesa's configure script.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #39 from farmboy0+freedesktop@googlemail.com --- I've double and triple checked to make sure I am making no mistake but the behaviour I see with Antichamber and the v2 and v3 branches is the same as reported in comment 21.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #40 from Damian Nowak nowaker@geozone.pl --- I confirm this bug is a case for me on Radeon 7870 and Xonotic with highest details only. High details run fine. Using Arch Linux (mesa 10.1.1, llvm 3.4).
@filipp.andjelo@gmail.com Since you are using Arch too, would you mind writing a PKGBUILD that would include all the patches that we need to test? I'd love to help and test the patches out, but I'd rather stay away from digging into how to compile these things. ;-)
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #41 from filipp.andjelo@gmail.com --- Hi Damian,
unfortunately, I didn't have enough time to build appropriate packages. I built patched LLVM manually and modified mesa package from Arch repository to use my LLVM. Nevertheless, it doesn't work yet as expected. I need more time to figure out, what went wrong... when I'm done, I will probably be able to supply PKGBUILD for you...
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #42 from filipp.andjelo@gmail.com --- I just can't get it running. LLVM + mesa is compiled, but as far as I install and restart it, my system falls back to swrast and that's all.... as I said, I'm not familiar with mesa/llvm development and just don't know what's wrong...
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #43 from filipp.andjelo@gmail.com --- Hi, I still would like to help. Can somebody post a short howto build everything to test the patched code? I'd like to know, what is required aside of LLVM and Mesa? Where can I see some logs about what is failing... such things. Furthermore, shouldn't the importance of this bug raised? I mean with current state radeonsi is unusable for almost 90% of applications.... If you look at openbenchmarking.org, you will only find some low quality tests, but all the interesting stuff is broken.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #44 from farmboy0+freedesktop@googlemail.com --- Hres a short howto that I use to test this stuff:
Build llvm from a repo: (change the prefix to where you want the have this installed, the configure is setup for a 32bit build to test with wine and Antichamber)
the main llvm url is http://llvm.org/git/llvm tom stellar's repo is at git://people.freedesktop.org/~tstellar/llvm
git clone <llvm repo url> cd llvm git checkout <branch name> ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/home/eho/programs --enable-keep-symbols --enable-shared --disable-assertions --enable-libffi --enable-targets=host,cpp,r600 make -j5 install
Build mesa from git: git clone git://anongit.freedesktop.org/mesa/mesa cd mesa /configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/home/eho/programs --enable-glx --enable-shared-glapi --enable-texture-float --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --enable-osmesa --enable-asm --with-dri-drivers=swrast,radeon --with-gallium-drivers=swrast,radeonsi,r600 --with-egl-platforms=x11,wayland,drm --enable-gallium-llvm --enable-openvg --enable-gallium-egl --enable-dri --enable-xvmc --enable-dri3 --enable-vdpau --enable-r600-llvm-compiler --enable-debug make -j5 install
To run your app you do: export LD_LIBRARY_PATH=<your prefix>/lib (for me would be /home/eho/programs/lib) <call your app here>
Does this help?
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #45 from filipp.andjelo@gmail.com --- Thank you very much for your help farmboy0. I was able to build and run everything as you mentioned. First of all, my systems doesn't hang as you describe in Comment 21, all the games are (kind of) running. I tested master branch of llvm as well as http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3. Both versions don't crash anymore, but the performance is very bad. With master branch the games are stuttering heavily, every 2-3 seconds the application stops for a second. With the si-spill-fixes-v3 everything's running a bit smoother, but still very slowly. Feels like similar behavior in both cases, but using si-spill-fixes-v3 it feels like the games would "wait" for shorter period of time, therefor more often. I tested with both 64 and 32 bit builds.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #46 from farmboy0+freedesktop@googlemail.com --- (In reply to comment #45)
Thank you very much for your help farmboy0. I was able to build and run everything as you mentioned. First of all, my systems doesn't hang as you describe in Comment 21, all the games are (kind of) running. I tested master branch of llvm as well as http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3. Both versions don't crash anymore, but the performance is very bad. With master branch the games are stuttering heavily, every 2-3 seconds the application stops for a second. With the si-spill-fixes-v3 everything's running a bit smoother, but still very slowly. Feels like similar behavior in both cases, but using si-spill-fixes-v3 it feels like the games would "wait" for shorter period of time, therefor more often. I tested with both 64 and 32 bit builds.
You need to realize though that the error message of llvm running out of registers is caused by two seperate issues.
The first issue is caused by errors with the SGPR spilling in llvm 3.4, this one is fixed with llvm git or with Tom's si-spilling-fixes branch.
The second issue is recorded in https://bugs.freedesktop.org/show_bug.cgi?id=75276 and is not yet fixed as (at least for me) it causes crashes.
You can differentiate the two issues while using llvm git. If while running your app you see messages in the console to the effect of VGPR spilling not being supported your app is hit by issue number two. You should then try to run this app with Tom's si-spill-fixes-v3 branch which started to try to implement VGPR spilling if i interpret the change messages correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #47 from filipp.andjelo@gmail.com --- Ok, thank you for clarification. I know, that such statements doesn't really help to solve problems in any way, but my system doesn't crash or freeze and I also not see any messages, that the VGPR spilling is not supported...
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #48 from farmboy0+freedesktop@googlemail.com --- (In reply to comment #47)
Ok, thank you for clarification. I know, that such statements doesn't really help to solve problems in any way, but my system doesn't crash or freeze and I also not see any messages, that the VGPR spilling is not supported...
This means that your apps only had issue #1 and as i already said this one is fixed already.
My app OTOH has issue #2 and thus it cashes. If your apps had issue #2 as well but you wouldnt see any crashes that would be relevant.
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #49 from Tom Stellard tstellar@gmail.com --- Can you try this LLVM patch:
https://bugs.freedesktop.org/attachment.cgi?id=99169
https://bugs.freedesktop.org/show_bug.cgi?id=73320
--- Comment #50 from farmboy0+freedesktop@googlemail.com --- This patch on top of llvm git master makes Antichamber segfault with the following backtrace:
Program received signal SIGSEGV, Segmentation fault. 0xf5054dd3 in std::pair<llvm::SlotIndex, llvm::SlotIndex>::operator= (this=0x44fd2ff4, __p=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_pair.h:153 153 second = __p.second; (gdb) bt #0 0xf5054dd3 in std::pair<llvm::SlotIndex, llvm::SlotIndex>::operator= (this=0x44fd2ff4, __p=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_pair.h:153 #1 0xf5064027 in llvm::IntervalMapImpl::NodeBase<std::pairllvm::SlotIndex, llvm::SlotIndex, llvm::LiveInterval*, 16u>::copy<16u> ( this=0x44e14ef4, Other=..., i=228385, j=228384, Count=4294967295) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:231 #2 0xf5064b0f in llvm::IntervalMapImpl::NodeBase<std::pairllvm::SlotIndex, llvm::SlotIndex, llvm::LiveInterval*, 16u>::moveLeft ( this=0x44e14ef4, i=1, j=0, Count=4294967295) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:242 #3 0xf50643e3 in llvm::IntervalMapImpl::NodeBase<std::pairllvm::SlotIndex, llvm::SlotIndex, llvm::LiveInterval*, 16u>::erase ( this=0x44e14ef4, i=0, j=1, Size=0) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:263 #4 0xf50638d7 in llvm::IntervalMapImpl::NodeBase<std::pairllvm::SlotIndex, llvm::SlotIndex, llvm::LiveInterval*, 16u>::erase ( this=0x44e14ef4, i=0, Size=0) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:270 #5 0xf5062950 in llvm::IntervalMap<llvm::SlotIndex, llvm::LiveInterval*, 16u, llvm::IntervalMapInfollvm::SlotIndex >::iterator::erase ( this=0xffff6338) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:1876 #6 0xf5061fa8 in llvm::LiveIntervalUnion::extract (this=0x44e14ef0, VirtReg=...) at LiveIntervalUnion.cpp:68 #7 0xf506ad51 in llvm::LiveRegMatrix::unassign (this=0xbea0460, VirtReg=...) at LiveRegMatrix.cpp:96 #8 0xf5123ed7 in (anonymous namespace)::RAGreedy::tryLastChanceRecoloring (this=0x449f4000, VirtReg=..., Order=..., NewVRegs=..., FixedRegisters=..., Depth=0) at RegAllocGreedy.cpp:2067 #9 0xf51248dc in (anonymous namespace)::RAGreedy::selectOrSplitImpl (this=0x449f4000, VirtReg=..., NewVRegs=..., FixedRegisters=..., Depth=0) at RegAllocGreedy.cpp:2285 #10 0xf5124218 in (anonymous namespace)::RAGreedy::selectOrSplit (this=0x449f4000, VirtReg=..., NewVRegs=...) at RegAllocGreedy.cpp:2144 #11 0xf5116c4d in llvm::RegAllocBase::allocatePhysRegs (this=0x449f4010) at RegAllocBase.cpp:109 #12 0xf5124e05 in (anonymous namespace)::RAGreedy::runOnMachineFunction (this=0x449f4000, mf=...) at RegAllocGreedy.cpp:2343 #13 0xf50a614f in llvm::MachineFunctionPass::runOnFunction (this=0x449f4000, F=...) at MachineFunctionPass.cpp:33 #14 0xf4d6434c in llvm::FPPassManager::runOnFunction (this=0x43bd6180, F=...) at LegacyPassManager.cpp:1545 #15 0xf4d64528 in llvm::FPPassManager::runOnModule (this=0x43bd6180, M=...) at LegacyPassManager.cpp:1567 #16 0xf4d6482c in (anonymous namespace)::MPPassManager::runOnModule (this=0x4340b1c0, M=...) at LegacyPassManager.cpp:1625 #17 0xf4d64dcb in llvm::legacy::PassManagerImpl::run (this=0x439dce00, M=...) at LegacyPassManager.cpp:1734 #18 0xf4d64fbf in llvm::legacy::PassManager::run (this=0xffff6988, M=...) at LegacyPassManager.cpp:1769 #19 0xf524806d in LLVMTargetMachineEmit (T=0xa61eb40, M=0x43869540, OS=..., codegen=LLVMObjectFile, ErrorMessage=0xffff6a68) at TargetMachineC.cpp:234 #20 0xf5248201 in LLVMTargetMachineEmitToMemoryBuffer (T=0xa61eb40, M=0x43869540, codegen=LLVMObjectFile, ErrorMessage=0xffff6a68, OutMemBuf=0xffff6a60) at TargetMachineC.cpp:260 #21 0xf5b91734 in radeon_llvm_compile (M=0x43869540, binary=0xffff6af0, gpu_family=0xf5fab3fd "verde", dump=0) at radeon_llvm_emit.c:148 #22 0xf5b72b17 in si_compile_llvm (sctx=0xc146100, shader=0x44b0c000, mod=0x43869540) at si_shader.c:2342 #23 0xf5b73811 in si_pipe_shader_create (ctx=0xc146100, shader=0x44b0c000) at si_shader.c:2622 ---Type <return> to continue, or q <return> to quit--- #24 0xf5b78acf in si_shader_select (ctx=0xc146100, sel=0x4364e780) at si_state.c:2130 #25 0xf5b78c0e in si_create_shader_state (ctx=0xc146100, state=0x44afedc8, pipe_shader_type=1) at si_state.c:2162 #26 0xf5b78c57 in si_create_fs_state (ctx=0xc146100, state=0x44afedc8) at si_state.c:2174 #27 0xf5d939ae in st_translate_fragment_program (st=0xbf8b000, stfp=0x44c8d700, key=0xffffb8d0) at state_tracker/st_program.c:787 #28 0xf5d93aa9 in st_get_fp_variant (st=0xbf8b000, stfp=0x44c8d700, key=0xffffb8d0) at state_tracker/st_program.c:824 #29 0xf5d4f943 in update_fp (st=0xbf8b000) at state_tracker/st_atom_shader.c:92 #30 0xf5d4a421 in st_validate_state (st=0xbf8b000) at state_tracker/st_atom.c:213 #31 0xf5d6a224 in st_draw_vbo (ctx=0xc290000, prims=0xffffba7c, nr_prims=1, ib=0xffffba98, index_bounds_valid=1 '\001', min_index=0, max_index=4, tfb_vertcount=0x0, indirect=0x0) at state_tracker/st_draw.c:198 #32 0xf5d2944f in vbo_handle_primitive_restart (ctx=0xc290000, prim=0xffffba7c, nr_prims=1, ib=0xffffba98, index_bounds_valid=1 '\001', min_index=0, max_index=4) at vbo/vbo_exec_array.c:591 #33 0xf5d2a015 in vbo_validated_drawrangeelements (ctx=0xc290000, mode=4, index_bounds_valid=1 '\001', start=0, end=4, count=6, type=5123, indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:1014 #34 0xf5d2a27e in vbo_exec_DrawRangeElementsBaseVertex (mode=4, start=0, end=4, count=6, type=5123, indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0) at vbo/vbo_exec_array.c:1122 #35 0xf5d2a33f in vbo_exec_DrawRangeElements (mode=4, start=0, end=4, count=6, type=5123, indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>) at vbo/vbo_exec_array.c:1142 #36 0x08baac6b in RHIDrawIndexedPrimitiveUP (VertexDataStride=32, VertexData=0xffffbba0, IndexDataStride=2, IndexData=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, NumPrimitives=2, NumVertices=4, MinVertexIndex=0, PrimitiveType=0) at ../../Development/Src/Engine/Inc/RHIMethods.h:1658 #37 DrawDenormalizedQuad (X=0, Y=0, SizeX=420, SizeY=247, U=0, V=0, SizeU=420, SizeV=247, TargetSizeX=TargetSizeX@entry=422, TargetSizeY=258, TextureSizeX=TextureSizeX@entry=422, TextureSizeY=258, ClipSpaceQuadZ=ClipSpaceQuadZ@entry=0) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneFilterRendering.cpp:199 #38 0x08b76416 in ApplyRadialBlur (SourceFilterBuffer=SRTI_FilterColor1, DestFilterBuffer=SRTI_FilterColor0, BlurVectorScale=1, LightSceneInfo=0x4307b000, View=...) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:872 #39 FSceneRenderer::RenderLightShafts (this=this@entry=0x44affb00) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:1113 #40 0x08bb6500 in FSceneRenderer::RenderDPGEnd (this=this@entry=0x44affb00, DPGIndex=DPGIndex@entry=1, bDeferPrePostProcessResolve=bDeferPrePostProcessResolve@entry=1, bSceneColorDirty=@0xffffbee0: 1, bIsOcclusionTesting=1) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2194 ---Type <return> to continue, or q <return> to quit--- #41 0x08bc15ee in FSceneRenderer::Render (this=this@entry=0x44affb00) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2670 #42 0x08bc16c4 in RenderViewFamily_RenderThread (SceneRenderer=SceneRenderer@entry=0x44affb00) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4166 #43 0x08bc1877 in Execute (this=<synthetic pointer>) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381 #44 BeginRenderingViewFamily (Canvas=0xffffc604, ViewFamily=0xffffc450) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381 #45 0x0882652e in UGameViewportClient::Draw (this=0xbf341c0, Viewport=0x9fb4c04, Canvas=0xffffc604) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnPlayer.cpp:1081 #46 0x08564935 in FViewport::Draw (this=0x9fb4c04, bShouldPresent=bShouldPresent@entry=1) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnClient.cpp:823 #47 0x08643249 in UGameEngine::RedrawViewports (this=0xb201800, bShouldPresent=1) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:76 #48 0x08649ae5 in UGameEngine::Tick (this=0xb201800, DeltaSeconds=0.0484998226) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:4249 #49 0x08e7b6a2 in FEngineLoop::Tick (this=this@entry=0x95c6900 <GEngineLoop>) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/LaunchEngineLoop.cpp:3970 #50 0x08e8328c in EngineTick () at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:193 #51 GuardedMain (CmdLine=0x90cfaf0 L"", hInInstance=hInInstance@entry=0x0, hPrevInstance=hPrevInstance@entry=0x0, nCmdShow=nCmdShow@entry=0) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:290 #52 0x08e37f7d in main (argc=1, argv=0xffffcb34) at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Linux/Src/Linux.cpp:727
https://bugs.freedesktop.org/show_bug.cgi?id=73320
Tom Stellard tstellar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
--- Comment #51 from Tom Stellard tstellar@gmail.com ---
*** This bug has been marked as a duplicate of bug 75276 ***
https://bugs.freedesktop.org/show_bug.cgi?id=73320 Bug 73320 depends on bug 75276, which changed state.
Bug 75276 Summary: Implement VGPR Register Spilling https://bugs.freedesktop.org/show_bug.cgi?id=75276
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org