About the Gallium Direct3D 10/11 work

[Luca Barbieri]

> 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.