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