Hi,
Eduardo and I have been looking into a few dEQP test failures that deal
with wide line rendering. There are a few of them that fail because of
how clipping is implemented for this case.
The problem in these cases seems to be that the hw renders the wide line
as a parallelogram so that if an edge of the parallelogram is partially
clipped, the other parallel edge will also be clipped at the same
height/width so that the resulting wide line stays a parallelogram. The
dEQP renders as if a wide line where a collection of 1px lines, so
cliping one edge of the resulting line does not have implications for
the other edge.
This ASCII art illustrates the problem (* represent line pixels, |
represents the viewport's rightmost edge):
Expected by dEQP i965 rendering
| |
*| |
**| |
***| |
****| ****|
**** | **** |
**** | **** |
We can make the rendering result match dEQP's expectation by enabling
the GuardBand in the clip stage (GEN6_CLIP_GB_TEST). This is being
disabled by the driver for gen7 in this scenario because the underlying
framebuffer surface is larger than the viewport, and per the comment in
the code, in gen7 that would make it render beyond the viewport limits
in that surface, while it notes that gen8 hw fixes this. So I guess that
we do not want to do this in any case in gen7.
Then, I have been reviewing the OpenGL specs to see if they clarify what
should happen when clipping wide lines and I think the spec does not
make a clear point, since when it talks about line clipping it does not
cover the case of wide lines specifically:
"13.5. PRIMITIVE CLIPPING
...
If part of the line segment lies in the volume and part lies outside,
then the line segment is clipped and new vertex coordinates are computed
for one or both vertices. A clipped line segment endpoint lies on both
the original line segment and the boundary of the clip volume.
...
"
The above description is clear for 1px lines, but where should the new
vertex be generated exactly for wide lines, where many points could be
at the boundary of the clip volume? Is any point valid? (that would mean
the dEQP test is bogus because there are multiple accepted renderings),
should the new vertex be exactly at the center of the line? (that would
make both deqp and intel rendering bogus).
Then there is also this comment in "14.5.2.2 Wide Lines" inside the
non-AA line rasterization chapter:
"Non-antialiased line segments of width other than one are rasterized by
off-setting them in the minor direction (for an x-major line, the minor
direction is y, and for a y-major line, the minor direction is x) and
replicating fragments in the minor direction (see figure 14.3). Let w be
the width rounded to the nearest integer (if w = 0, then it is as if w =
1). If the line segment has endpoints given by (x 0 , y 0 ) and (x 1 , y
1 ) in window coordinates, the segment with endpoints (x 0 , y 0 − (w −
1)/2) and (x 1 , y 1 − (w − 1)/2) is rasterized, but instead of a single
fragment, a column of fragments of height w (a row of fragments of
length w for a y-major segment) is produced at each x (y for y-major)
location. The lowest fragment of this column is the fragment that would
be produced by rasterizing the segment of width 1 with the modified
coordinates."
This "suggests" that wide line rendering should be equivalent to
rendering multiple lines of width=1 and if we actually did that then the
expected rendering result after clipping would be what dEQP expects.
I think the whole thing isn't 100% clear. Does anyone have any thoughts
on what should be considered correct behavior in this case?
Iago
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
