Re: [PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().

[Stefan Dösinger]

> Am 04.01.2016 um 14:11 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>:
>
> This fixes commit b0d4502c29941c31108a53d6c23f9e23196fb7ec.
> I asked Riccardo about this init change in an earlier version, and afair he said creating cubemaps without a device crashes on some Windows drivers. I can't find the exchange in the archives, it was probably on IRC. Riccardo, do you remember why you made this change?
> -        if ((test_data[i].caps2 & DDSCAPS2_CUBEMAP)
> -                && !(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP))
> -        {
> -            skip("Device does not support cubemaps.\n");
> -            continue;
> -        }
> You're creating cubemaps without checking for support now.

[PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().

[Riccardo Bortolato]

2016-01-04 22:37 GMT+01:00 Stefan Dösinger <stefandoesinger(a)gmail.com>:
> > Am 04.01.2016 um 14:11 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>:
> >
> > This fixes commit b0d4502c29941c31108a53d6c23f9e23196fb7ec.
> > I asked Riccardo about this init change in an earlier version, and afair he said creating cubemaps without a device crashes on some Windows drivers. I can't find the exchange in the archives, it was probably on IRC. Riccardo, do you remember why you made this change?

Hello Stefan,

Unfortunately I don't keep logs and I cannot remember exactly but that
was done to fix a crash in a test bot or a Windows XP VirtualBox VM
(can't remember exactly).

In case of the bot, I guess it has either been fixed or some other
change in the ddraw test code correctly identifies the buggy driver?

Ciao,
Riccardo
> > -        if ((test_data[i].caps2 & DDSCAPS2_CUBEMAP)
> > -                && !(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP))
> > -        {
> > -            skip("Device does not support cubemaps.\n");
> > -            continue;
> > -        }
> > You're creating cubemaps without checking for support now.

[PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 2016-01-05 um 07:28 schrieb Riccardo Bortolato:
> Unfortunately I don't keep logs and I cannot remember exactly but
> that was done to fix a crash in a test bot or a Windows XP
> VirtualBox VM (can't remember exactly).
> Keep in mind that an earlier version of the test accidentally created
> a DDSCAPS_VIDEOMEMORY cube map texture. This was more likely to
> provoke bad driver behavior than the managed texture that's
> (presumably) mostly handled by the runtime until it is actually used
> for rendering.

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

iQIcBAEBCAAGBQJWjBqPAAoJEN0/YqbEcdMwx3cP/0weuNud1244g7ZUfneL/F9v
AjohCW/7oRpr1VqPfQJ5Ow+/MkGj+7hoh0vNCDhVX2/BP63T6sPzOcVjuoAVZ6ll
yjxpizqdTWok9J2OOSSZLm4LGHwV3xUg0dj6/cBFiJyTnFtdJBTzq+YIbje3H9L+
dmVZW4arsGn+PD2dST2k8mW2d8EFwpeWBeraiimcU8wtuCsfBnzKMHmqB4vD1vHA
Sxp/wVjGlEjMS4u+5oddFB2payLfCyRzHP+KJfDtSnO6If3NxJkFhX5JSyEKhgai
YHmdEZxcM+ONmRBwcBS1/zVidk6/YYZf2UbeG2bAVY+wPe+I+j9NHyR30mhxJi+c
nlRu6Y5X1e5sZLn2zo/73H8h9axtUc2mf9P0zlBpDk5QHOcP4tGTnfxCvcEi2OEf
vBZZlMVYvsacS+07Ue1tCsf1CrhRbzPIIRmXLlVE7fT1VidksN1N3eiojvtWNnJF
a4DkRdDVWjN8gaeuFBTBd7+PxhkK9Lflw4+/DO3IfUNfxMCAvrumyFfAUqLpxhk0
iW/+RcpINTP6DoXozuYVxC+0wSml/jjZzmmovHqAym6vSryZS1x4pktPyHUdMjDV
lzKxQZBuKjTqSqiwtjMhQQpRKuK69jbRDJSNNGOhT/k47eQUSoWunpa1ptYMxoBY
538cG4NkQ9Kk+jRcdmj5
=FFvC
-----END PGP SIGNATURE-----

[PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().

[Henri Verbeet]

On 4 January 2016 at 22:37, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
> I asked Riccardo about this init change in an earlier version, and afair he said creating cubemaps without a device crashes on some Windows drivers. I can't find the exchange in the archives, it was probably on IRC. Riccardo, do you remember why you made this change?

If it was for 64-bit ddraw, it was probably fixed by
2dca999e3393cb039d2aabebf7c83328925ab30e.
> > -        if ((test_data[i].caps2 & DDSCAPS2_CUBEMAP)
> > -                && !(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP))
> > -        {
> > -            skip("Device does not support cubemaps.\n");
> > -            continue;
> > -        }
> > You're creating cubemaps without checking for support now.

Yeah. I think that's either just supposed to work, or needs a
different kind of check, like e.g. "hal_caps.ddsCaps.dwCaps2 &
DDSCAPS2_CUBEMAP". Creating cubemaps works on the testbots without 3D
support at least, and I have the impression that
"device_desc.dpcTriCaps.dwTextureCaps" is for checking rendering
support. Note that different device types can be created from the same
ddraw interface, so it isn't necessarily clear that if e.g. a
TnLHalDevice can't render cubemaps a RGBDevice wouldn't be able to
either.

Unfortunately I don't have hardware without cubemap support, so I
suppose we'll have to wait for results from test.winehq.org, if any.