[3/4]

[Henri Verbeet]

2008/12/8 Stefan Dösinger <stefan at codeweavers.com>:
>> I would expect the relevant state to be dirty, but you say this
>> depends on where the function is called from?
> States are marked clean before the application function is called. This is needed to handle e.g. the relationship between the vertex declaration and the lighting enable state.
>
> What I mean is this:
> pixelshader(bla bla bla) {
>        /* I know I have to apply the pixelshader */
>        shader_backend->shader_select();
> }
>
> pixelshader(bla bla bla) {
>        /* I know I have to apply the vertex shader */
>        shader_backend->shader_select();
> }
>
> shader_whatever_select() {
>        /* What do I have to do? Apply pixel shader? Or the vertex shader? or both? */
> }
>
It would be up to the shader backend to determine what to apply. That
might imply storing the current vertex and fragment shader id's in the
context, but considering we also store those in the d3d vertex and
pixel shaders I think that's acceptable for now.

Does the patch have any other advantages besides making the fixed
function state handlers somewhat simpler though? I'm not sure if
introducing a dependency on the state tracker in the shader backend is
worth this. (I've got a better way to avoid redundant constant loads).

>> Well, you can hardly argue that eg. vertex shader enable is a proper
>> vertex state to begin with.
> The vertex shader enable doesn't have any say without the vertex declaration. And the vertex declaration has a similar effect on e.g. D3DRS_FOGVERTEXMODE. This state is treated differently in different shader model versions and different GL pipeline implementations on the fragment side. Is FOGVERTEXMODE a proper state or not?
>
Fog is not a pure vertex or fragment state, no (neither is the vertex
declaration, strictly speaking, since a large part of what it does is
about resource loading rather than how vertices are rendered).
state_fog() makes this obvious in a rather painful way.

> What I want to say is: We open a can of worms if we try to separate first class(programmable/ffp switch) states and second class states(ffp states) in the general state manager. This should really be left up to the actual pipeline implementation.
>
That it might not be trivial isn't really an argument against it.
Either way, this is pretty much a separate issue from the original
patch.