On 12/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> 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.