italomandara / CXPatcher

A patcher to upgrade Crossover dependencies and improve compatibility
GNU General Public License v3.0
831 stars 22 forks source link

Render problem in Astrometica game #198

Open Mfarshore opened 1 month ago

Mfarshore commented 1 month ago

When running the game Astrometica after a short time I get rendering problems as shown in the attached images. The game is built using UE version 5.1. I have seen no reports of this kind of problem from PC users.

I am running on a Mac, Ventuira OS using CrossOver 24 patched with CXPatcher 5.1 to deal with the legendary UE Black Screen of Frustration.

What causes this sort of problem? Is there a way to fix it using scripting commands, or is it a bug somewhere in the Mac side software?

Screenshot 2024-06-01 at 5 08 42 PM

Screenshot 2024-06-01 at 5 20 55 PM

italomandara commented 1 month ago

What version of Crossover are you using? Have you tried d3dmetal? Have you tried patching only moltenvk and not dxvk? (in CXPAtcher options). Please let me know what happens.

Mfarshore commented 1 month ago

I am running Crossover 24 under Ventura 13.6.7 on an Intel mac, so I don't have d3dmetal. The game is UE5, so I need to use the UE hack or I will get the infamous Black Screen. Any combination with latest MVK will not run at all. DXVK is required or the game will freeze and require a forced quit. So the only patch combination is DXVK + base MVK + UE hack.

I have noticed that the CPU spikes, the fan starts up, and I have considerable input lag just before the rendering problem starts. Anything else you can suggest for debugging would be appreciated.

italomandara commented 1 month ago

you could still try the stock dxvk by not patching it. You only need to patch MoltenVK to get the ue4 Hack, it may be slower with the stock DXVK though. That's to isolate the issue, If it's a problem with MoltenVK you'll either have to wait for to fix the issue with the latest MoltenVK on CX24 or upgrade to apple silicon 😁.

Mfarshore commented 1 month ago

The stock DXVK, unpatched, has a lot of stutter and input lag. I attempted to limit that by patching the Engine.ini file to do shader compilation on load, but that did not help.

The game is definitely playable. I just have to start and stop CX regularly to clear whatever is iclogging memory. Tedious, but I do get fresh respawns of the easy pickings resources ;)

Keep this issue updated, if you please, as the problem has infected me with curiosity about the problem.

italomandara commented 1 month ago

but has the stock dxvk fixed the glitches at least?

Mfarshore commented 1 month ago

Input was so slow I did not have time to test and see; I mean really slow. The glitches take about 5-10 minutes to show up. I'll give it a try again now that I have some time to wait and see.

Mfarshore commented 1 month ago

Well, some success. Using the stock DXVK definitely slows down the glitches. I gave it a thorough test in the game where I knew I could get the glitches to return and I had to try to make them show up by extending the test. Hope this helps with the fix. Let me know if you need any more debugging tests.

I dealt with the input latency by including the following in the Engine.ini file:

[SystemSettings] ; shader compilation optimizations niagara.CreateShadersOnLoad=1 r.CreateShadersOnLoad=1 r.Shaders.Optimize=1

; input latency r.GTSyncType=1 r.OneFrameThreadLag=1

italomandara commented 1 month ago

Are you able to turn on the Metal hud and see if, besides the CPU spike, you get Gpu memory usage spikes as well?

Mfarshore commented 1 month ago

I tried using the Stats app when this first started and found that the GPU was in full use during the game, and especially when the glitches start. To confirm this morning I made a test version of working modification of CX with the metal HUD enabled. Spikes during the initial part of the game, but not during the glitches (1st image). But when the GPU memory goes above about 3GB (I have 8GB) is when the glitches start (2nd image). See the attached screen shots.

Considering that when the memory is cleared when the game is stopped I think the problem has something to do with the memory becoming overloaded and not GCed. I also looked at the process and child threads, and there are many. The GPU info might not be going to the correct thread. My background is in corporate and scientific programming, so my guesses might not be appropriate for game programming ;)

[Is there a reference for what is displayed in the metal HUD? Neat tool I think I will start using.]

start-Screenshot 2024-06-04 at 12 43 13 PM glitches-Screenshot 2024-06-04 at 12 39 35 PM
italomandara commented 4 weeks ago

I was thinking it was a memory leak causing the vector explosion, but it doesn't seem so. All i can see is a tiny increase in the cpu load while preparing the work for the GPU but that shouldn't cause the issue. at this point we could experiment with the FAFO technique: try runnig your app with this env var: MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS=1 also try MVK_CONFIG_FAST_MATH_ENABLED=0 can't guarantee anything just guessing at this point. the latest version of MoltenVK brings a lot of fixes but I'm still unable to build a version that is compatible with crossover's dxvk trying to work on it.

this is a doc for the MEtal hud: https://developer.apple.com/documentation/xcode/monitoring-your-metal-apps-graphics-performance#

Mfarshore commented 4 weeks ago

Yeah, I found that ref to the metal HUD. I also added the DXVK HUD to the test CXP version.

I assume that I add the env vars to the test CXP version CrossOver.conf file?

italomandara commented 4 weeks ago

you can run the game with env variables by right-clicking on the game icon in the crossover window and clicking "run with options" you can do that even with steam if you don't see the game icon.

Mfarshore commented 4 weeks ago

MVK_CONFIG_FAST_MATH_ENABLED=0 does not work at all. I tried that by mistake early on because another UE game did need that to eliminate foliage flicker. MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS=1 shows promise. Glitches took a while to show up, and then only when the GPU memory use went above 5.49GB. Usually glitches started at about 3.0GB so this might be a trail to follow. GPU memory seems to be the central issue here.

I see that 0.5.2-pre for Crossover 24 will introduce metal cache functionality, so that may help.

italomandara commented 4 weeks ago

I see that 0.5.2-pre for Crossover 24 will introduce metal cache functionality, so that may help.

the cache tools help locate and clear steam caches and d3dmetal caches, you could give it a try by cleaning steam caches.

Mfarshore commented 4 weeks ago

I don't run the game thru Steam. I run it directly to avoid any CPU overhead from Steam, sort of like running offline.

Since it runs acceptably I will just keep restarting when the glitches show up.

italomandara commented 4 weeks ago

I don't run the game thru Steam. I run it directly to avoid any CPU overhead from Steam, sort of like running offline.

Since it runs acceptably I will just keep restarting when the glitches show up.

Most of the time Steam runs in the background in headless mode so you might want to try anyway

Mfarshore commented 4 weeks ago

Well, gave that a try. Running the game from the Steam bottle produced instant glitches compared to the what I have been using to debug. Exactly the same game saved files, same HUDs active, etc.

I also tracked down all of the caches in the game bottle (only the one app in the bottle). None of the caches were larger than about 90K

Mfarshore commented 4 weeks ago

I found the quote below at https://www.reddit.com/r/macgaming/comments/142tomx/apples_game_porting_toolkit_seems_to_have_a/?rdt=35717 at the bottom of the discussion page. The render glitches only appear after a considerable amount of crafting that adds to the stuff that needs to be rendered. And the glitches suddenly appear when I turn the 1st person character's to a new perspective of the same scene. This suggests that there is a render complexity threshold above which the render compositor gets confused and/or the render pipeline becomes disordered. Interested in seeing your thoughts.

"... This means that if you take a VK PC engine and try to run it on apples GPUs it will either not run at all (as the HW does not have features it expects) or will run very very poorly. Apple GPU pipeline (the order that tasks run) is very different to AMD, NV and Intel. VK games written for PC are optimised for the pipeline ordering and contains of those GPU cards. Running them on apples GPU pipeline results in very poor perofmance as the GPU will need to stall, and wait doing almost nothing all the time so as to pretend to run like the PC gpus _**if it does not do this there will be lots and lots of visual glitches were shaders run in the wrong order.**_

Sure games could update thier VK engines to support the pipeline that apple use but this is infact a massive change and a LOT of work. Most devs would instead opt for poor perfomance and using a shim layer very very simpler to MoltenVK so that they can run the PC VK pipeline on an Apple GPU VK pipeline."

italomandara commented 4 weeks ago

Well, gave that a try. Running the game from the Steam bottle produced instant glitches compared to the what I have been using to debug. Exactly the same game saved files, same HUDs active, etc.

I also tracked down all of the caches in the game bottle (only the one app in the bottle). None of the caches were larger than about 90K

You're getting the glitches earlier because of the caches probably. also caches can be corrupted if for example you run the game with different versions of MoltenVK (because patched/unpatched or older version of CX)

In that case clearing caches would help.

Mfarshore commented 4 weeks ago

I would say let's put this on hold until there is a new version of MoltenVK and/or cxpatcher. You no doubt have other things to do, and I have basically finished the game doing the debugging. :)

The game runs fine if I save, quit, and restart it (without a restart of CX) which clears the GPU memory. So the only thing I can say for sure is that the problem is related to the amount of GPU memory being used. The MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS=1 option doubles the amount of GPU memory that can be used before any problems show up.