If any one wishes to make any comments I'll include those as well as contacting Luca Barbieri (?) or who ever is relevant to this over at Gallium3D.
Here I am :)
As you have read, this is an initial (but working and with most of the code there) implementation of the D3D10/11 APIs. The plan is to ship all the core interfaces (ID3D10Device, ID3D11Device, ID3D11DeviceContext and supporting ones) in Mesa/Gallium, and make it available to native Linux applications.
In addition, some Wine dlls will be provided with just the minimal amount of code to hook the Gallium implementation to Wine's HWNDs. They could be shipped either as part of Mesa or as part of Wine.
The initial plan would be to ship them as part of Mesa, but if having anything else than Wine ship Wine DLLs is a problem, this could be revisited.
Wine would however need to provide all the non-core APIs, such as D3DX and effects, which I don't think anyone will implement for Gallium.
The HLSL compiler might come from the GLSL compiler, especially if the Intel team writing it were to decide to support Cg in addition to GLSL. Alternatively Wine could provide it.
In the meantime, Microsoft DLLs will be used for all these.
like the fact that it's C++
C++ dramatically increases productivity, especially when implementing COM interfaces, which in C require a lot of unnecessary boilerplate.
needs X11 windows,
The current implementation does, but it's very easy to port to anything else supported by Gallium (currently KMS consoles, fbdev and GDI).
and is limited to Mesa drivers,
It's limited to Gallium drivers.
If desired, this limitation can be circumvented by writing a Gallium driver that uses GL3/4 underneath. I think this could be the best way forward.
Even if Wine were to finish its own D3D10/11 implementation over OpenGL, Gallium would still have its own implementation, because going through OpenGL causes massive unnecessary overhead, reliability problems and difficulty of debugging.
Furthermore, this allows to provide Direct3D 10/11 features even if Mesa doesn't yet support the corresponding OpenGL features. In fact it's possible that Mesa will make available features like Direct3D 11 tessellation first in the d3d11 state tracker, and only later in the OpenGL state tracker.
from talking to Luca on IRC it sounds like this is just the "easy" parts like e.g. resource transfers, texture format conversion and basic draw calls
Not at all.
This is a full implementation of ID3D10Device, ID3D11Device, ID3D11DeviceContext and all the interfaces required by them, except for deferred contexts and things not yet supported by Gallium.
It should support almost everything in the D3D 9.3 feature level, some of the D3D10.0 feature level and almost nothing of the D3D11 feature level. This is mostly due to the current limitations of Gallium.
It includes a shader translator which supports all SM4 opcodes, although not all addressing modes and declarations are supported, and it has been tested quite little. Also some things like resinfo and switch/case/default/endswitch aren't yet implemented by most Gallium drivers.
It supports texturing with separate resource and samplers by putting every (resource, sampler) pair in a traditional "texture unit". This will change for DX10 hardware once Gallium gets support for distinct resources and samplers.
Of course, it's a very young implementation with almost no tests, so it will surely need a lot of small bug fixes to get fully working.
It's much more advanced than the Wine implementation, which apparently doesn't seem to even implement OMSetRenderTargets, which is obviously essential for rendering anything.
The *hard* parts are figuring out things like the shader and effect formats in a clean way.
Both are fully documented. Microsoft ships an header for the shaders and source code for Effects11 at least.
Shader parsing is already fully done.
The "hard part" is doing the Gallium hardware drivers, and making them competitive with the proprietary ones.
Implementing Direct3D 10/11 doesn't really have any truly hard part, just a lot of work, especially for the auxiliary parts like the HLSL compiler, D3DX and effects.
Luca took a bit of a shortcut there by not doing effects at all, and using the DDK for the shader format.
Yes, and that's seem a reasonable move.
Effects can be layered on top of the core API and thus are out of the scope of a Gallium state tracker.
That may or may not be ok, depending on what's actually in the DDK, but I'm not going to take that risk for no good reason.
As far as I can tell, there is no risk. The EULA doesn't even attempt to prevent alternative implementations and it's just an header file, not source code. As far as I can tell, the DDK license does not seem more restrictive than the Windows SDK one
To my knowledge the effect format isn't documented anywhere.)
As far as I know, Microsoft ships full source code for the Direct3D 11 effects implementation at least, and thus it is fully documented in that. Even if Wine developers don't want to just read the Microsoft source code, you can have someone read it and document it.
At any rate, reading source code and implementing based on the ideas learned is perfectly legal.
Note however that this has _not_ been done for the code in Gallium, especially because it only implements core APIs, and Microsoft (obviously) doesn't release source code for them at all. Even the C++ IUnknown implementation and COM smart pointer is _not_ based on the ones in ATL or MFC, which I haven't even examined.
Suffice it to say that I'm extremely unhappy with the way D3D development is currently going.
I think this is unjustified.
Getting a new, working, Direct3D 10 and 11 implementation seems to me quite a positive thing for Wine.
It would be great if we could get past this initial impression and have Mesa and Wine work together on this.
If you have any concerns, they can be addressed.