[3/4]

Henri Verbeet hverbeet at gmail.com
Mon Dec 8 05:51:26 CST 2008


2008/12/8 Stefan Dösinger <stefan at codeweavers.com>:
>> 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.


More information about the wine-devel mailing list