On 23/10/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
How would I mark vertex shader constant #3653 dirty, and apply it using your mechanism ?
Uhh, shader constants, must have forgotten them :-( . Well, Henri and I silently agreed to leave them as they are right now. I think they have a simmilar issue as the sampler states. I have to check how and when to trigger an upload of the shader constants.
Right now, it sets the corresponding flag flag in the "set" structure of the stateblock to mark it dirty, and if it wasn't already it adds the constant's index to a list with dirty constants to apply. When it's time to apply constants we just iterate of the list. In that respect shader constants already work similar to how the new statemanagement would work.
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.
Ie, if the program never changed, we should remove shader constants from the dirty list after they are applied. If a program was used that was never used with this device/stateblock before we should set all the dirty constants again. But if a program was used that *was* used before, we would have to figure out what constants changed between now and the last time the program was used.
I'm not sure how much we would gain from fixing that though, depending on what a uniform is used for it might either change each frame or stay the same for a relatively long time.
Sampler states and bound textures are more difficult, as they are per-texture settings in gl and per device settings in d3d.
That doesn't sound entirely correct - there are per-texture-unit settings in GL, and per-sampler settings in d3d. I thought we had to map the samplers to GL texture units.
I mean things set with glTexParameter. The man page is not really clear on that, but I think the red book mentiones that texture parameters are per texture object, and not per stage. I'll check that again.
They are per texture object. You did say per device rather than per sampler in the d3d case though. We do have to map texture units to samplers, but that's for texture stages, when register combiners are used.
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.