stefan at codeweavers.com
Mon Dec 8 10:58:06 CST 2008
> 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
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
More information about the wine-devel