elishacloud/dxwrapper

Query on Direct3D driver files

Closed this issue · 4 comments

BEENNath58 commented

I was scouting through the Nvidia driver files and that's where I got a few doubts. My tests were conducted with Process Explorer. Since you have a fair experience with D3D9 I thought you could help with my doubt.

If I go through the files of the driver, then:

nvd3dum.dll and nvd3dumx.dll - NVIDIA WDDM D3D driver

nvwgf32um.dll and nvwgf32umx.dll - NVIDIA WDDM D3D10 driver.

  1. According to D3D9On12, forcing it should replace "some file" from the above with d3d9on12.dll. However I can't emulate this. On GTA VC, a d3d8 game, this causes both nvd3dum.dll (which was with vendor driver too) + nvwgf32um.dll to load together. Burnout Paradise, a D3D9 game, and Blood 2, a D3D6 game, replaces nvd3dum.dll with nvwgf32um.dll (Blood 2 has graphical issues, BP gets performance issues which should mean d3d9on12 is loaded but the loaded module is different)
  2. There's a nvd3d9wrap.dll in the driver folder. Interestingly, this file is present on a Nvidia drivers as old as since 2012. What does it do?
  3. Burnout Paradise interestingly loads d3d9.dll with Dx9ShaderValidation call when D3D9On12 is enabled. Why should it appear in Process Explorer if the same didn't with the native driver?
  4. I can't see any file being loaded when running a DirectDraw only app, like the DX DDRAW samples or games like MechWarrior 2
  5. What's the WDDM D3D11 and WDDM D3D12 drivers then?
  6. What's the nvlddmkm.sys file? Kernel driver?
  7. In old XP drivers, the only significant file I see is the nv4_disp.dll. How does it differ from the ones you see now (and as mentioned in my above points)
mirh commented
  1. d3d9on12 is a fully fledged d3d9 device driver (only, it spews out d3d12 calls as opposed to native gpu commands), and if any that is what it might substitute. I'm not sure if D3D12TranslationLayer should be supposed to handle even the whole presentation step, but even just an innocent nvapi query could be enough to load the vanilla system UMD. Unless you are claiming that this behavior only happens with dxwrapper I don't think there's anything to see here
  2. it's loaded by nvinit.dll in order for optimus to work, before microsoft added its official infrastructure in W8.1 (and it is present in the drivers installer if any, once actually installed it goes into the coprocmanager program files folder)
  3. you meant Direct3DShaderValidatorCreate9 perhaps?
  4. of course, what would you expect?
  5. as far as Windows is concerned, it's always the same nvldumd(x); with this said, the actual newer code is then split and implemented in nvwgf2um(x)
  6. yes, obviously? it's literally written in its description
  7. one had XDDM, now we have WDDM - it's kinda mindblowing to ask what's the difference when everything is different
BEENNath58 commented

Thank you for your valuable answers

  1. d3d9on12 is a fully fledged d3d9 device driver (only, it spews out d3d12 calls as opposed to native gpu commands), and if any that is what it might substitute. I'm not sure if D3D12TranslationLayer should be supposed to handle even the whole presentation step, but even just an innocent nvapi query could be enough to load the vanilla system UMD. Unless you are claiming that this behavior only happens with dxwrapper I don't think there's anything to see here

No this isn't just DxWrapper exclusive. I can't get the d3d9on12.dll driver to load anyways. It behaves as if a combination of multiple driver files loaded together simulate the D3D9On12 experience.

  1. of course, what would you expect?

Just like Direct3D loads device drivers like nvd3dum.dll, I expected something similar. Not that DirectDraw is all software accelerated now.

  1. one had XDDM, now we have WDDM - it's kinda mindblowing to ask what's the difference when everything is different

Now that I forgot what I was about to ask for this particular one here :P (well some other day I will remember this one)

elishacloud commented

No this isn't just DxWrapper exclusive. I can't get the d3d9on12.dll driver to load anyways. It behaves as if a combination of multiple driver files loaded together simulate the D3D9On12 experience.

dxwrapper does not attempt to load d3d9on12.dll. Instead it loads d3d9.dll and calls the Direct3DCreate9On12 or Direct3DCreate9On12Ex. See here.

Just like Direct3D loads device drivers like nvd3dum.dll, I expected something similar. Not that DirectDraw is all software accelerated now.

DirectDraw is 2D. There may not be any 2D equivalent dll to load on your computer.

elishacloud commented

Closing this issue. Reopen it if you still have a question.