[PATCH 2/5] d3d9/tests: Add a test for UpdateTexture.
matteo.mystral at gmail.com
Mon Mar 16 11:38:10 CDT 2015
2015-03-11 16:46 GMT+01:00 Matteo Bruni <matteo.mystral at gmail.com>:
> 2015-03-11 16:31 GMT+01:00 Stefan Dösinger <stefandoesinger at 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.
More information about the wine-devel