WineD3D State management - going live(TM)

[Stefan Dösinger]

Am Montag 23 Oktober 2006 00:57 schrieben Sie:

> What does addDirtyState() do when called multiple times with the same
> representative?
There is a stateblock->changed.<somestate> field in the stateblock, which is a 
boolean right now. This can be made a pointer to the list element, and set to 
the element when the state is first add to the dirty list, and set to NULL 
when the state is applied. When addDirtyState finds that a state already has 
a list entry it doesn't have to dirtyfy it again

> > This is still a bunch of code, not a magic instruction how to call gl
> > directly. To apply a state to gl
> >
> > States[State]->func(State, stateblock);
>
> 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.

> > I think you agree that the state grouping is a bit inflexible. For
> > example, the vertex declaration affects the fog settings. This way it
> > would be consequent to group them. However, as other things depend on the
> > vertex decl this will get a way to big group. The bigger the groups are
> > the more likely it is that one of the states is changed, so this will eat
> > performance.
>
> I think you're mixing dirtification of states with mapping which
> function applies those states, and I don't fully understand how this is
> going to work yet...
Well, what I wanted to say with this is that the representative grouping is 
not the last thing we have, and that we can implement more fine grained 
control in the code where needed.

> > 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.

>  > There is no point in putting  them into the main state list, instead
>
> there should be a dirty list per supported sampler.
>
> Again, it seems to me that two different concepts are being mixed
> together - I certainly don't want to be typing the function to apply per
> sampler, when there should be one entry in a table somewhere, with the
> sampler passed as an argument. Dirtification is another topic, which I
> don't think you can solve with a list anyway.
No worries, we don't need a seperate function for each sampler :-) The apply 
function gets a DWORD state value passed which it can use to find out to 
which sampler to apply things and where to read the values from.

Dirtification won't work properly for samplers, right. We will have to check 
the 13 sampler states when a different texture is used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20061023/021a51d6/attachment-0001.pgp