[Mesa-dev] Expected wide line rendering with clipping

[Roland Scheidegger]

Am 06.02.2015 um 13:11 schrieb Iago Toral:
> 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
> 
> 

I am quite sure that i965 rendering is what (at least legacy GL)
expects. This is because the wide-line expansion is defined to be
happening at rasterization time, i.e. past clipping. Thus, at clipping
time, no matter if a line is wide or not, it is still really a line,
hence clipping will produce a single new endpoint at the viewport edge
and in rasterization this is then what will be used as the endpoint.
FWIW a very similar problem exists for points, and this is something
which sometimes comes up. A point is either clipped fully or not at all,
which causes large points to both disappear suddenly when the center is
outside the viewport, and to get drawn fully even outside the viewport
if the center is within the viewport! This is a really annoying
difference to d3d (9 as 10 ditched points) which causes us a lot of pain
(and it's noteworthy at least nvidia doesn't implement it the GL way all
the time, depending on several factors but I don't know them exactly).
gallium has the point_tri_clip bit for this but it's not settable from
GL. For lines though there's nothing in gallium neither, and it may not
be really correct for GL (if drivers use draw's wide line stage, it will
be expanded as GL expects since clipping happens earlier, but drivers
implementing it themselves may well do d3d behavior).

Personally I think you shouldn't expect any specific result since what
the spec calls for is somewhat unexpected and drivers may chose to
ignore that ;-).


Roland