Henri Verbeet hverbeet at gmail.com
Tue Dec 9 03:36:37 CST 2008

2008/12/8 Stefan Dösinger <stefan at codeweavers.com>:
>> 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.
The patch essentially adds a version to the constants and throws them
in a queue. The disadvantage is that setting a constant becomes a bit
more expensive, and cache usage becomes a bit worse if you have to
load constants from deeper in the tree, but it still gives me about 10
extra fps in the CSS stress test.

I don't see how setting vertex and fragment shaders at the same time
hurts us that much, it just gives the shader backend a certain degree
of freedom. Please also keep issue 20 from ARB_geometry_shader4 in
mind. While it's possible to do crazy stuff like mixing
ARB_vertex_program with fragment shaders, you can't mix
ARB_vertex_program with a geometry shader. On the other hand, if you
really wanted to do that kind of mixing, you could just create two
backends and always pass FALSE for usePS to one backend, and always
pass FALSE for useVS to the other. It's not impossible, just ugly.
Splitting the shader backend doesn't change anything there.

>> 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 do have an opinion on how the shader backend should fit in with the
rest of the code. So far, I haven't heard anything that would make me
change that opinion.

More information about the wine-devel mailing list