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