Direct3D 10 design considerations
stefandoesinger at gmx.at
Sat Aug 18 05:26:20 CDT 2007
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
*) 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
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?
More information about the wine-devel