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

[Chris Robinson]

On Friday 11 April 2008 08:35:21 am Stefan Dösinger wrote:
> *) We may want to mix shader backends. GLSL is a pain on MacOS at least on
> the vertex side, but it works okish on the fragment shader side. It may be
> helpful to compile a ARB vertex shader and a GLSL pixel shader. Also an ARB
> replacement may be faster there because the GLSL compiler on MacOS often
> creates slow code.

As far as I can see, OSX's broken drivers are the only reason you'd not want 
to use GLSL when nothing else of better capability is available. For that 
case, there's two options: for nVidia users, extend ARB shaders with nv 
programs and use them (likely suprassing GLSL performance), and for other 
cards, bug Apple for proper drivers. IMHO, I don't think WineD3D should be 
that hindered and cause WineD3D issues with other vendors because Apple 
insists on making drivers themselves, and doing a poor job at it.

> *) We have an NVTS and ATIFS replacement now, but no ARB or GLSL fragment
> processing code, and it would be cool if we can make use of the ATIFS code
> on newer cards as well. NVTS currently works because it is included in the
> baseshader/fixed function backend.

Why would it be cool to use ATIFS on newer cards? It'd be cool if we had 
something lean, sleek, and working. Mixing output shader modes is just asking 
for problems, IMO.

> *) It's also about getting the design right in principle, and finding a
> design that doesn't need an entire rework when dx10 and geometry shaders
> are introduced.

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).