Direct3D 10 design considerations

Ivan Gyurdiev ivg231 at gmail.com
Sat Aug 18 12:59:13 CDT 2007


H. Verbeet wrote:
> On 18/08/07, Roderick Colenbrander <thunderbird2k at gmx.net> wrote:
>   
>> From what I have seen GL3 is very different. It would be like maintaining a
>> GTK and a QT backend in one library. They use very different calls
>> (glBegin/glEnable and so are gone), need different WGL contexts and so on.
>>
>> Sure in case of a wined3d-gl3 you'll end up fixing bugs twice. But for quite a
>> number of bugs you'll need to patch both gl2 and gl3 anyway.
>>
>>     
> That's true, but there's also a rather large part of wined3d that's
> not GL specific in the first place. The most obvious examples are most
> of the shader stuff and state management, but that's certainly not
> all.
>   
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.

It's interesting that all this work was done to move towards convergence:
D3D1-9 -> Wined3d
Pixelshaders, Vertexshader -> shared backend
GLSL, ARB -> single shader parser

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






More information about the wine-devel mailing list