Re: [1] WineD3D: Add the state dirtification infrastructure

[Stefan Dösinger]

Am Montag 18 Dezember 2006 19:25 schrieb Stefan Dösinger:
Another issue I stumbled uppon: This patch moves the + 1 for the array 
declaration to the right place.
> Am Montag 18 Dezember 2006 14:06 schrieb Stefan Dösinger:
> Another update, it fixes an spotted by Henri issue where the state was used
> instead of the representative and uses shifting and bitmasks to calculate
> the index and shift for the bitmap.
> > This is another updated version, it uses bitmaps for the isStateDirty
> > member.
> >
> > Am Sonntag 17 Dezember 2006 14:45 schrieb Stefan Dösinger:
> > > Am Freitag 15 Dezember 2006 18:31 schrieb Stefan Dösinger:
> > > > This patch adds the dirty list infrastructure. A dirty marker
> > > > consists of a DWORD containing the state it marks dirty, and the list
> > > > structure to build the list.
> > > >
> > > > The wined3ddevice has 3 new members:
> > > > dirtyStateList: The list of dirty states. This will be moved to a
> > > > per-context stucture once we add multithreading support
> > > > freeListElems: A list containing unused dirty markers to avoid
> > > > unnecessary HeapAlloc/HeapFree calls. I have seen D3D games spending
> > > > 15% cpu time in the Heap code, we don't want to increase that.
> > > > dirtyStates: An array that tells if a state is dirty. It is used to
> > > > avoid double dirtification. I do not use the
> > > > stateblock->changed.XXXX[] array because this is used for different
> > > > purposes in the stateblock code. Ivan, do we still need it?
> > >
> > > Attached is an updated patch that uses an array for dirtification
> > > instead of a list. Actually there are 2 arrays, one to quickly find out
> > > if a specific state is dirty, and one to quickly find all dirty states.
> > >
> > > Checking if a state is dirty is done very often, so we need the
> > > isStateDirty. A linear search on the dirtyArray would take way too much
> > > time. On the other hand, my experiance so far shows that usually not
> > > more than 10-20 states are dirty at the beginning of a drawprim call,
> > > so iterating over all states would be a waste of time too. That's why
> > > the dirtyArray is there.
> > >
> > > In the end there will be around 1000 states, so the size of those
> > > arrays will be 8-10 kilobytes. Even oldest games load textures in the
> > > area of megabytes, with recent games it's about gigabytes, so I don't
> > > think those 10 kb's are an issue :-) . I could easilly change the
> > > DWORDs to shorts, but all d3d states are defined as DWORDs, so I
> > > decided to use DWORDS.
> > >
> > > If I used a bitmap I could squeeze the same information in about 128
> > > bytes + extra size for the code dealing with the bitmap + extra runtime
> > > needs for bit shifting and checking all DWORDs in the bitmap. D3D games
> > > are usually cpu limited, so I prefer the more memory intensive version.
> > >
> > > The other patches should apply cleanly over this patch, so I do not
> > > resend them.