WineD3D State management - going live(TM)

[Stefan Dösinger]

Am Montag 23 Oktober 2006 08:43 schrieben Sie:
> Stefan Dösinger wrote:
> > 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
>
> Ok, but that sounds rather messy...
Well, we don't need a pointer to the list element, a BOOL changed will still 
do the job. All we need then is a "if(renderstate[representative].changed) 
return;"
>
> I don't like how the number of things staying "as they are right now" is
> growing, while the number of things being changed remains confined to
> render states. To have a proof-of-concept state management system, it
> would be best to take things that are as different as possible, and
> manage to get them successfully updated via the new state manager.
> Otherwise you won't find out whether the design is flawed or not until
> much later.
Agreed, in theory. But I also think that we shouldn't try to put different 
things in one model by force. If some things work differently, why shouldn't 
we handle them seperately?

Shader constants are different from fixed function things in two ways: There 
is a dynamic number of them, and there are no dependencies between 2 shader 
constants. So there is no use for a table like the fixed function elements, 
which on the other hand does not mean that a table and dirty list is 
pointless for render states and other fixed function things.

That I said "leave them as they are" was because Henri claimed that constant 
management is done properly already. I don't know the code, and if it needs 
improvement I don't say we can't change it :-) . But if there are different 
needs than fixed function states we don't have to use the same data 
structure / code either :-)

> Yes, but it sounds like you need an entry for this function into the map
> for each sampler...
> map { SAMPLER(0) -> sampler_apply_function }
> map { SAMPLER(1) -> sampler_apply_function }
> map { SAMPLER(2) ...
>
> ...and that seems wrong, but maybe I'm misunderstanding.
Nah, I wouldn't create a table with own entries for up to 
MAX_SAMPLERS*HIGHEST_SAMPLER_STATE sampler states :-) So for samplers I could 
create one table containing the 13 sampler states for grouping them, but as 
dirtifying won't work well for samplers there is not much use for that. The 
idea would be to group e.g. MINFILTER and MIPFILTER, and keep a dirty list 
per supported sampler. But a SetSamplerState without a SetTexture on the same 
sampler is rather rare I think, so the gain would be limited. The 'global' 
dirty list however can contain a flag that one or more samplers are dirty. 
The handler for this dirty flag can contain code to check which sampler 
states have to be reapplied.
-------------- 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/076522e9/attachment.pgp