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 <stefandoesinger(a)gmx.at> 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.