Direct3D 10 design considerations - wine-devel

18 Aug 2007


      Hi,
In the past days there was a bit of discussion about the implementation design 
of our future d3d10 implementation. The major question was wether we should 
make a clean start over with opengl 3.0, or extend wined3d for d3d10.
A few facts:
*) D3D10 is a clean restart without any backwards compatiblity, so is gl3. The 
fixed function pipeline was removed in both.
*) The D3D10 interface is a present. Many of the nasty things in d3d9 have 
gone. SRGB textures are a pixel format property now. Sampler states are a 
texture property, not a device setting. Offscreen-rendering is more fbo like.
*) WineD3D contains a huge set of functionality of d3d10 already. D3D10 is an 
evolutionary step, not a revolution. I estimate that 80% of the functionality 
that is of our interest already existed in d3d9. Code reuse, especially of 
the shader code and texture management, is desireable.
*) GL3 isn't out yet. When will we have a gl3 implementation on all platforms 
and drivers?
*) If we split, we do not have to take care for old opengl implementations and 
missing extensions. For d3d10 we could just require gl3, period. Of course 
that will only work satisfiably for the user if there are gl3 implementations 
everywhere.
So we have two ways:
1) Do the same Microsoft did, and do a fresh start. Some code, like the shader 
code, could be copied over and forked. This is propably the fastest way, but 
it leaves us with 2 different d3d implementation. The d3d10 implementation on 
the other hand would be free of old junk. It would make it hard to run d3d10 
on gl2+extensions, and even more harder to implement d3d9- on gl3.
2) Extend wined3d. We could use the inheritance scheme like in old ddraw, 
where the non-rendering functionality was implemented in a base object, and 
the renderer specific things(DGA / User / 3D) was implemented in objects 
derived from the base objects. This was a nice thing, but it made the code 
next to unreadable IMHO because of a huge number of objects and unintuitive 
interactions(DGA code calling User stuff, common code calling callbacks that 
are set in 5 places in the code, 5 different surface types).
WineD3D already has the attachment points for such an abstraction. We have COM 
vtables and state management callbacks. Implementing d3d10 properly in 
wined3d is most likely more work than a restart is, but it would allow us to 
reuse some code. What we would have to do is this:
*) Make sampler states work like in opengl. D3D7-9 takes care for updating the 
per texture states based on the device states. This will require some code to 
be moved from wined3d to d3d7-9 and duplicated in the 3 libs, most notable 
sampler state tracking in stateblocks.
*) Move the srgb flag -> format matching from wined3d to d3d9. Before this can 
be done, wined3d has to be changed from D3DFORMAT to DXGI_FORMAT style.
*) Clearly separate gl-specific code from non-gl-specific code in surface, 
texture, cubetexture, volumetexture, indexbuffer and vertexbuffer. Then split 
them in a base object and a derived gl2 object. Add a gl3 object implementing 
the gl-specific stuff in gl3. Make sure there is no gl specific 
buffer/texture stuff in the device(like CreateVBO &
*) Add a 2nd state table and callback functions for gl3. GL3 will have 
different state linkings. Most of the states can stay unimplemented unless we 
want to run d3d9 with gl3. D3D10 is much simpler here because the fixed 
function pipeline was removed.
*) Do something about the context manager. Multithreading has changed in 
d3d10, and it may change in gl3. Offscreen rendering in d3d10 can require 
fbos(no point in d3d10 offscreen rendering without them), this has much less 
hassles than the back buffer or pbuffer orm. Context management will most 
likely be much simpler in d3d10+gl3.
Andras tells me that he has the d3d10 stubs(no rendering yet) done now, and he 
is writing some tests currently, then he will send stubs and tests in.
Which way do you think should we go?