Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A.I.M.: Artificial Intelligence Machines - world map is heavy on performance #76

Open
ghost opened this issue Dec 23, 2022 · 23 comments
Open
Labels
enhancement New feature or request working! This game works, but may still need attention.

Comments

@ghost
Copy link

ghost commented Dec 23, 2022

Frame rate drops significantly when viewing world map.

For comparison, both WineD3D and d3d8to9 + DXVK have similar results. FPS drops also on MS Windows with D8VK in combination with AMD proprietary drivers. However, on Windows without D8VK there's virtually no FPS loss at all.

d3d8-map-fps2.mp4

Software information

A.I.M.: Artificial Intelligence Machines, versions 1.00 to 1.06

System information

  • GPU: AMD Radeon RX 5700 XT
  • Driver: Mesa RADV 22.3.1
  • Wine version: 7.22 Staging
  • DXVK version: a50de46

Apitrace file(s)

Log files

@AlpyneDreams
Copy link
Owner

Not sure the immediate cause of this issue as the framerate drops even when CopyRects is disabled. It is probably due to the many queue syncs caused by calling LockRect a whole bunch. Not sure if this can easily be fixed without refactoring d3d9 a bunch.

@AlpyneDreams AlpyneDreams added enhancement New feature or request game labels Jan 3, 2023
@AlpyneDreams
Copy link
Owner

@Kritzmensch can you confirm that the issue doesn't occur if the game is run on Windows with Microsoft D3D8? Or is it just apitrace where it's fast?

@ghost
Copy link
Author

ghost commented Jan 5, 2023

@Kritzmensch can you confirm that the issue doesn't occur if the game is run on Windows with Microsoft D3D8?

It does occur, but it's not nearly as taxing as with anything else, including D8VK, that I've tested so far. Although the drop isn't visible (at least on 1080p and lower) without uncapping and monitoring FPS, the overhead is still rather high on pure Windows, too (~45 frames on my setup; though perhaps that's the way the game works and it's the best result that can be hoped in the end).
Also, something I failed to mention at the top is that this Windows' d3d8 implementation is broken in some parts.

AIM.v1.06.Windows.AMD.d3d8.mp4

@AlpyneDreams AlpyneDreams added the working! This game works, but may still need attention. label Feb 1, 2023
@AlpyneDreams AlpyneDreams removed the game label Feb 23, 2023
@WinterSnowfall
Copy link

@Kritzmensch Can you please retest with latest main? There have been some changes done to buffer allocation which might have fixed these performance issues.

@GranMinigun
Copy link

Just built the latest commit, the game slows down to a crawl on the map screen. Intel Core i5-7400, Intel HD Graphics 630, Mesa 23.0.2. The game is patched to version 1.04 + 1.06 No-CD.

Menus in general significantly tank performance, and the game seems to constantly hitch when you're on the move, even in the areas that you've been before. It's... not exactly a technological masterpiece. (Although the map didn't tank performance that hard, even on a much weaker Windows configuration.)

@WinterSnowfall
Copy link

@GranMinigun Thank you for retesting.

Just built the latest commit, the game slows down to a crawl on the map screen.

Does setting d3d9.apitraceMode = True help at all?

@GranMinigun
Copy link

Doesn't seem to, no.

@ghost
Copy link
Author

ghost commented Apr 19, 2023

@WinterSnowfall Unfortunately I have to confirm @GranMinigun's earlier findings. There's no FPS increase.

@WinterSnowfall
Copy link

No worries and thanks again for retesting. We'll keep this on the burner then and hopefully sort it at a later date.

@GranMinigun
Copy link

I'm not familiar with either D3D or Vulkan, but some observations, just in case: The number of queue syncs always stays at zero, but the numbers of queue submissions, barriers, and CS chunks considerably increase in menus, and jump drastically at the map screen, skyrocketing frametimes up to 300+ ms on my machine. The game also performs a lot of render passes (around 150, double that on map), but with a relatively digestible number of draw calls (usually less than 1200, much less in menus). Numbers fluctuate a bit. D8VK built from commit 4a7c627.

In-game Menu Map
Queue submissions 7 22 232
Barriers 271 326 1339
CS chunks 15 24 231

@ghost
Copy link
Author

ghost commented Sep 20, 2023

Not related to this specific issue but I've noticed a significant drop in average FPS over last few months with D8VK when compared to d3d8to9+DXVK combination.

There are many areas in the first game where FPS will always drastically drop for me, all seemingly where there is a lot of foliage around (and particle effects in case of Clan Wars). One of the worst locations is a southern shore of the lake near raw materials base in Tundra Sector. Start from somewhere in the middle of the northern part of the lake and start moving southwards without deviating from the course (coords: x13670 y8100, marked with the red circle on map). You should experience a steady decline in frame rate while approaching.

@GranMinigun can you check if same happens on you setup too?

L2_fps_drop_area

Observations I've made:

D8VK d3d8to9+DXVK
FPS in problematic 'hotspots' ~70..110 130..190
FPS normally ~210 250..300

@GranMinigun
Copy link

GranMinigun commented Sep 20, 2023

My iGPU suffers greatly from alpha-blending overdraw in general, and it's not unique to this game or DXVK. There's a field of dry grass west of Climate Activator in the Hills Sector, which seems to hit even harder.

In other news, the map screen doesn't tank performance into single digits on my setup any more (still slows down).

@ghost
Copy link
Author

ghost commented Sep 24, 2023

Did you try to compare D8VK against d3d8to9+DXVK, was there any noticeable perf. diff. on your setup as well? If I remember correctly the gap used to be much narrower at the start of the year in my case.

alpha-blending overdraw

I guess that might explain why particles also decrease FPS so drastically.

There's a field of dry grass west of Climate Activator in the Hills Sector, which seems to hit even harder.

There are many areas in the first game where FPS will always drastically drop for me, all seemingly where there is a lot of foliage around

I removed foliage models from all terrain materials and it indeed is the cause for the abysmal frame rate. Game runs unbelievably smoothly without them.
Based on the two answers to basically a same issue on upstream (doitsujin#1012 (comment), doitsujin#1012 (comment)) I take that there's no point in opening a new separate issue since the current behaviour is expected and there's unfortunately nothing to do about it.

In other news, the map screen doesn't tank performance into single digits on my setup any more (still slows down).

Funnily enough, for me it's the other way around. It's not single-digit of course, but the frame rate has degraded by some 50 frames in map view (from around 100 FPS, or a bit less, at 1080p seen in the video above).

@GranMinigun
Copy link

GranMinigun commented Sep 24, 2023

Did you try to compare D8VK against d3d8to9+DXVK, was there any noticeable perf. diff. on your setup as well?

d3d8to9 with the current DXVK release crashes on first attempt to render water, then doesn't draw it at all in subsequent launches. But yes, I too observe that performance difference, although much less extreme likely due to weaker hardware.

nothing to do about it

Reverse the game, rewrite the renderer. I don't think the developers would mind that. ;)

Or, as an option, see if there's a way to replace alpha blending with masked alpha.

@ghost
Copy link
Author

ghost commented Sep 24, 2023

d3d8to9 with the current DXVK release crashes on first attempt to render water, then doesn't draw it at all in subsequent launches. But yes, I too observe that performance difference, although much less extreme likely due to weaker hardware.

Thank you for testing! d3dx9_43.dll from Wine Project seems to not be 100% compatible with it. If you have A.I.M. 2: Clan Wars or A.I.M.: Racing bought on Steam, look into their _CommonRedist/DirectX/Jun2010 directory. If you haven't, Microsoft probably still directly hosts it on their website. I think disc releases were also shipped with their own copies of DirectX installers but those are probably way older and don't include d3d9.

Reverse the game, rewrite the renderer.

Honestly, no kidding, that is something I might just look into at some point in the future, even if it takes 10 or more years to get on par with the original binaries (considering how long, or fast, it approx. took to RE original binaries of RenderWare engine, 3D GTAs and Morrowind and then rewrite them as librw and re3, and OpenMW). The interest is certainly there.

I don't think the developers would mind that.

Spline, the lead dev, does indeed seem chill on that regard. He's even given some small hints/clarifications about the code and inner workings of the engine. The current IP owners, however, would probably have something to say about that unless the clean way is used. But that's a topic for another time to avoid going too off-topic of the opened issue.

Or, as an option, see if there's a way to replace alpha blending with masked alpha.

Possibly. I know M2 has [non-specular] uses for masks in some places, maybe M1 as well with correct configuration. There's also the way of disabling transparency selectively for commonly occurring spammy textures, including particle effects, entirely in the game's database. It would, of course, have a downside of looking ugly but it would still be a viable way to have higher FPS with foliage for those who're seeking it.
I still find it curious that d3d8to9 is so much more performant in case of alpha-blending.

@WinterSnowfall
Copy link

I still find it curious that d3d8to9 is so much more performant in case of alpha-blending.

It's most likely not. If I had to guess it might be the game is one of the few impacted by our D3DPOOL_MANAGED workaround. At some point I think we'll devise a better system to handle games that read from WRITE_ONLY buffers, but for now it's the best compromise we could come up with and unfortunately other games (which ironically behave properly) are expected to take a hit on performance. Try running it with d3d8.managedBufferPlacement = false and see how it goes.

@GranMinigun
Copy link

Getting better performance with that setting. If the game misbehaves, would it crash or just show graphical artefacts? Not seeing anything weird in a brief flythrough.

d3dx9_43.dll from Wine Project seems to not be 100% compatible with it.

winetricks d3dx9_43 it is then. Thanks, will keep that in mind.

current IP owners

I thought Dust, one of the original devs, bought out the rights from 1C? But sure, if you don't want to derail the ticket even further.

@WinterSnowfall
Copy link

WinterSnowfall commented Sep 25, 2023

Getting better performance with that setting. If the game misbehaves, would it crash or just show graphical artefacts? Not seeing anything weird in a brief flythrough.

The game won't misbehave with this setting, because we're doing what it asks of us in the first place (with it set to false).

The underlying problem is that apparently a lot of d3d8 games read back from DEFAULT resources on the CPU, which tanks performance severely when it happens - these situations are what we're currently mitigating with MANAGED buffer placement. But having an extra local copy around can cause performance regressions with other well behaved games, which seems to be the case here as well.

Since the number of games that have been observed to be negatively affected keeps growing, I'll raise an issue to track this problem and hopefully come up with a better solution once d8vk is merged upstream. Feel free to use the above config option for now.

@ghost
Copy link
Author

ghost commented Sep 30, 2023

It's most likely not. Try running it with d3d8.managedBufferPlacement = false and see how it goes.

You're right. Frame rate is of course sometimes higher, sometimes lower, between different sessions making it more difficult to compare the two but it seems to be on par with D8VK+d3d8to9 when this setting is disabled.

winetricks d3dx9_43 it is then. Thanks, will keep that in mind.

Since you're using winetricks [I assume it cherry-picks specified dll without pulling in others from the SDK] you'll also have to add d3dcompiler_43.

I thought Dust, one of the original devs, bought out the rights from 1C? But sure, if you don't want to derail the ticket even further.

I don't remember the whole story behind it, I'll have to recheck, but I remember he got the right/license to use A.I.M./Механоиды name again and [some?] assets. I doubt he actually owns them again. The original trilogy (A.I.M., A.I.M. 2: Clan Wars and A.I.M.: Racing) are, however, still property of 1C.
We can continue the discussion on the community Discord group, or in PMs, if you wish.

[...] all seemingly where there is a lot of foliage around (and particle effects in case of Clan Wars).

Scratch the last part. Frame rate doesn't drop half of the times when a lot of spammy particles are spawned at once. And when it does drop it doesn't seem to be affected by whether I'm using d3d8to9+DXVK or d3d8.managedBufferPlacement = false with D8VK.

@WinterSnowfall
Copy link

And when it does drop it doesn't seem to be affected by whether I'm using d3d8to9+DXVK or d3d8.managedBufferPlacement = false with D8VK.

Apart from what Alpyne mentioned at the start (the game abusing LockRect), it could be spamming a lot of ProcessVertices calls at times, which is also known to pose a performance problem with d8vk/dxvk. Unfortunately, there's no way to address that at the moment and as luck would have it older games are more likely to exhibit this behavior, since on hardware at the time it wasn't all that expensive (and done on the CPU).

@WinterSnowfall
Copy link

@GranMinigun I see the person who opened this issue is gone, but can you perhaps retest this on dxvk 2.4 and let us know if it's still a problem?

If so, please also try setting d3d9.allowDirectBufferMapping = False and should game performance be better than way, we can consider making it a builtin default.

@GranMinigun
Copy link

Same hardware as before, Linux 6.nice.8, Mesa 24.1.3, freshly built DXVK 2.4.

The map screen used to plummet framerate into a single digit a long time ago, but at some point that improved - 20~30 FPS, not sure whether that's DXVK or Mesa improvements, or something else.

d3d9.allowDirectBufferMapping doesn't seem to affect performance.

DXVK HUD suggests that queue and CS syncs take a lot of time, and this is the only place where I see these values being non-zero, if that helps.

@WinterSnowfall
Copy link

DXVK HUD suggests that queue and CS syncs take a lot of time, and this is the only place where I see these values being non-zero, if that helps.

Setting d3d9.allowDirectBufferMapping to False could've potentially helped with queue syncs, but alas. Thanks for retesting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request working! This game works, but may still need attention.
Projects
None yet
Development

No branches or pull requests

3 participants