-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-27 00:15, schrieb Henri Verbeet:
- swapchain->swapchain_ops->swapchain_present(swapchain,
src_rect, dst_rect, dirty_region, flags); + wined3d_cs_emit_present(swapchain->device->cs, swapchain, src_rect, + dst_rect, dst_window_override, dirty_region, flags);
I think we should place comments like "This function is called through the command stream" for all functions that are called through the CS, similar to what we do for context activation.
Also note that swapchain_gl_present contains calls to wined3d_surface_blt and wined3d_device_clear that are going to cause problems with the multithreaded CS. I have patches to remove them, so feel free to ignore this problem for now.
On 27 September 2013 13:05, Stefan Dösinger stefandoesinger@gmail.com wrote:
I think we should place comments like "This function is called through the command stream" for all functions that are called through the CS, similar to what we do for context activation.
Perhaps, I'm not sure. For that kind of comment to be useful it should have a clear set of implications, and I'm not sure it has that until we work out the details of the multi-threaded implementation.
Also note that swapchain_gl_present contains calls to wined3d_surface_blt and wined3d_device_clear that are going to cause problems with the multithreaded CS. I have patches to remove them, so feel free to ignore this problem for now.
Sure, this is just getting the basic infrastructure in place. I'm ignoring e.g. the RECT pointers that aren't necessarily valid after the present call finishes as well, until the actual multi-threaded implementation comes along.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-27 14:19, schrieb Henri Verbeet:
Perhaps, I'm not sure. For that kind of comment to be useful it should have a clear set of implications, and I'm not sure it has that until we work out the details of the multi-threaded implementation.
Works for me.
Afaics the main implication will be that functions that are called through the CS shouldn't place any commands into the stream. Depending on the synchronization between writer and reader this may work, but waiting for the CS to finish inside the command stream will never work right.
On 27 September 2013 15:23, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-27 14:19, schrieb Henri Verbeet:
Perhaps, I'm not sure. For that kind of comment to be useful it should have a clear set of implications, and I'm not sure it has that until we work out the details of the multi-threaded implementation.
Works for me.
Afaics the main implication will be that functions that are called through the CS shouldn't place any commands into the stream. Depending on the synchronization between writer and reader this may work, but waiting for the CS to finish inside the command stream will never work right.
Yeah, the main things I can think of is that you shouldn't generally generate CS ops from inside the CS, and you can't access device state. I'm not sure in how far those are going to be issues that require this kind of annotation though. The only things that should access device state are going to be the various device getters and stateblock capture, but those should only ever have external callers. The main cases for generating CS ops from inside the CS are probably blits, and perhaps resource maps. The basic rule should probably be that anything that makes wined3d_cs_emit_*() calls should only have callers outside of wined3d, which shouldn't be too hard to verify.