Open Blisto91 opened 2 years ago
patmann03
commented
2 years ago I tried with unlimited video memory, it did not stop a crash. I'll run now with wined3d, then do an API trace.. although wondering if its an issue with wine?
Rome2_d3d11.log Rome2_dxgi.log
Proton log section with section where it fails.
Notable part of log.
patmann03
commented
2 years ago Crashed with WINED3D as well this was when trying to load a battle (that has a port). I was able to get through the other battle that crashed. Also attached the whole proton log.
Seems an unimplemented function called the crash for wined3d.
3079.501:0258:025c:trace:seh:dispatch_exception code=80000100 flags=1 addr=7B011197 ip=7b011197 tid=025c
3079.501:0258:025c:trace:seh:dispatch_exception info[0]=6ce86000
3079.501:0258:025c:trace:seh:dispatch_exception info[1]=6ce8625f
wine: Call from 7B011197 to unimplemented function d3dx11_42.dll.D3DX11LoadTextureFromTexture, aborting
3079.501:0258:025c:trace:seh:call_stack_handlers calling handler at 55D6BB98 code=80000100 flags=1
3079.501:0258:025c:trace:loaddll:build_module Loaded L"C:\\windows\\System32\\FaultRep.dll" at 23A60000: builtin
3079.501:0258:025c:fixme:faultrep:ReportFault 006BE2B0 0x0 stub
3079.501:0258:025c:trace:loaddll:free_modref Unloaded module L"C:\\windows\\System32\\FaultRep.dll" : builtin
3079.501:0258:025c:trace:seh:call_stack_handlers handler at 55D6BB98 returned 1
3079.501:0258:025c:trace:seh:call_stack_handlers calling handler at 00404070 code=80000100 flags=1
3079.501:0258:025c:trace:seh:call_stack_handlers handler at 00404070 returned 1
3079.501:0258:025c:trace:seh:call_stack_handlers calling handler at 7BC67B00 code=80000100 flags=1
wine: Unimplemented function d3dx11_42.dll.D3DX11LoadTextureFromTexture called at address 7B011197 (thread 025c), starting debugger...
3079.501:0258:025c:trace:seh:start_debugger Starting debugger L"winedbg --auto 600 1124"
Proton log with wined3d steam-214950.log
patmann03
commented
2 years ago Ok used winetricks and installed d3dx11_42 and set winecfg to native. Was able to get into the battle... but then it crashed when I was about to win. Got a GL out of memory error, followed by Exception access violation.
Also noticed earlier in the log that it said something about "Dynamic linking not implemented yet"
4230.815:0260:0264:fixme:d3d11:d3d11_device_context_VSGetShader Dynamic linking not implemented yet.
4230.815:0260:0264:fixme:d3d11:d3d11_device_context_PSGetShader Dynamic linking not implemented yet.
4611.259:0260:0264:warn:seh:OutputDebugStringA "d3d call failed (0x8876086c) : D3DERR_INVALIDCALL\n"
4611.259:0260:0264:trace:seh:dispatch_exception code=40010006 flags=0 addr=7B012B4F ip=7b012b4f tid=0264
4611.259:0260:0264:trace:seh:dispatch_exception info[0]=00000033
4611.259:0260:0264:trace:seh:dispatch_exception info[1]=6d40a1d0
4611.259:0260:0264:warn:seh:dispatch_exception "d3d call failed (0x8876086c) : D3DERR_INVALIDCALL\n"
4611.259:0260:0264:trace:seh:call_stack_handlers calling handler at 7B0826F0 code=40010006 flags=0
4611.259:0260:0264:trace:seh:__regs_RtlUnwind code=40010006 flags=2
4611.259:0260:0264:trace:seh:__regs_RtlUnwind eax=00000000 ebx=00000000 ecx=40010006 edx=006be668 esi=006be618 edi=006be668
4611.259:0260:0264:trace:seh:__regs_RtlUnwind ebp=006be158 esp=006be150 eip=7b082686 cs=0023 ds=002b fs=0063 gs=006b flags=00000206
4611.259:0260:0264:trace:seh:__regs_RtlUnwind calling handler at 7BC573B0 code=40010006 flags=2
4611.259:0260:0264:trace:seh:__regs_RtlUnwind handler at 7BC573B0 returned 1
4611.259:0260:02c0:err:d3d:wined3d_debug_callback 0xb500590: "GL_OUT_OF_MEMORY in glMapBufferRange(map failed)".
4611.259:0260:02c0:err:d3d:wined3d_context_gl_map_bo_address Failed to map bo.
4611.259:0260:02c0:err:d3d:wined3d_debug_callback 0xb500590: "GL_OUT_OF_MEMORY in glMapBufferRange(map failed)".
4611.259:0260:02c0:err:d3d:wined3d_context_gl_map_bo_address Failed to map bo.
4611.259:0260:0264:trace:seh:dispatch_exception code=c0000005 flags=0 addr=55D6956A ip=55d6956a tid=0264
4611.259:0260:0264:trace:seh:dispatch_exception info[0]=00000001
4611.259:0260:0264:trace:seh:dispatch_exception info[1]=00000180
4611.259:0260:0264:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised
4611.259:0260:0264:trace:seh:dispatch_exception eax=29a3d1ac ebx=55a42800 ecx=00000060 edx=00000060 esi=29a3d14c edi=00000180
4611.259:0260:0264:trace:seh:dispatch_exception ebp=006be81c esp=006be758 cs=0023 ss=002b ds=002b es=002b fs=0063 gs=006b flags=00010293
4611.259:0260:0264:trace:seh:call_stack_handlers calling handler at 55D6BB98 code=c0000005 flags=0
4611.262:0260:0264:trace:loaddll:build_module Loaded L"C:\\windows\\System32\\FaultRep.dll" at 64900000: builtin
4611.262:0260:0264:fixme:faultrep:ReportFault 006BE1D0 0x0 stub
4611.262:0260:0264:trace:loaddll:free_modref Unloaded module L"C:\\windows\\System32\\FaultRep.dll" : builtin
4611.262:0260:0264:trace:seh:call_stack_handlers handler at 55D6BB98 returned 1
4611.262:0260:0264:trace:seh:call_stack_handlers calling handler at 00404070 code=c0000005 flags=0
4611.262:0260:0264:trace:seh:call_stack_handlers handler at 00404070 returned 1
4611.262:0260:0264:trace:seh:call_stack_handlers calling handler at 7BC67B00 code=c0000005 flags=0
wine: Unhandled page fault on write access to 00000180 at address 55D6956A (thread 0264), starting debugger...
4611.262:0260:0264:trace:seh:start_debugger Starting debugger L"winedbg --auto 608 1056"
Here is api trace... although I could never load a campaign map. It makes the game run incredibly slow and practically unresponsive... so not sure if I did something wrong I used the 32 bit binaries as according to the guide and info on like this is a 32 bit game.
https://drive.google.com/file/d/1xwELmS5cFWZXLRuGG77BGfhiJKPWG40d/view?usp=sharing
Blisto91
commented
2 years ago If it makes the game run slow it means you have done it right 😁 When it crashes in the loading screen with dxvk i haven't seen that it really wrote anything interesting in the proton log, like it did for shogun 2 dx9. but will double check later.
patmann03
commented
2 years ago If it makes the game run slow it means you have done it right 😁 When it crashes in the loading screen with dxvk i haven't seen that it really wrote anything interesting in the proton log, like it did for shogun 2 dx9. but will double check later.
Ok cool. Couldn't get into the actual campaign map I waited like 15 minutes so I want sure if that was going to be a problem. Thought I'd have to play to the point of loading a battle or something to provide enough data... Really hope there is a solution for this game is one of my favorites and I play with friends lol. Would love to finally nuke windows.
Blisto91
commented
2 years ago If you want to try and see if the raised vram limit makes a difference then you can try this build. It should show around 4GB ingame. Tho still the actual issue is that it crashes at all so it isn't a proper fix even if it works.
patmann03
commented
2 years ago If you want to try and see if the raised vram limit makes a difference then you can try this build. It should show around 4GB ingame. Tho still the actual issue is that it crashes at all so it isn't a proper fix even if it works.
Not sure if I installed it wrong, but that build did not increase the video memory in game, it still showed 3072 (I even deleted the game preference file as they store it in there it seems). dxgi.log shows DXVK version 1.10.1. I updated the prefix, then used the bash script to install. It had the modified flag on the d3d files so it looked liked the install worked. I did enable the DXVK_HUD and did noticed a spike in vram right at the crash coming out of a battle back to the main loading screen (nothing notable in the proton log this time). When it was running fine Vid mem heap 0 was sitting around 2800 with 2600-2700 used, when it crashed heap 0 jumped above 3k.
Any thoughts on disabling large address aware and creating a 32 bit prefix? wondering if that would have a positive impact.
Blisto91
commented
2 years ago Hmm strange, i just double checked and it shows around 4G for me. Tho i just backup my proton 7.0-2 dxvk files and shove the newly compiled ones in there instead.
Don't know if it would have an impact.
What do i need to install as winetricks for the wine version? I can't get it to launch by just installing the redist stuff that comes with the steam version.
patmann03
commented
2 years ago Interesting. I have no problems launching it.
PROTON_USE_WINED3D=1but I installed d3dx11_42 and the d3dcompiler_42
I'll nuke my prefix and try your build again from scratch
Blisto91
commented
2 years ago I can run it fine through steam/proton i thought you were using regular wine. Are you using proton?
patmann03
commented
2 years ago I can run it fine through steam/proton i thought you were using regular wine. Are you using proton?
Yes proton
Blisto91
commented
2 years ago Ah.
How are you installing dxvk into the proton prefix with the script? Just pointing WINEPREFIX at it? Only ever used it for default wine install :grin:
for proton i usually do it manually
patmann03
commented
2 years ago Yep, guess I could just move the DLLs manually lol
Blisto91
commented
2 years ago By manually btw i mean put them into steamapps/common/Proton 7.0/dist/lib64/wine/dxvk/ for what ever proton and bit version i am testing.
patmann03
commented
2 years ago By manually btw i mean put them into
steamapps/common/Proton 7.0/dist/lib64/wine/dxvk/for what ever proton and bit version i am testing.
Ok I see. Yes now I have 4gb for video memory showing
patmann03
commented
2 years ago That did make a significant improvement. I was able to play longer without crashing. I did get to a point where the game froze (didn't just crash / shut off), but I forgot to enable logging however.
Blisto91
commented
2 years ago Interesting.
Do you have a feeling if it was the same issue or a different?
patmann03
commented
2 years ago Not sure. I'm wondering if Fsync/Esync is playing a role here or another bug/regression in wine. When using proton 4.11 with the installed dlls mentioned above with wine tricks and running with wined3d I seem to have a stable experience . I'm going to try running your dxvk version and disabling fsync, then esync.
Blisto91
commented
2 years ago Worth a try. It's not unheard that some games have stability issues with fsync
patmann03
commented
2 years ago Well disabling F/Esync, installing the DLLs that I used with proton 4.11(d3dcompiler_42 & d3dx11_42) and using your 4gb dxvk build & proton ge 7-15. I just played over an hour and a half with no crashes playing several battles.
Blisto91
commented
2 years ago Eh ma gewd! Easy peasy :grin:
Still need a proper fix for the crash somewhere tho as it isnt a proper fix for GPU's with less vram. Tho dunno if dxvk even is the culprit.
patmann03
commented
2 years ago Ya. Is have to test without your build. I'm thinking esync was the culprit accessing memory out of order.
patmann03
commented
1 year ago So I tried creating a new build of dxvk v2.1 with the increased vram as I've seen others still having issues (seems to mainly be NVIDIA). But it doesn't seem to be reporting it around the 4gb with the increase I did. Do you know if there was additional changes made to how dxvk reports memory back to the game? See my fork below. I made the same change you did to the dxgi_adapter.cpp file
Blisto91
commented
1 year ago @patmann03 Hi there.
Your change seems to work fine for me. Here is Rome 2 with dxvk compiled from your fork.
And without
Yasand123
commented
1 year ago Hey! Any news on this? Is the 4048 patch good enough to make the game stable?
Blisto91
commented
1 year ago No news. Haven't checked this in a while and no specific work have been done i believe, though i can take a peek again.
There shouldn't be issues if you turn on Unlimited Video Memory (i think but maybe i misremember reread some of the above)
Edit: Actually i guess it can still crash with Unlimited Video Memory. Just tried
Blisto91
commented
1 year ago Logs from benchmark crash running at Extreme preset with Unlimited Video Memory turned on. Though happens regardless.
rome2_dxgi.log
rome2_d3d11.log
Split off from the Shogun 2 issue.
I have this save game where when i end the turn one of my fleets will get attacked by another fleet. If i go into this battle i will crash just as the loading is about to finish. Video memory on the card is not being maxed out system wide that i can see being only max at 3.2 - 3.3, but it seems to depend on how much is used since if i restart with fresh DE i might be able to get into the battle. Don't know if there is a short spike when loading into battles since when you get into the loading screen video memory actually drops to below 2GB system wide. To make it not crash consistently i have to set my graphics down to High or below (Tested on R9 380) or go into settings and turn on Unlimited Video Memory option. When the option is on you allow the game to use Swap memory and when it is off it will instead lower graphical details in the background. With the option off this seems to work fine on Windows even on my card with 2GB vram as i can load into the battle even with options set to Extreme before the battle and it will say in the loading screen i am running low and is lowering the options. On Linux with dxvk it instead seems to crash when it's done loading if there isn't enough Vram.
When i tested on my R9 380 with 4GB i can get into the battle by for example setting the options to medium, and then after i get into the battle it will allow me to set them to Ultra or Extreme. I tried to compile dxvk with the 32bit max limit changed to
0xFD000000which shows as a bit above 4000MB ingame. This seems to get rid of the crash on my 4GB card. But I'm guessing the issue is that it crashes at all when it should manage or lower the details like on windows and make it through.Software information
Total War Rome 2 Very high, Ultra & Extreme graphics settings without Unlimited Graphics memory. (Depends on background Vram used i guess)
System information
Apitrace file(s)
Log files
Made with
DXVK_LOG_LEVEL=traceon the nvidia 960 Rome2_d3d11.log Rome2_dxgi.log