March 11, 2015
8:52 a.m.
2015-03-11 13:41 GMT+01:00 Stefan Dösinger <stefandoesinger(a)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-----