| 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 [details]
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.
Created attachment 113229 [details]
Image showing the expected triangle (top, drawn with nouveau), and the triangle
got on R600/SI (bottom)
| What | Removed | Added |
|---|---|---|
| CC | tizbac2@gmail.com |
Created attachment 113231 [details]
Xnine testcase that checks the output of fract on texcoord.x*16-1/256
Beware that the part to d3dadapter9.so is hardcoded so you will need to change
it
This testcase renders a quad of two triangles that cover the entire screen (
256x16) , and outputs what happens with frac along the X axis on the 15th line,
where the triangle that has problems lies
| What | Removed | Added |
|---|---|---|
| Attachment #113228 mime type | text/plain | image/png |
| What | Removed | Added |
|---|---|---|
| Attachment #113229 mime type | text/plain | image/png |
It also seems to be incorrect with half_pixel_center =3D 1.
With additional tests, we found out the problem comes out from the barycentric coordinates. On one of the triangle, one barycentric coordinate is very slightly below the expected value. It's not just on some pixels, but on all the pixels of the triangle. We also tested on an r600 card (hd3650), and the bug is the same. However for SI and R600, the handling of the barycentric interpolation seems to have evolved a lot. Could it be some state that has been forgotten in the doc, that would specify barycentric coordinates rounding ?
Created attachment 114504 [details]
Additionnal test
Additional test that draws a square of size 256 * 24.
The pos coordinates of the square are (-1-(1/256), 1+(1/16)) and (1-(1/256),
-1+(1/16))
the first texcoord a is 0 for the left of the square and 1 for the right
the second texcoord b is 0 at the top, 23 at the bottom.
the images shows the b-th bit of the mantisse of a.
On ilo, nouveau and llvmpipe, the image is black, except at the top, where we
see some white pixels with a specific scheme.
On radeonsi and r600, the top right triangle is the same than for the others,
but the bottom left triangle is almost full white.
This shows that the texcoord a has a value just below what it should have for
this triangle. This is the root of the problem, as the game shader with the
problem multiplies the texcoord value by a power of two, and then applies
floor. Because of this bug, it gets off by one problem.
This 'little below expected value on one of the triangle' problem doesn't
depend on the half_pixel_center = 0 parameter. It just happens that for what
the game does, the texcoord value with half_pixel_center = 1 instead of 0
(which would be correct value for nine), is above what it should be, and then
with the floor, the result is correct and not off by one.
| What | Removed | Added |
|---|---|---|
| Attachment #114504 mime type | text/plain | application/octet-stream |
Created attachment 114582 [details]
OpenGL version of the testcase
The red line at right and bottom is because coords are meant for dx9 raster
rules and not opengl ones
To compile GL , GLU, GLEW and GLUT are needed
| What | Removed | Added |
|---|---|---|
| Summary | Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI | Incorrect interpolation on R600 and SI |
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | WONTFIX |
This is how the hardware works. Even though it may lead to inc= orrect rendering sometimes, there is no workaround. This issue has been reported to hardware designers.