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

[Stefan Dösinger]

-----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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWJ2GsAAoJEN0/YqbEcdMw6jMP/iwu8dhSlxAsKHWFQx6KoTfJ
10KENScmDTJ75xfhn8LXd6+Uxoq/9sHa4x1JoEpuK/vlSt/qseAXCFQSYNmj63EE
GIenCmhI/y4CdK7JKHv7+o3W1tcKGuK41VqBxe905rbzj7TFQP3d8xxT65qcbMlT
TiatvFoLgWa8+wjXcgKkRa0kzWozTieuri2fYlpXhScmoXqQxFjq+ao315ecS3FC
j/dDZHQSMh6IEJ9/TrC1XbhTd3Y1xykB377BORUbD6VBcjtqE60QOQzv5kdtDp0h
UhSzFkiL5d4Z0pJ3arW9wfFhflJaTCZbzS0w9f63kYq/KgO+SHCQDp4f8wRYNKZM
CCi3zhInUTOZ+FlrKejJwx8xp0lpjO2XRwDq+qJKOKuEADxxhlcvHGXpnQ0G4Mi+
+YhtTcMbnzllTAx1C4/PjKtQa5aQ5g20dJH0M2i51kKoY+08p48Ly3wFctQYGnUD
kkTH4EMCd7Lp4aaJxk74owIYXCidmtQkFZjVCiuldhZ+J+hDZNGhJeT8Vyi1V/CT
jEwefYkV0XZtK1KMb1faVEtp5OwPjymOyHFg4HR9xqLybH6JFuBPltJmKXA6eOvy
OKlD/R7gXcurMuzE86BB0ukTmkq0CSuC5Zo97Wf3Ep4FoA6bbKeXaMbyxUmgdRVH
i6CLZmj8TPP5/m5L+lbk
=+gvV
-----END PGP SIGNATURE-----