Am Freitag, 11. April 2008 20:41:57 schrieb Chris Robinson:
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.
I don't know who exactly writes the Apple drivers, but the Mac drivers have a few identical issues as the Linux ATI driver.
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.
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.
For one part it is helpful for testing, and it is a temporary solution until we have an ARB and GLSL pipeline replacement(post 1.0 most likely)
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.
-> Extending pixel shader and vertex shader support to 4.0 is fairly easy with whatever design we choose. Just extend the existing code.
-> 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)
-> 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.
-> 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
-> A major API rewrite in D3D10 is the new resource model. Basically we have to make IndexBuffers, VertexBuffers and Surfaces general "Buffers". IB and VB can be just replaced by the buffer d3d <= 9 wise, for surfaces we have to create a derived class where we add D3D <= 9 surface specific methods like Blt, the Container texture, Palettes, etc. Textures should be replaced with the more flexible ShaderResourceView objects. (I don't know if one buffer can be used in more than one resource view object. If yes than that might be an issue, as it means that a surface can be part of many textures e.g. as a mip level)
-> Vertex declarations? They are some shader resource view as well now, I have to look at them more in detail. Maybe we can just reuse them unmodified.
-> Pixel formats: We need tests to find out what the d3d10 formats need, but basically replace the WINED3DFORMAT enum with a d3d10-like one and add private values for d3d <= 9 formats missing in d3d10 like P8, X4R4G4B4. The DXGI_FORMATs are nicer than the D3D9 ones IMO.
-> One open issue: Where do we implement srgb reading switching? In WineD3D or D3D9?
There will surely be more open issues, this is just a rough plan.