Re: [3/10] WineD3D: Move decoding the vertex declaration to the vertexshader state handler
Regarding the concern of storing the decoded strided data after finishing drawing: This is intentional, the decoded vertex declaration will remain valid after the draw is finished and the arrays loaded. Future draws can use it, if the state is not dirtified again.
This sounds like a good idea...
Wrt the upward references: When we have multithreading with multiple contexts we will need a per-context tracking of most of the stuff we have in the device now(last_was_rhw, ...). This structure does not exist yet, and I do not see a point in passing the device impl to every function when we can get it from the stateblock too.
I still think this caching stuff needs to go into its own structure [ maybe device->cache or something like that ]. I can see how it's a bit different from the standard stateblock data, since it's just a cache, rather than something that's set/get by the application - cache state vs configured state. It's not so clear to me that this is all per-thread data - the strided streams are directly tied to the vertex declaration and stream data, which is in turn shared across threads as part of the stateblock. =========== Note: you just made drawPrimitiveTraceDataLocations into dead code. (previously called in d3d8 fixed function code path). I don't care much for this function, but please remove it if getting rid of its callers.
Am 03.01.2007 um 14:07 schrieb Ivan Gyurdiev:
Regarding the concern of storing the decoded strided data after finishing drawing: This is intentional, the decoded vertex declaration will remain valid after the draw is finished and the arrays loaded. Future draws can use it, if the state is not dirtified again.
This sounds like a good idea...
Wrt the upward references: When we have multithreading with multiple contexts we will need a per-context tracking of most of the stuff we have in the device now(last_was_rhw, ...). This structure does not exist yet, and I do not see a point in passing the device impl to every function when we can get it from the stateblock too.
I still think this caching stuff needs to go into its own structure [ maybe device->cache or something like that ]. I can see how it's a bit different from the standard stateblock data, since it's just a cache, rather than something that's set/get by the application - cache state vs configured state. It's not so clear to me that this is all per-thread data - the strided streams are directly tied to the vertex declaration and stream data, which is in turn shared across threads as part of the stateblock.
The strided streams can contain opengl vbo names. They are per gl context, but I think they are shared with display list sharing (Otherwise we'll get an issue with them with multithreading). A seperate structure in the device sounds like a good idea. I'd prefer to keep them were they are until the state management move is finished though. Change one thing after the other :-)
This particular commit breaks Galactic Civilizations 2 Dark Avatar. Would a trace be helpful? 438c17284138776edbbe9196364ae620bbf01adb is first bad commit commit 438c17284138776edbbe9196364ae620bbf01adb Author: Stefan Dösinger <stefandoesinger(a)gmx.at> Date: Tue Jan 2 21:31:08 2007 +0100 wined3d: Move decoding the vertex declaration to the vertexshader state handler.
Am 04.01.2007 um 04:12 schrieb * *:
This particular commit breaks Galactic Civilizations 2 Dark Avatar. Would a trace be helpful?
438c17284138776edbbe9196364ae620bbf01adb is first bad commit commit 438c17284138776edbbe9196364ae620bbf01adb Author: Stefan Dösinger <stefandoesinger(a)gmx.at> Date: Tue Jan 2 21:31:08 2007 +0100
wined3d: Move decoding the vertex declaration to the vertexshader state handler. Can you test if patch 7/8 I sent yesterday fixes it? "WineD3D: Dirtify the stream sources in DrawPrimitiveUP"
participants (3)
-
* * -
Ivan Gyurdiev -
Stefan Dösinger