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).
The double loading fix was the main intention
The other thing I intend with the patch is to move the GLSL shader<->constant dependency checks to the GLSL code where it belongs
The patch also starts to untie vertex and pixel shaders where we can(read ARB). I think it is wrong that we tie vertex and pixel shaders together in the shader backend interface because one implementation needs it.(On a hypothetical point, we need this for a nvts or atifs shader backend(*)). This might conflict with your intentions with the patch you mentioned above though, in that case we should not do that.
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.
Agreed, I can live with it. I however think that having this instead of the dirty state checks(which aren't completely nice either) moots the point.
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.
The thing is just that this topic comes back every other patch, and I feel like running in a cicrcle having the same arguments over that point again and again...
(*) I may need pixel shader support on my old laptop for personal reasons in a few weeks, so maybe I invest a rainy weekend of my time into it. Otoh just installing Windows may be an easier fix