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?
Vitaly asked me on irc why I use a linked list instead of an array or bitmap. Well, my original plan was indeed an array, but after discussing it with Henri I decided to got for a list. See http://www.winehq.org/pipermail/wine-devel/2006-October/051868.html and following posts.
The main arguments for a list were:
* The shader constant code uses it too. It keeps the code somewhat simmilar * memory usage. An array has a fixed sizeof(DWORD) * STATE_HIGHEST mem usage, while a list has sizeof(DWORD) + 2*sizeof(void *) * number of dirty states memory usage. well, that was the idea
In fact, the initial dirtification kills the memory usage argument. However, instead of dirtifying all the elements I could set the recording flag in the device on before initializing the initial stateblock and later apply the states instead of dirtifying them. When there are multiple contexts those can share the list of the free dirty markers.
The way dirtification is done and the rest of the code are independent from each other, so it can be changed easilly when we decide to do so. I prefer to get the state management running first, and then move the initial opengl setup to Init3D().
Stefan Dösinger stefan@codeweavers.com writes:
The main arguments for a list were:
- The shader constant code uses it too. It keeps the code somewhat simmilar
- memory usage. An array has a fixed sizeof(DWORD) * STATE_HIGHEST mem usage,
while a list has sizeof(DWORD) + 2*sizeof(void *) * number of dirty states memory usage. well, that was the idea
That list thing still looks very inefficient. If you don't want a full array (though I note you have one anyway in your code) you can use a growing DWORD array of dirty states id; then adding a state become simply something like dirtyStates[count++] = state.
Am Samstag 16 Dezember 2006 16:51 schrieben Sie:
Stefan Dösinger stefan@codeweavers.com writes:
The main arguments for a list were:
- The shader constant code uses it too. It keeps the code somewhat
simmilar * memory usage. An array has a fixed sizeof(DWORD) * STATE_HIGHEST mem usage, while a list has sizeof(DWORD) + 2*sizeof(void *) * number of dirty states memory usage. well, that was the idea
That list thing still looks very inefficient. If you don't want a full array (though I note you have one anyway in your code) you can use a growing DWORD array of dirty states id; then adding a state become simply something like dirtyStates[count++] = state.
That was my original idea, I think I'll go back to that :-)
-
Alexandre Julliard -
Stefan Dösinger