search

AlpyneDreams / d8vk

Direct3D 8 to Vulkan translation for DXVK! Merged into dxvk: https://github.com/doitsujin/dxvk
zlib License
486 stars 6 forks source link

Revisit the managedBufferPlacement workaround #198

Closed WinterSnowfall closed 2 days ago

WinterSnowfall commented 6 months ago

I think we really need to look for a somewhat better option here or better tweak when we apply the workaround to decrease the number of game-specific configs we're using.

I've tried a couple of things which were specifically aimed at optimizing only caustics (fixed the Water D3D8 SDK sample app), but sadly that doesn't appear to be the entire story, as 3DMark2001 SE still regresses in performance.

Alternatively we could keep it, but maybe explore defaulting to it being off and enabling it only where we know it helps with performance and doesn't cause issues. At this point I believe this would in fact reflect as less game specific config entries, since it has caused more numerous performance regressions than we've initially anticipated.

So far, off the top of my head, I remember it dramatically improving performance or fixing issues in:

WinterSnowfall commented 6 months ago

Alright, I've managed to solve the big mystery. 3DMark2001 SE, in all its wisdom, switches paths during initialization. While it appears to be loading the dxvk.conf file from the same directory as its executable initially, it will in fact switch current paths to the "e2driver" folder and load it from there (or revert to defaults, not finding any overrides...).

This fun behavior blinded me to the fact that performance in the Car Chase - High detail benchmark is indeed improved both by d3d9.cachedDynamicBuffers = True, albeit to a lesser degree, and by d3d9.allowDirectBufferMapping = False, which has the same effect on performance as using MANAGED. This mirrors what I saw with the "Water" SDK app and makes a lot more sense now.

That being said, considering the numerous performance regressions we've seen as a result of resorting to this workaround, and it behaving essentially the same as d3d9.allowDirectBufferMapping, I believe it's better we drop it altogether and stick to d3d9's buffer mapping mode (see d3d9_common_buffer.cpp), patching up things on a case by case basis, when we see misbehaving apps. It is, after all, the most sane and maintainable approach and one dxvk's d3d9 space is no stranger to.

I'll PR something soon and probably do a long run of validations.

WinterSnowfall commented 6 months ago

I'll leave this up for future discussion/debate: what we can consider to generally improve these buffer readback situations is enabling cachedDynamicBuffers by default for d3d8, since we're rarely (if ever) GPU bound anyway.

I have a feeling native drivers sort of did something similar, but dynamically, by tracking actual buffer access patterns. So it would perhaps be even more beneficial to pursue this approach for d3d9 as well if feasible.