WineD3D State management - going live(TM)

H. Verbeet hverbeet at gmail.com
Mon Oct 23 03:27:14 CDT 2006


On 23/10/06, Stefan Dösinger <stefandoesinger at 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.



More information about the wine-devel mailing list