Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.

[Henri Verbeet]

On 19 February 2017 at 12:47, Stefan Dösinger  wrote:
> @@ -10746,7 +10746,8 @@ static void test_pointsize(void)
>      IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL);
>  /* The following code tests point sprites with two textures, to see if each texture coordinate unit
> -
> * generates texture coordinates for the point(result: Yes, it does)
> -
> * generates texture coordinates for the point. Result: Yes, it does, except on some older hardware
> -
> * (r500 and earlier, probably others).
> *
> * However, not all GL implementations support point sprites(they need GL_ARB_point_sprite), but there
> * is no point sprite cap bit in d3d because native d3d software emulates point sprites. Until the
>
> @@ -10802,6 +10803,11 @@ static void test_pointsize(void)
>      color = getPixelColor(device, 64-4, 64-4);
>      ok(color == 0x00ff0000, "pSprite: Pixel (64-4),(64-4) has color 0x%08x, expected 0x00ff0000\n", color);
>      color = getPixelColor(device, 64-4, 64+4);
> - if (color == 0x00ff0000)
> - {
> -
>    skip("Hardware generates point sprite coordinates on texture unit 0 only.\n");
> -
>    goto cleanup_1tex;
> - }
> ok(color == 0x00000000, "pSprite: Pixel (64-4),(64+4) has color 0x%08x, expected 0x00000000\n", color);
> color = getPixelColor(device, 64+4, 64+4);
> ok(color == 0x0000ff00, "pSprite: Pixel (64+4),(64+4) has color 0x%08x, expected 0x0000ff00\n", color);

This test has been around for a while, did it always fail? I also have
the impression the hardware should be able to do this, does this fail
on Linux, Windows, or both?

[PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.

[Stefan Dösinger]

Am 2017-02-20 um 15:59 schrieb Henri Verbeet:
> This test has been around for a while, did it always fail?

I think so. I remember seeing this a long time ago and when I worked on
this over the weekend I thought I sent a patch long ago.
> I also have the impression the hardware should be able to do this,
> does this fail on Linux, Windows, or both?

The failure happens on Windows. But I originally introduced this test
because Linux on the same hardware had worse problems in such situations
(668328a6). Unfortunately at the time I didn't have a Windows
installation on this computer, otherwise I would have caught the test
failure right away.

I guess all that's needed to support it is to redirect all reads that go
to a register loaded from TEXCOORD1 or higher to TEXCOORD0. We're
already doing that by reading gl_PointCoord regardless of the usage index.

I'll do some double-checking to be sure and run the original test code
on Windows. And since we're happily handling the problem in Wine I think
the skip should be a win_skip instead.