2008/12/8 Stefan Dösinger <[EMAIL PROTECTED]>: >> 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. > Why not?
> It would also tie shader and shader constants, as well as different shader > types and constant types together in ARB. > That's an issue of course, but we should only reload dirty constants anyway. I've got some patches I could cleanup that do this. > 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 > I would argue that since shaders replace vertex and/or fragment states, we shouldn't have to go through the state management for replaced pipeline stages in the first place.
