[3/4]

Stefan Dösinger stefan at codeweavers.com
Mon Dec 8 04:48:26 CST 2008


> If you're going to introduce a dependency on state management in the
> shader backends anyway, you don't need to export constant loading
> functions from the shader backends at all. You might as well just call
> shader_select(), and let that figure out if it needs to change the
> shader or load any constants. That would also avoid this not-so-pretty
> code here.
I don't think that would work well. We would need some shader model specific private data in each context(e.g. last vertexshader and last vertexdeclaration) to allow the shader backend to find out what to do, since the dirty state information won't suffice if the shader backend doesn't know where it was called from. It would also tie shader and shader constants, as well as different shader types and constant types together in ARB.

There are however two follow-up ideas of this patch I am toying with:

1: Make the load_constant and shader_select prototypes the same, so GLSL can use one call for all and ARB remains flexible

2: Make the shader backend provide a pipeline template instead of shader_select and shader_load_constant. That would move shader selection out of the fixed function pipeline code and allow the shader to use the state management linking facilities for these sorts of dependencies





More information about the wine-devel mailing list