On 12/04/2008, Stefan Dösinger stefan@codeweavers.com wrote:
We have to face that driver bugs are reality. I think we are having more issues in form of user complaints due to the driver<->wined3d connection than the wined3d<->application one. I doubt Apple is going to fix their vertex shader bugs anytime soon. They come up weekly or monthly on their development lists, no official statement yet.
This is probably more of a concern to CW than Wine in general, but I guess it's a somewhat valid issue. The issue then becomes more one of how much ugliness we're willing to accept in the Wine tree in order to work around obviously broken drivers.
As it is, I imagine WineD3D will need to be reworked for D3D10 no matter what we do here. Unless someone has a working design plan for what changes are needed by D3D10 for WineD3D, we're ultimately just guessing about what may work best (not to mention it'll be using GL3 instead of the current stuff, so whatever's picked may not even be efficient API-wise for it).
I have a rough design plan
-> Replace the current d3d9 shader language with an intermediate language generated by the shader compiler and assembler library I am working on(see the other thread). d3d9 will feed a d3d9 shader into that lib and get a parsed shader back that it passes to wined3d, d3d10 works similarly.
I thought we decided on IRC that it would make more sense to call the shader library from wined3d rather than d3d8, d3d9 and d3d10.
-> Adding geometry shaders should work with the one-in-all shader backend. Add geometry shaders next to pixel and vertex and link all 3 together. I don't know the details with Henri's suggestion, but I think we'd just add an extra geometry state handler and extend the shader backend(or add a new shader backend if we split things up)
A geometry state handler would only make sense if you would want to add a "fixed function geometry processing replacement". Just supporting the shaders only requires adding them to the shader backend (split up or not).
-> OpenGL 3.0 needs the finalized GL 3 spec. If GLSL is unmodified(I think so), we can just reuse the existing GLSL shader backend. Otherwise we have to create a new one, and depending on how similar they are maintain it as a separate backend or overwrite a few parts via inheritance.
AFAIK GLSL will be mostly unchanged, although supposedly it will also allow things like bindable uniforms and binding separate programs for vertex/fragment/geometry stages. This would allow us to get rid of our main use of GLSL linking.
-> The non-shader parts of GL3 need a separation of the management code and GL specific code. For the state setters, we either need an entirely different set of state setters, or we can reuse a fully-GLSLed pipeline implementation. For textures, surfaces, buffers, devices we can move the management code into a base class and inherit a GL2 and GL3 class, similarly to BaseSurface-D3DSurface-GDISurface
I think going the GLSL way makes sense there. Anything supporting GL3 should fully support GLSL already, and I'm not even sure GL3 will support a traditional fixed function pipeline.