Direct3D 10 design considerations

Stefan Dösinger stefandoesinger at gmx.at
Sat Aug 18 15:50:42 CDT 2007


Am Samstag, 18. August 2007 19:59 schrieb Ivan Gyurdiev:
> The shader stuff uses two different backends and an intermediate
> interface (SHADER_OPCODE_ARG) to isolate the asm parser. Other parts of
> wined3d could do the same thing - you are interface constrained from the
> top (d3d) and from the bottom (gl), so it makes sense to focus on
> intermediate representations of the data. If it's hard to replace your
> GL backend, then the code isn't properly structured.
>
> ...and  splitting things up is being considered yet again.
> I'm not sure I like the idea of throwing away working code to start
> "fresh" - but I'm no longer writing d3d code, so :)
No question it is possible to keep things merged, but keep in mind that d3d10 
throws away some things that are a major thing the current d3d->gl wrapping 
code is dealing with, like having sampler states device global. The step from 
d3d9 -> d3d10 is much bigger interface wise than d3d7(*) -> d3d8 or d3d8 -> 
d3d9 have been, it is so big that Microsoft decided to throw away their 
internal implementation and start over. This is why we discuss this. If 
Microsoft hadn't entirely changed the way d3d works internally there wouldn't 
be any reason for us to do the same too.

D3D10 is a present. It is much closer to opengl than to d3d9. Having a common 
code means to deal with the overhead of mapping d3d9 to opengl in code that 
also runs d3d10. The question is how to deal with that overhead.

(*) d3d7->d3d8 was a huge change too because it got rid of the ddraw stuff in 
d3d. However, the differences are initialization-wise only, rendering once 
the device is there works the same way in d3d7. d3d10 has a 
different "run-time" interface.



More information about the wine-devel mailing list