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

[Stefan Dösinger]

Alexandre didn't commit the patch, I think we should come to an agreement on 
this issue, otherwise it is going to come up again and again.

The requirements I have in mind are these:

1) The state table should be selectable based on the available opengl features 
and possibly registry settings. I think we all agree on that

2) We want a fixed function vertex and fragment pipeline replacement with ARB 
and GLSL

3) We want to be able to support pixel shaders with atifs and nvts. I don't 
know if that will ever be implemented, but if we choose a design that makes 
this hard or impossible that's not going to help

4) Even if we have an ARB/GLSL replacement, it should be possible to use D3D 
shaders but still use the opengl fixed function pipeline

5) A nice to have is to be able to use the replacement pipelines together with 
shaders, but that is not a hard requirement for me. We need an ARB and GLSL 
replacement anyway.

---

I understand Henri's suggestion this way: Don't put the state table into the 
shader backend(*), but select it separately. This way the ATIFS pipeline 
replacement doesn't have to be a shader model. That way we can choose the ARB 
shader backend and ATIFS state table on r200 cards, and use GLSL and ATIFS on 
newer cards.

That way we get full shader support and still the advantages of the pipeline 
replacement without using 3 inherited shader backends. Then the state table 
could have some backend to enable / disable ATIFS like in this patch. (The 
bottom line of the patch here is that we should enable the extension we 
*use*, and not what happens to be available).

The state table would report the fixed function caps it has, and the shader 
backend reports the programmable pipeline caps. GetDeviceCaps has to collect 
the caps from multiple places, but that isn't an issue IMO.

Is that correct, or did I missunderstand something?

However, I see two issues with that:

*) In which place do we decide which program/shader to use in the end? If we 
have an ARB fixed function replacement program and an ARB program generated 
from a D3D shader? Currently this happens to work because ARB/GLSL override 
NVTS and NVRC, but this fails if we have a shader and ffp implementation 
using the same extension

*) What do we do if a shader implementation wants to overwrite some states for 
its programmable pipeline work? For example take my GLSL clipplane patch: The 
ARB shader backend disables clipplanes when a shader is used. This example is 
about a driver bug, but there are others as well: ATIFS and NVTS with a pixel 
shader implementation will have to override a part of the sampler setting(the 
stuff that is currently done in activate_dimensions)

How would you deal with this?

Stefan

(*): Ivan and I agreed on a discussion on IRC that "shader backend" is not a 
good name. The shader backends today are more a pipeline implementation 
rather than a shader implemenation, and should be renamed accordingly. I did 
not rename them yet because I am not 100% happy with the name "pipeline" yet.