WineD3D: WineD3D: Use the shader backend to enable / disable atifs and nvts
chris.kcat at gmail.com
Fri Apr 11 13:41:57 CDT 2008
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).
More information about the wine-devel