Chris Smowton wrote:
Hello,
First of all my apologies if you're the wrong person to ask; I got your name by searching the wine-cvs list for who seemed to be doing most D3D10 work. If you're not the right person to ask the following questions, I'd appreciate if you'd advise who if anyone I'd be better off asking.
In general, wine-devel is the most appropriate place for questions like these.
Now then, I'd like to ask you about the current state of Wine's D3D10 support. I'm looking at how much effort will be required to gain D3D10 support for virtual machines, and Wine's D3D9 code has of course been used in a few virtualisation solutions. Here are my specific questions:
- Would I be right in assuming that D3D10 support is currently very
basic -- at the level of user apps being able to create a device and context, but not perform rendering as of yet?
Pretty much. We can do some rendering, but don't expect anything beyond very simple sample applications to work.
- What about shaders -- has the Wine project made much progress
supporting the new shader models?
We have some initial SM4 support. We can reuse a lot of the infrastructure for previous shader models, but the SM4 binary format isn't publicly documented anywhere, as far as I'm aware.
- Whilst of course Wine doesn't need to do this, have you gained any
insight into how the MS D3D10 usermode runtime interfaces with the DWM? I assume that simply replacing d3d10.dll on a Windows system with the hope of remoting rendering is not practicable because the runtime presumably creates the window's primary surface with a shared handle, and passes that handle on to the DWM to perform rendering. I see no reason why that internal D3D usermode runtime <--> window manager process interaction ought to be documented, and so a replacement for d3d10.dll on a real Windows system would seem like it would necessarily involve reverse engineering that process, but perhaps I'm wrong?
We didn't really look. I'd expect that to be done by dxgi rather than d3d10 or d3d10core though.
Henri