Open SeongGino opened 4 months ago
To add some context, the offending section is somewhat into the game and unfortunately the game demo stops right before that part.
@Blisto91 has also determined that the "detached" hair is baked into the trace, as it can be observed even on Windows native while playing it back.
Since it appears to work fine on AMD post-upstreaming (see here), we would need to investigate with a copy of the game if this is perhaps a precision issue on Nvidia (I'm thinking floatEmulation and the like), or an outright bug.
in my case with 2.4 works ok seems a nvidia problem ?
@SeongGino If you have some time could you try a play-through of the problematic area with d3d9.floatEmulation = Strict
? If you drop that line in a dxvk.conf
file placed near the game's executable it's usually enough. You can verify in the logs that the option is properly parsed and applied; please make sure that is the case.
@SeongGino If you have some time could you try a play-through of the problematic area with
d3d9.floatEmulation = Strict
? If you drop that line in adxvk.conf
file placed near the game's executable it's usually enough. You can verify in the logs that the option is properly parsed and applied; please make sure that is the case.
Noting the d3d9 in that setting, does that apply to D3D8 too?
I'll investigate before the end of the night. Sounds like a very obscure bug to be vendor specific.
Noting the d3d9 in that setting, does that apply to D3D8 too?
Yes, it does. You can use any of the d3d9 config options with d3d8 as well.
Sounds like a very obscure bug to be vendor specific.
It wouldn't be the first time we've had one like this, if this is what it turns out to be.
Sorry about that, family related emergency.
Unfortunately, no change. Hair still brokey. :(
This is now with DXVK release 2.4
Unfortunately, no change. Hair still brokey. :(
Alright, thank you for ruling that out at least.
Thank you for the insight. If that is indeed the case, I'd be happy to just use d3d9.customVendorId = 1002
with the game, assuming that fixes the problem. Keep in mind this is a console port and most likely intended to run around 30 fps anyway.
I dont remember this subtitles glitch... that must be dxvk specific. But yeah in general, if app is messing something with a formats... then all of these glitches could be just false positive.
Right above, you can see a screenshot from @mrdeathjr28 where those subtitles appear to be fine? We'll try to procure the game and see if we can reproduce any of these things.
Keep in mind this is a console port and most likely intended to run around 30 fps anyway.
The Xbox port of House of the Dead III runs at 60 (which makes sense; HOTD3 in arcades is Chihiro hardware, i.e. a ram doubled Xbox anyways), as does the Wii port as part of HOTD 2&3 Returns. This game is absolutely natively 60fps, as are most light gun games.
Right above, you can see a screenshot from @mrdeathjr28 where those subtitles appear to be fine? We'll try to procure the game and see if we can reproduce any of these things.
That text glitch seems happens only there and last for a second or two....so screenshot could misslead you if you take it a bit before or afterwards. And i didnt checked else languages, so maybe glitch is english subtitles specific
For what it's worth, neither the glitch subject of this issue nor that subtitles glitch happens when playing the game with dgVoodoo2 and rendering through DXVK's DX9 path.
For what it's worth, neither the glitch subject of this issue nor that subtitles glitch happens when playing the game with dgVoodoo2 and rendering through DXVK's DX9 path.
DXVK's d3d8 is mapped to d3d9, much like d3d8to9 wrapper. As mapped to different path, then they have different bugs potentional. Here bug is either in d3d8 and/or d3d9.
dxvk d3d8 is not exactly d3d8to9 wrapper because have many things proper to dx8 compared d3d8to9 wrapper
back to error in my case works ok, i finish a gameplay video around 3 hours (2 rescues), have a glitch but different than posted @SeongGino and appear when you have finish game
Anyway, you can easy guess what app wants here, old style SYSTEMMEM buffers made NOT THE same as MANAGED and probably STAGING..
Not sure if any NINE parallels are worthwhile here, because we already do that as far as I can see.
DXVK's D3D9 still need buffers optimisations, for SWVPs too, that still run TAD SLOW... take a look at this trace https://drive.google.com/file/d/1V_JT0FAPUejBMTXPXzakSBJfoMETEAgd/view?usp=sharing if you wanna make SWVPs fast. Application asked full Software Vertex Processing
Maybe if you elaborate on the topic @K0bin can have a look. It's not very clear to me what kind of "buffer optimizations" you're asking for, since our SWVP path is somewhat common in terms of handling to the HWVP path.
I dont even think d3d9.customVendorId works for d3d8 apps... so there are more things TODO on d3d9 part to be more d3d8 friendly
That is a fair point, since I don't think we've plugged that bit into the d3d8 device. I can take a look and address it, thanks for the heads-up.
It can be literally be described as d3d8to9tovk 🤣
Well, I can tell you one thing: we don't disassemble any shaders, we only translate the shader definitions. But yes, we do plug into the d3d9 (dx)vk backend, never claimed otherwise.
DXVK's D3D9 still need buffers optimisations, for SWVPs too, that still run TAD SLOW
SWVP should run fine unless a game does exceptionally weird stuff. It's implemented the same as HWVP except that SWVP supports more vertex constants. To avoid copying 1024 Vec4s for every draw call, we only copy up to the highest constant that gets modified by the application on the CPU and rely on robustness2 to return 0 for out of bounds reads. This approach has generally worked and SWVP stopped being a problem once we landed that, so I'd be surprised if its still slow in this game.
As for the bug, it sounds like it comes down to undocumented locking behavior. Maybe writing data after calling Unlock()
or something like that.
I'll take a look at your trace for both things.
I don't know what you spot in 2.3.1 but the optimization I was talking about landed years ago.
https://github.com/doitsujin/dxvk/pull/2282
I guess that is because 1 to 4 component fog diff between D3D8 (could write to 1 component fog) and D3D9 (could write to 4).
Again, no idea what you're talking about. The D3D9 oFog
register in SM2_x only has 1 component. Same as in SM1_4.
About d3d9.customVendorId not functiong for d3d8 apps, that is third bug...
I've just checked with the d3d8-triangle test app, and it is being applied correctly, as determined by the d3d9 customVendorID logic. So are the rest of the fields (customDeviceId, customDeviceDesc). If you spot any particular points where a custom vendor ID isn't retrieved correctly, please open a bug with steps on how we can reproduce it.
Note that the dxvk HUD will not report these frontend values, since it takes them from Vulkan directly.
Well, latest shader d3d version have 4 fog components, not 1.
That's not the problem. All d3d8 shaders map onto SM1.x shaders, which already were supported by dxvk due to the fact d3d9 supports them. There may be some "devil is in the details" problems regarding definition translation, but that's beyond my knowledge to tackle.
It is this that triggered some SWVP perf i think https://github.com/doitsujin/dxvk/pull/3765
What does "triggered" mean here? Improved or worsened?
Well, latest shader d3d version have 4 fog components, not 1.
No, it does not. The latest shader model which has fixed function fog is SM2_x and as you can see here:
oFog only has 1 component.
Software information
The House of the Dead III (PC)
System information
Apitrace file(s)
hod3pc.5.trace.tar.xz
The first stage that the character appears, her hair detaches from her head - almost like it's frozen where it first appears in the shot. Examples for visual aid, both from Stage 2:
Edit: And though less noticeable, I believe some of the decals of the moss type enemies from Stage 1/Prologue slightly stick out unusually and persist beyond their deaths, similar to Lisa's hair.
NOTE: Though the apitrace is attached with WineD3D as instructed, some facial models are broken under it and I'm not sure if the resulting trace is reproduced perfectly: (subtitles glitch here happens on D8VK too) These issues aren't reproduced in dgvoodoo2-through-DXVK.
Note: this issue is re-posted from d8vk#193 (at the advice of @WinterSnowfall), but as can be seen from my last post on that thread at midnight today (1:38 AM @ July 9th, 2024), the issue is still present in the listed DXVK master version post-D8VK merge.