Please post a stack trace of when the game crashes. Something is fishy though, replaying your apitrace requires more than 48GiB of RAM for some reason and I don't have that.
neither do I, I have 16Gb.
What do you mean by a stack trace? I get nothing more from Wine that the log I posted.
The window that wine opens when an application crashes contains a stack trace.
Right but I don't get that in this crash, the game sort of freezes for a couple seconds and then it just goes back to the terminal.
As for replaying the trace, I've just done it without issue. In case it matters I used the mingw build from https://people.freedesktop.org/~jrfonseca/apitrace/ , I was getting pagefault errors with the msvc one.
Without what issue exactly? If you can successfully replay the apitrace with DXVK without getting a crash, it's useless to debug this problem.
the game sort of freezes for a couple seconds and then it just goes back to the terminal.
That's not particularly helpful either, sadly. Does dmesg complain about out-of-memory errors?
Oh you meant replaying it with DXVK, I meant with standard Wine.
With DXVK, replaying works fine till it ends earlier than without DXVK.
Looking at dmesg, d3dretrace indeed got killed from an OOM issue at the time the game would crash, so maybe that's the issue.
I had a similar issue with Rise Of The Tomb Raider when RADV_TRACE_FILE was set, it's not set currently.
Is there any reason why DXVK or radv would require so much memory in that scene?
No, that's what I'm currently trying to debug. Sadly, none of the debugging tools for memory allocation issues are completely useless for wine and I haven't managed to figure out anything so far, so this issue will be very hard to even find (let anone, fix).
The RADV_TRACE_FILE stuff is unrelated, it's known to eat a lot of memory in some cases.
Probably a naive question, but from the trace and with your knowledge, couldn't you see what calls create this memory issue and then with guesswork find whether the issue lies in DXVK or RADV?
I'm getting fresh llvm and mesa in case it's something that creeped in last week and maybe got fixed since.
Well as expected newer Mesa/LLVM + reboot didn't change anything.
I just randomly figured out by enabling debug logging that RADV or LLVM are responsible for the huge allocation while trying to compile a compute shader. If necessary I'll file a Mesa bug.
Awesome luck!
I don't understand how a compile failure leads to so much memory used. Does it keep retrying in parallel for ever or something?
Thank you!
By failure I mean that the compilation itself takes so much memory and eventually dies. No idea why though, RADV devs will have to debug that. This bug does not occur on Nvidia drivers.
Oooooh I see.
Is there any way on your end to blacklist this shader or fake it to see if that's it?
Should be fixed in latest master, at least I can replay your trace now.
I've tested other places where it crashed and it worked fine now.
Thank you very much for the quick fix!
Alright, thanks for the feedback.
Of course!
Is there a need to create a bug for RADV after all? If so, did you do it or should I?
Thanks!
RADV_TRACE_FILEx2 2018-07
With DXVK the game will always crashes in certain circumstances, but I'm not sure what that means.
The game will always crash when starting a new game from scratch when the prologue should play, but if it's not a fresh gameplay, it's fine, I'm able to enter the city and interact with things, in that case the game will crash once I start an event of some sort: start a training lesson, enter the colosseum, etc.
Software information
Dragon Ball Xenoverse 2, config: https://imgur.com/delete/vMIvpBv5cOAtCc2
System information
Apitrace file(s)
Log files
I have to admit that the game is not 100% stable with simply Wine, but the crashes are fairly random and not reproducible unlike those when using DXVK.
Thanks!