> 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
