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

[Stefan Dösinger]

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.