WineD3D State management - going live(TM)

Stefan Dösinger stefandoesinger at
Mon Oct 23 05:01:19 CDT 2006

> One issue with shader constants is that in GLSL you set uniforms per
> program object, and it keeps the values last set, also when changing
> the currently used program. That means that in certain cases we might
> be setting constants to the same values as they were the last time we
> used the program.
Same issue to the sampler states and texture objects. I am afraid the fastest 
thing to deal with that is something like if(program->c[X] != 
stateblock->c[X]) { <set the gl constant; program->c[X] = stateblock->c[X]; }

One way is to keep a dirty list per shader program, but that would be an O(# 
programs), which is worse than the code above.

> Wrt sampler states <-> texture parameters: note that it's not unlikely
> for a texture to always be used with eg. the same filter settings,
> while the sampler states might change. It might be worth it to keep
> track of what sampler states a texture (ie, IWineD3DTextureImpl) was
> last used (ie, applied to the GL texture object) with.
Yup :-) The texture impl already stores the values, not sure what those are 
used for.

Lionel Ulmer voiced the idea of making comparisons a bit more efficient by 
e.g. putting some values in one DWORD. For example, the filter type needs 
only 3 bits essentially, which allows us to put MIN-, MAG- and MIPFILTER into 
one dword and just compare that. We can do that, or don't do it, but I don't 
think it will gain much.

All we can do is to manage as much states as possible with dirtification, and 
for the rest use verification before applying for the rest. And then we can 
make dirtification and verification as efficient as possible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the wine-devel mailing list