Timeline for How can I read texel data on a separate thread in D3D11?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 28, 2014 at 20:54 | comment | added | user41464 | Ah ok, no problem. | |
| Jan 28, 2014 at 19:47 | comment | added | user1430 | Comments aren't for extended discussion, that should be taken to Game Development Chat, but you lack the reputation for me to import the conversation there, so I am trying to do things to circumvent that (and it's not working); this discussion we are having is largely due in part to my misunderstanding you initially and really has no impact on my answer. | |
| Jan 28, 2014 at 19:36 | comment | added | user41464 | and there are comments being deleted left and right. I don't think that is particularly helpful. Even if I or anyone else post info that isn't 100 correct, just pointing it out in the discussion is enough to clear up any potential misunderstandings by other readers. I think in the end they probably would get a better grasp of the subject from the entire discussion. | |
| Jan 28, 2014 at 19:28 | comment | added | user41464 | Hi. My understanding is different. In d3d10, if I map a buffer, it is locked. In fact, unless I specify the singleThreaded flag in the d3d10.device constructor, then the device itself will be locked as well. It, and the buffer, will be unlocked when I Unmap the buffer. So there is no concurrent operation happening on any resource. I can call the methods from separate threads and everything will work out of the box. No, I'm not really editing and rendering the data at the same time. But I am using 2 threads to do two different tasks without having to deal with synchronizing them. | |
| Jan 28, 2014 at 19:07 | comment | added | user1430 | I think, if you're careful, you can do it with two semaphores and don't need to pepper locks all over. | |
| Jan 28, 2014 at 19:05 | comment | added | user1430 | Oh, I see what you are referring to now; yes, you could pass a flag to the device that would cause it to take internal locks to protect it's own state as far back as D3D9 (maybe earlier). But that doesn't cause it to support concurrent operations on the physical device like you are asking for: copying back resources from the GPU on CPU worker threads while the GPU is still potentially rendering (from a command buffer issued on the main thread). That's why Map can only do discardable/no-overwrite maps on the deferred context (and why the DO_NOT_WAIT flag exists). | |
| Jan 28, 2014 at 18:48 | comment | added | user41464 | Anyway, thanks for taking the time to post. It's just frustrating finding yourself having to resort to 'messier' code when upgrading APIs. It should be the other way around! | |
| Jan 28, 2014 at 18:21 | comment | added | user41464 | "As far as I am aware, D3D10 had no way to guarantee that behavior you are describing." Sorry, but you are wrong. D3D10 internally locks the device whenever one of its method is called. Thus, my original D3D10 code, was 100% full proof. Now, if I want the equivalent behaviour in D3D11 I need to manually add locks whenever I use D3D11's context. Yeah, this is going to be fun...... It's messy, and its something D3D11 could have kept from D3D10 as an option to be as a flag in the device constructor. | |
| Jan 28, 2014 at 17:18 | comment | added | user1430 | If you want clean separation of tasks, divorce them from D3D, which is synchronization point due to its API design and driver device access; for example, load your texture data off the disk without D3D and perform whatever post-map operations you want to do in a worker thread. When that is done, signal the main thread which creates a new texture with the until-now purely CPU-side data (or, in fact, just use the deferred context's Map and discard the whole existing buffer, splatting the new CPU-side memory into it). | |
| Jan 28, 2014 at 17:15 | comment | added | user1430 | As far as I am aware, D3D10 had no way to guarantee that behavior you are describing. It may have appeared to work but it was likely a ticking time bomb. D3D's "multithreaded" capability is basically supporting the recording of commands; not the execution. It does not (and has not) support "multithreaded rendering" or "multithreaded device access." | |
| Jan 28, 2014 at 17:13 | comment | added | user41464 | Uh, ok, but the texture mapping is part of the loading function. One state is drawing while another state loads. Clean separation of tasks in a multithreaded environment. Now I need to somehow add the mapping code from one state to a completely unrelated part of my code because... duh D3D11 broke the multithreading ability D3D10 already had? | |
| Jan 28, 2014 at 17:07 | history | answered | user1430 | CC BY-SA 3.0 |