> 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




Reply via email to