[PATCH 08/10] wined3d: make wined3d_device_update_surface operate with wined3d_texture and sub_resource_idx

Stefan Dösinger stefandoesinger at gmail.com
Wed Oct 21 04:58:04 CDT 2015

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

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.

Version: GnuPG v2


More information about the wine-devel mailing list