<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89012">89012</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr>
<tr>
<th>Version</th>
<td>git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Drivers/Gallium/radeonsi
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dri-devel@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>axel.davy@ens.fr
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>dri-devel@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=113228" name="attach_113228" title="result drawn by the test. The bottom triangle is wrong.">attachment 113228</a> <a href="attachment.cgi?id=113228&action=edit" title="result drawn by the test. The bottom triangle is wrong.">[details]</a></span>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>