Turning D3D9 partial precision into SPIRV RelaxedPrecision is probably doable but anything beyond that (explicit fp16) would probably require writing an actual compiler rather than the simple instruction-by-instruction translator that DXVK has right now.
Yeah this is the kind of thing that probably needs a complete compile rewrite. I tried hacking RelaxedPrecision into DXBC at some point since the FSR2 shaders use that, but with all the bitcasts and loads/stores etc it didn't end up emitting any actual fp16 code in the driver either.
If you still had the hack laying around, I could take a stab at producing some perf numbers that might justify better-than-a-hack.
Doesn't look like I do actually, but that would only have been for Dx11 anyway where the only known use case is FSR2, which is optionally used in exactly one singular game that hasn't switched to dx12 in the meantime.
How common is the dx9 equivalent anyway? On the hardware side of things I think the only GPUs that ever really cared about it while Dx9 was relevant were Geforce FX cards, so I'd be somewhat surprised if this was actually widely used in the wild.
How common is the dx9 equivalent anyway? On the hardware side of things I think the only GPUs that ever really cared about it while Dx9 was relevant were Geforce FX cards, so I'd be somewhat surprised if this was actually widely used in the wild.
Well, we're looking at DX9 games being run on qualcomm hardware, which doesn't have the power of a typical desktop GPU, so we care about the feature now even if it had limited use back then. I've never worked in DXVK before, but could be interested in working on this if you could orient me a little to where I'd be working in the codebase.
Hopefully those geforce cards were common enough when the content was being produced that there aren't shaders with code that actually doesn't want partial precision! But we could driconf that away per-application easily enough.
To give a late update on this: We did end up rewriting our shader compiler and it does have support for partial precision (implemented as explicit FP16) now. Can be enabled via DXVK_CONFIG="d3d9.useFP16 = True".
The problem: We can't really enable it by default for now because too many games just slap it on every instruction and then don't render properly. Maybe we can revisit this in the future with some heuristics (e.g. to disable it on things like sqrt(dot(a, a)) or any expression that feeds into texture coords, which seem to be the two biggest problems), but it's a rather unfortunate situation.
D3D11 has FP16 support enabled by default everywhere and that works without issue, but almost no game actually uses it.
DXVK_CONFIG="d3d9.useFP16 = True"x1 2026-06
I'm looking at the performance of D3D9 applications on Qualcomm graphics (Turnip vk driver). I see that _pp opcodes shown in apitrace dump are not being translated to either RelaxedPrecision or fp16. That is likely a significant performance hit for us -- fp16 can do MADs at twice the rate, and takes up less register space allowing for more waves at the same time. I'm looking at a particular apitrace for example (Resident Evil 6 benchmark), and it has _pp opcodes, is rendering at ~4-20fps in apitrace replay, has many frag shaders with register pressure limiting max waves, and appears to be GPU bound despite apitrace overhead.
Using DXVK 2.6.2 on turnip from Mesa main today.