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 :
>
> 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 :
> > Am 04.01.2016 um 14:11 schrieb Henri Verbeet :
> >
> > 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  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.