[Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2305 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=89012

            Bug ID: 89012
           Summary: Incorrect behaviour of half_pixel_center = 0
                    rasterizer setting on R600 and SI
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: axel.davy@ens.fr
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 113228
  --> https://bugs.freedesktop.org/attachment.cgi?id=113228&action=edit
result drawn by the test. The bottom triangle is wrong.

Tested on Evergreen and CAPE VERDE.

Nine uses the rasterize setting half_pixel_center = 0,
which means, as the docs puts it:
"the rasterizer should use (0, 0) pixel centers for determining pixel
ownership". This is the mode needed for d3d9.

The hw has a state for that.
For example on SI, PA_SU_VTX_CNTL has PIX_CENTER set to 0 to get this
rasterizer mode. The doc says that the hw implements it by adding 0.5. This is
the same for R600.

But is seems it requires some other things to work, or that it is buggy, or
something else we don't know.

We have some games having bugs because of off by 1 results for the drawing.
This causes red shadows for example for Borderlands 2.
Nouveau and llvmpipe don't hit these bugs.

The problem is that the translation seems to suffer precision issue or
something.
We tried play a lot with the states for IEEE-> fixed float prevision on the two
cards and with FLOAT_ROUND, but that didn't solve the issue.

The problem can be reproduced with the attached demo, using Xnine (you need
edit Xnine.c to fix the loading path of the nine module). This attached image
show the visual result: on two triangles drawn, one gets off-by one pixels(the
one of the bottom). These issues only happen with corner cases vertex
positions.

The program also outputs some numbers, and the green ones should show 1,
but on R600 and radeonsi they will show 0.999998. the fact this result is below
1, will make floor result in the wrong number, and causes the off by one pixel
issue of the demo.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3831 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel