-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2015-10-21 um 11:38 schrieb Henri Verbeet:
Oh right, you meant csmt for both cases. I guess the "or" was a bit ambiguous. It's something csmt will have to deal with either way though, since d3d10+ uses that.
The current solution in my patches is to wait until the upload is done. That makes the tests happy, but obviously isn't an efficient solution.
My suggestion would be to map the d3d10+ call to the d3d9-style call with a sysmem staging resource managed by d3d11, similarly to how we handle UP draws in <= d3d9. But I haven't looked into the details at all.
(On a semi-related topic, OpenGL doesn't know that that the sysmem pointer isn't going away and needs to make a copy even if we have a sysmem d3d resource. The idea here is to use a buffer with client storage (ARB_buffer_storage) to tell GL that it doesn't have to bother copying but still having a stable map address).
Of course you can't necessarily know a system memory surface isn't going to be modified before the upload finishes in such a case either, but I suppose you could block on maps in that case.
Yeah, right now I handle that in the same way as I handle buffers, textures and render targets in regular draws. I know two applications that ran into performance problems with update_surface or update_texture. One of them is World of Warcraft, and it passes D3DLOCK_DISCARD when it maps the sysmem surface. Implementing discards for sysmem resources fixed the issue.
The other one is Call of Duty Modern Warfare, and it doesn't use D3DLOCK_DISCARD. It is updating a pretty small volume. I suspect it is using it as a way to throttle the render-ahead behaviour, but I have no proof of that.
Note that I don't think it's a given that resource updates should always happen on the rendering thread though.
Yeah, but that doesn't help here. E.g. the destination resource could be busy, in which case an update in the main thread can't be done right away either. And no, we can't discard single sub resources.