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.
-
Stefan Dösinger