From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI Date: Fri, 06 Feb 2015 16:06:16 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0262696879==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 329FA6E96E for ; Fri, 6 Feb 2015 08:06:16 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0262696879== Content-Type: multipart/alternative; boundary="1423238776.4551Bda0.9267"; charset="UTF-8" --1423238776.4551Bda0.9267 Date: Fri, 6 Feb 2015 16:06:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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. --1423238776.4551Bda0.9267 Date: Fri, 6 Feb 2015 16:06:16 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"
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.


You are receiving this mail because:
  • You are the assignee for the bug.
--1423238776.4551Bda0.9267-- --===============0262696879== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0262696879==--