-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-10 um 19:29 schrieb Matteo Bruni:
/* This works on AMD but fails on Nvidia (it draws black).*/ + /* {8, 8, 8, 8, 4, 4, D3DFMT_A8R8G8B8, D3DFMT_R5G6B5}, */ /* Different format */
What does AMD draw in this case? Does it convert the format from A8R8G8B8 to R5G6B5 like StretchRect would? Or does it just memcpy? In the latter case I'd expect a memory corruption due to the size mismatch.
2015-03-11 10:50 GMT+01:00 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-10 um 19:29 schrieb Matteo Bruni:
/* This works on AMD but fails on Nvidia (it draws black).*/ + /* {8, 8, 8, 8, 4, 4, D3DFMT_A8R8G8B8, D3DFMT_R5G6B5}, */ /* Different format */
What does AMD draw in this case? Does it convert the format from A8R8G8B8 to R5G6B5 like StretchRect would? Or does it just memcpy? In the latter case I'd expect a memory corruption due to the size mismatch.
It seems to do the conversion IIRC. Notice though that that table entry is commented out.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBAgAGBQJVAA/0AAoJEN0/YqbEcdMwKlcP/RVMf9nx/D4Emx4Viu9U3iGZ P1XV8AvAjKxJ/BNQ58HGCVH+9X3GXLLOJiv3H5CanOt7MxpwT+MX9hADYz9aZZTr lo45Gp5H4i2d9X2fNNNTcoY7y0lYV1R3YCEcSiQlick3o/0KTXPV5a6+m+Z1QDcV hlSjkj0SpZICVpzUwuU/FQuSyKE/ihcyZNGwtfxt+q+QdJDPzDp86QBV+s80snKD Yzsif4pAU2bLzrrM181qsRv0MB8mvfmfT25gPtjrZq5JekRe+WWhZ2uLrqQhkxAH y6A3TeVuIiRY0qwOMe05eEXAEZjLxDswJJDD7fLps3XcYYkpbIBLECjNqHhEFtK1 7DCjb7nQtJBFy+cX4ZBxRZ6X15Rsri6iQfP04e2/V44JWZrO6EHQvEybUw2i57+Y R1yLsf3KzDzpcy9At7gH4sFIvjDfuCROlblsdYmEwacwq+rO8kyRI6DhixPRtWDG beW6eMRUAVVyeQvXVCuLW6uPIpWuEdpmQZ7neug1YFfdqsG4YfR76RgQv6Gkj32V f3G/wGri8fF6PUWavZscdVdcD51LbkUQRyNy8CpRpxJe5AABGaecVj+nirskoKEo qFXcWxSUK5YHQ055WWn0UwQ2NabX62FNTki35tNqbZru/iivVbsEb4kcYeaYsMe9 TZrdk2aXSVrmHbd52LSi =xL1U -----END PGP SIGNATURE-----
-----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.
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)?
2015-03-11 13:41 GMT+01:00 Stefan Dösinger stefandoesinger@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%... (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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-11 um 14:52 schrieb Matteo Bruni:
I can test those, from the previous tests I expect that there isn't a consistent behavior among drivers.
If it's not too much effort. If it distracts you too much I'll look into this myself. Not sure if I'll write a formal test for this considering your findings so far, or just satisfy my curiosity.
2015-03-11 16:31 GMT+01:00 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-11 um 14:52 schrieb Matteo Bruni:
I can test those, from the previous tests I expect that there isn't a consistent behavior among drivers.
If it's not too much effort. If it distracts you too much I'll look into this myself. Not sure if I'll write a formal test for this considering your findings so far, or just satisfy my curiosity.
Oh, I'll test something, I have to update the patches and thus rerun them on Windows anyway. It will probably just be some quick and hacked up test unless it shows something unexpected.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBAgAGBQJVAF/TAAoJEN0/YqbEcdMw9MQQAIdLILsg+CHj/Dk+HK4TcEIm hhG7P30o/fUgH03YKHyx9B8F3B9W6covwUwbETIFYLGrz9QljZFJKP0tZZ4GWq89 NJR4y9EZTjL1FHN2eV5bpkRWk5Q7JO/f+x9XhHu2Ba3bihjQPvxPw0IEmwHidd/Q 6HJNt5IPOm2JiEYfk3+OWqjuxUsPXQCbmL+BAKNUNPyNvSx6tFKa6rgacq3p+DT1 WEW1wZOqUYm1/nO5eAf6JTW3RS/IiuW0+63QwVDeJ+fD6Ds3i5oWq+QZyQ47WtqK ACf0He07G4UuAYGm/ftc82CWwZ3qGdoALMzKsETXLFuN7uPrpNZLkJ2U+aAIGuOF fTr++qAjjW01AubdJi1Cn4EOxUkgJ/qctgxgFny4qGTCLPwVhqVWW9kIuMnXDtgL p9wNd3RVzQbgXHYStUmMyJQHP629bpef96CTzpTBSlBjg5t1zh9Bdq1MZgPuYo29 M1ch/xEeJOpmlP3Kfmcr2+NXxa1e+gP5C78n+8865GNc1oFoQ7aj1JVNpJzg+2YP tKk34v9Cjvxtrmkxsp0mjK84XLgEt254wrDaODowi3AS4WHgYtDIjXnk4KyNHqmg pfgO1WasVvMQRPJ/OUFXCMfeckxq78q8k8FjGKxUtMA26eYMSj/5plYU6v7wjMbK FDX6fcaw1Coq9DMhBnNk =y4Mf -----END PGP SIGNATURE-----
2015-03-11 16:46 GMT+01:00 Matteo Bruni matteo.mystral@gmail.com:
2015-03-11 16:31 GMT+01:00 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-11 um 14:52 schrieb Matteo Bruni:
I can test those, from the previous tests I expect that there isn't a consistent behavior among drivers.
If it's not too much effort. If it distracts you too much I'll look into this myself. Not sure if I'll write a formal test for this considering your findings so far, or just satisfy my curiosity.
Oh, I'll test something, I have to update the patches and thus rerun them on Windows anyway. It will probably just be some quick and hacked up test unless it shows something unexpected.
I ran some more tests which pretty much confirm the previous findings.
On AMD UpdateTexture seems to always convert data between different formats (e.g. A8R8G8B8 -> R32F, red has the correct converted values). I'm not sure about the UNORM -> SNORM conversion, that one might be broken but I didn't look very hard into it. On Nvidia it looks like data is copied if the source and destination formats have the same bpp (e.g. UNORM -> SNORM, but even A8R8G8B8 -> R32F gives the expected result of a "reinterpretation" of the data as in the destination format), otherwise nothing happens and the destination texture stays black. When it does work data is just copied, e.g. the X channel is copied intact into the A channel in X8R8G8B8 -> A8R8G8B8. For what it's worth, the X channel seems to be preserved on AMD too.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-16 um 17:38 schrieb Matteo Bruni:
On AMD UpdateTexture seems to always convert data between different formats (e.g. A8R8G8B8 -> R32F, red has the correct converted values). I'm not sure about the UNORM -> SNORM conversion, that one might be broken but I didn't look very hard into it. On Nvidia it looks like data is copied if the source and destination formats have the same bpp (e.g. UNORM -> SNORM, but even A8R8G8B8 -> R32F gives the expected result of a "reinterpretation" of the data as in the destination format), otherwise nothing happens and the destination texture stays black. When it does work data is just copied, e.g. the X channel is copied intact into the A channel in X8R8G8B8 -> A8R8G8B8. For what it's worth, the X channel seems to be preserved on AMD too.
Thanks for testing this. I'll at some later point do a similar test with ddraw blits. We know ddraw blits can stretch, convert between formats and transfer between different memory pools, but so far we don't know if they can do all 3 of those things at once.
-
Matteo Bruni -
Stefan Dösinger