Bug 25871

Created attachment 32446 [details]
fp-tri.c

Test program to provoke the bug. This is a hacked version of fp-tri.c from mesa/progs/fp that I was using to debug a problem with a bicubic filtering fragment program, so it can be a bit messy. If you have trouble sorting it out, then I can try to clean it up and remove non-essential bits.

Created attachment 32447 [details]
fragment program

The fragment program in its full form.

For point sampled textures, SQ_TEX_SAMPLER_WORD2_0.MC_COORD_TRUNCATE needs to be set to 1.  The default behavior for texture addressing is to round unless that bit is set.

Created attachment 43951 [details] [review]
possible fix

Does this patch help?

(In reply to comment #4)
> Created attachment 43951 [details] [review] [review]
> possible fix
> 
> Does this patch help?

this patch has been committed as

commit 1dc204d145dc8c0b19473a7814c201a8954b6274
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Mon Feb 28 21:52:19 2011 -0500

    r600g: truncate point sampled texture coordinates
    
    By default the hardware rounds texcoords.  However,
    for point sampled textures, the expected behavior is
    to truncate.  When we have point sampled textures,
    set the truncate bit in the sampler.
    
    Should fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=25871
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>

and reverted in

commit 72c6a748b9ffdaa893f82faf911f22a241a5e4f5
Author: Marek Olšák <maraeo@gmail.com>
Date:   Mon May 2 01:10:19 2011 +0200

    Revert "r600g: truncate point sampled texture coordinates"
    
    This reverts commit 1dc204d145dc8c0b19473a7814c201a8954b6274.
    
    MC_COORD_TRUNCATE is for MPEG and produces quite an interesting behavior
    on regular textures. Anyway that commit broke filtering in demos/cubemap.


reassigning to r600g

is this still an issue with a newer mesa (e.g. 8.0.4 or git master)?

I don't have any updated systems right now, so I can't really test. Test program should still be valid though.

Created attachment 66984 [details]
captured shader

I have tested your modified fp-tri-c from attachment 32446 [details]
with r600g on my rv770 .
I got the following output with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd
and mesa 8.0.4:

$ ./fp-tri -fps foo2.arb
!!ARBfp1.0

TEX result.color, 0.498046860099, texture[0], 2D;

END

GL_RENDERER = Gallium 0.4 on AMD RV770
glGetError = 0x0
12850 frames in 5.0 seconds = 2570.000 FPS

Additionally I have attached a screen shot from the shader.

What is the expected behavior?

might be fixed with this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f44bda17f515c411071ca8744ebd96039d9c583b

(In reply to comment #8)
> might be fixed with this commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f44bda17f515c411071ca8744ebd96039d9c583b


I can't see any difference between mesa git master and mesa 8.0.4 .

What is the expected behavior?

(In reply to comment #7)
> 
> What is the expected behavior?

It's so long ago I don't remember the exact details. You can easily figure it out though. The test program creates a 4x4 checker board texture and then uses a single point on it to draw the triangles. The range [0.25,0.5[ should all be the same color. The bug was that as you approached 0.5, it started sampling the next pixel prematurely.

So change the fragment program to use coordinate 0.4 or something like that. That colour should be the same as 0.4999... . Looking at the code, white seems to be the correct colour.

(In reply to comment #10)
> 
> It's so long ago I don't remember the exact details. You can easily figure it
> out though. The test program creates a 4x4 checker board texture and then uses
> a single point on it to draw the triangles. The range [0.25,0.5[ should all be
> the same color. The bug was that as you approached 0.5, it started sampling the
> next pixel prematurely.
> 
> So change the fragment program to use coordinate 0.4 or something like that.
> That colour should be the same as 0.4999... . Looking at the code, white seems
> to be the correct colour.

Ok I've got it.

With coordinate 0.4 I get a white color and with 0.4999 I get black.

Additionally I checked the other end of the range:
Between the range [0.2480468676,0.498046860099] the color is white.
If I change the fragment program to use coordinate 0.2480468675 then the color is black. With 0.4980468601 I get also black.

So the issue persists in git mesa master 9.1-devel (git-e81ee67)

I think this is a normal behavior and it's not a precision issue. The coordinates are rounded to 0.5, because the filter is NEAREST (and 0.5 is the nearest pixel). Closing as NOTABUG.

Hardly NOTABUG. There is no pixel at 0.5. The pixels are at 0.125, 0.375, 0.625 and 0.875. 0.49999 should get rounded to the 0.375 pixel. That's the closest, not the 0.625 one.

Thanks for the feedback. So it is a precision issue after all. If fglrx exhibits the same behavior, there is nothing I can do. I don't know of any hardware state which controls precision of texture addressing.

(In reply to comment #14)
> Thanks for the feedback. So it is a precision issue after all. If fglrx
> exhibits the same behavior, there is nothing I can do. I don't know of any
> hardware state which controls precision of texture addressing.

AMD's Windows drivers at least seemingly consistently performs nearest-filtering with round-off-point off by a 512th of a texel. So I think this is somehow intended (even if really unfortunate for some non-trivial usecases).

(In reply to comment #14)
> Thanks for the feedback. So it is a precision issue after all. If fglrx
> exhibits the same behavior, there is nothing I can do. I don't know of any
> hardware state which controls precision of texture addressing.

I would guess it needs input from the AMD folks. So I guess getting their attention is one thing that could be done. Maybe a microcode update could solve.

I also haven't tested this in ages. Might not be an issue for modern chips...