[PATCH 2/5] d3d9/tests: Add a test for UpdateTexture.

[Matteo Bruni]

2015-03-11 13:41 GMT+01:00 Stefan Dösinger <stefandoesinger at gmail.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 2015-03-11 um 12:46 schrieb Matteo Bruni:
>> It seems to do the conversion IIRC. Notice though that that table
>> entry is commented out.
> - From my little UpdateTexture test on volumes in device.c I had the
> impression that UpdateTexture always just behaves like memcpy, that's
> why this is confusing me. Maybe my previous mental model of
> UpdateTexture / UpdateSurface was right and AMD just does some extra
> work. But maybe there is a way to make updates between different
> formats do something useful on all GPUs.

As far as I can see, there isn't any consistent pattern. That same
test on Nvidia draws black, so I think that specific UpdateTexture
call on Nvidia does not do anything in that case (but it still returns
S_OK, apparently UpdateTexture never fails with the release d3d9
runtime, it can fail with the debug runtime instead). The general
feeling is that the driver is allowed to do pretty much whatever it
wants with this call in those edge cases.

In the current version of the test I'm really only checking for the
result of what I figure are the useful cases, specifically updating to
a texture identical to the source but possibly without a few mip
levels at the start or the end. The first part is what is documented
in https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858%28v=vs.85%29.aspx
(although MSDN is otherwise incorrect, as usual), the second part is
what is used by Unigine Heaven 4.0 (bug 38048).

> There are some other interesting questions though: What happens when
> there are different formats with the same pixel size? E.g. ARGB16 ->
> ARGB16F, or signed / unsigned? Or maybe R32F to A8R8G8B8? When you
> copy from X8R8G8B8 to A8R8G8B8, does it just memcpy the X channel into
> the A channel, or set A = 0xff (or 0x00)?

I can test those, from the previous tests I expect that there isn't a
consistent behavior among drivers.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJVADgHAAoJEN0/YqbEcdMwfKAP/RpxFwP2cKi8vd1IfVVAPi1T
> 53qBWuaGKE2IgJ4Lzg+BFt060Y8hBg7B9azSDLyUeNwsIMtElxZ9D9zt6tplgGQ/
> /fWkX95g8DuoavzZOKQN3FXgj2l1f5ioVPaNMQnxRFQOQQv/EbJj72A05nY5cUKY
> IQRuJkjeBAzLm2Qc8Srw5nefaem/0Ezg4cofeSOR+6woZYS68g5hpBBUZrQfaUsl
> 2YN2QgyfumC4qpU3c4RMcqk4h9FNxHc4PM7njBp8dpLJe31+c5IWl/Kck2iALMpg
> iCHQlQJUNLVFFUpMSA7s01X2GniN8j+a+iRysHemp6pqpeYZpnmT5qJEzoKxjNsf
> PBh1LGXsWioy8RpTY+YGy5xjt0crtuA8VRbcw21i8Wx29dxEbI2TdbOd8tsv+dW7
> VsdZHKFuaaVwEAp5rNROdpvfNajEbohDIBD7ee7kUKQQ4FRgV/fmszpgxwwvCPU+
> nONHuYqDAYaDBCVB8cVsOuYhVmpyhggyov+dPpGIgZA7zcQzTZkd63mexbF+axvs
> +7w6s1oFsPEuI+iQSPoJuQvheV1RRdGKMPn6tGW30iX9/zonKL0WH7VTk2JKvpiS
> Y/qxYL+3KsbC5YUPpMpWjIjD5XuA4Ux0txhw5JcPxqefC7QmtWh8MMBOzKZpNK7A
> R4pIcprxQAkSJCHVva/F
> =wr1l
> -----END PGP SIGNATURE-----