No subject

indistinguishable from real fixed function processing, other than that
in case of GLSL you have to link it together into a single program.

>  My concern is that if you split vertex processing and fragment processin=
g up,
>  you need a linker object that deals with linking. This linker object has=
 know
>  about the vertex and fragment processing state handlers and tables, thus
>  creating a special linker for each vs-ps-vff-ffp-other combination. I do=
n't
>  have any objections against that in principle, but I am afraid that due =
to
>  the high interconnection between vertex, fragment and other states we wo=
uld
>  end up with implementing most things in the linker.
>
It's a concern when mixing different shader backends, but I'm not sure
there's a lot we can do about it there. For fixed function
replacements it shouldn't matter though, because you always write to
the predefined fixed function outputs. In that case linking is only an
issue for GLSL FFP + GLSL shader, which is trivial to implement. I'd
prefer to keep this discussion focussed on fixed function
implementations though. GL3, D3D10 and splitting up the shader backend
are certainly interesting, but at this point it just distract from the
core issues.