WineD3D: WineD3D: Use the shader backend to enable / disable atifs and nvts

H. Verbeet hverbeet at gmail.com
Fri Apr 11 22:07:49 CDT 2008


On 12/04/2008, Stefan Dösinger <stefan at 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.



More information about the wine-devel mailing list