Initial load/calculation time on D3D9 demo much slower than WineD3D
Hi there and thank you for the report.
Does running it with DXVK_CONFIG="d3d9.cachedDynamicBuffers = True" make a difference?
Hi there and thank you for the report. Does running it with
DXVK_CONFIG="d3d9.cachedDynamicBuffers = True"make a difference?
It appears that it does, reducing the time closer to that of WineD3D/Windows.
Can see in your log the exe is named UDS3.exe. Do you know if that is a generic name or unique to the game?
Just wondering why a game named Median have an exe called UDS3
Can see in your log the exe is named
UDS3.exe. Do you know if that is a generic name or unique to the game?
Just wondering why a game named Median have an exe called UDS3
It appears to be a shared, in-house engine used by multiple Ümlaüt productions. I haven't tested any other prods using their engine yet, but there should be some more listed under their Pouet group page.
Hi there and thank you for the report. Does running it with
DXVK_CONFIG="d3d9.cachedDynamicBuffers = True"make a difference?
d3d8/9 demos & benchmarking tools have been known to need it to perform adequately, at least in some scenes, so no surprise there. I would not add a built-in profile in such cases, unless it's known to affect actual games in some manner.
It appears to be a shared, in-house engine used by multiple Ümlaüt productions. I haven't tested any other prods using their engine yet, but there should be some more listed under their Pouet group page.
I tested a couple more of their prods using the same engine, namely Low and Along for the Ride; the former is slightly older and exhibits a similar issue, while the latter is seemingly unaffected.
(Feel free to close if there's no interest in pursing this further.)
@TheEssem Can you check if this build helps the issue in general without a config? https://github.com/doitsujin/dxvk/actions/runs/19936761733
@TheEssem Can you check if this build helps the issue in general without a config? https://github.com/doitsujin/dxvk/actions/runs/19936761733
It appears that it helps significantly with loading performance in both of the affected demos!
I did notice a rendering regression with Low between 1855e5e5209abdac3f5d33a1fc50981f6ae709f4 and the above CI build, however; the first object immediately after the intro (a ball shattered into many moving pieces) has a good chunk of its pieces missing.
Before:
After:
Given that the issue gets baked into trace files even when recording with a working DXVK version, this demo must be relying on some sort of undefined behaviour again because clearly we haven't seen enough of that yet.
That last commit in the PR fixes the demo with that cracking sphere. It apparently provides incorrect values for the offset and size parameters of the buffer lock function. Without the PR, we ignore those because the buffer ends up being directly mapped as it is D3DUSAGE_WRITEONLY. With the PR we no longer directly map it but that last commit changes it so we ignore the locking range for static D3DPOOL_DEFAULT buffers.
When starting the scene demo Median by Ümlaüt Design (https://www.pouet.net/prod.php?which=67384) with WineD3D, it takes around 3-5 seconds between the window opening and the progress bar starting to fade out. However, when starting the same demo with DXVK, it takes around 4 minutes and 20 seconds for loading to finish and the progress bar to start fading out. The load time on Windows itself also appears to be closer to the WineD3D time.
Software information
Uses Direct3D 9. Launched at 1280x720 (16:9) resolution with fullscreen off and multisampling enabled.
System information
Apitrace file(s)
https://downtown.wetdry.world/UDS3.trace
Log files
game.log