[Mesa-dev] Expected wide line rendering with clipping

[Roland Scheidegger]

Am 09.02.2015 um 09:53 schrieb Iago Toral:
> On Fri, 2015-02-06 at 21:27 +0100, Roland Scheidegger wrote:
>> 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.
> 
> That makes sense, but in that case I think i965 rendering would still be
> incorrect, the expected result would look something like this:
> 
>           |
>           |
>         **|
>        ***|
>       ****|
>      **** |
>     ****  |
> 
> However, as far as I can tell, since i965 hardware renders wide lines as
> parallelograms, it can't render something like this. 
> 
> Actually, the rendering result looks more like something we would obtain
> if we did line expansion before clipping:
> 
>           |
>           |
>           |
>           |
>       ****|
>      **** |
>     ****  |

Ok that seems incorrect then - I thought this was merely the inprecision
of the ascii art.
I think though I didn't really get all the details of wide line
rendering previously, in particular the major/minor axis bits, which are
again sort of surprising (naively you would expect wide lines to be a
rectangle, not reproduce replicated fragments along the minor axis, but
that's only true for antialiased lines). Due to that it could be that
what i965 produces is indeed correct - the spec says render with a line
which is essentially offset from the real line with width/2 and
replicate fragments in the minor direction, and I'm not really sure it
should produce fragments then if the "virtual endpoint" lies outside the
viewport (though I would still suspect yes since this ought to still be
happening after clipping).
But maybe i965 just renders wide (non-antialiased lines) by offsetting
them at primitive setup time, then clips them, and does the wide-line
thing at rasterization, which would lead to this result. Though in this
case this would make it asysmmetrical wrt to left/right edges right? So
this would happen only on the right edge, at the left edge with the same
line it would render them until it touches the viewport, that is it
would look like this:

|           |
|           |
|           |
|       ****|
|      **** |
|     ****  |
|    ****   |
|   ****    |
|  ****     |
| ****      |
|***        |
|**         |
|*          |
|           |

Whereas I suspect it should indeed be:

|           |
|           |
|         **|
|       ****|
|      **** |
|     ****  |
|    ****   |
|   ****    |
|  ****     |
| ****      |
|***        |
|**         |
|           |
|           |

I don't know if it's really worth bothering though, I bet what everybody
really wants to see for wide lines is rectangles anyway (which you
clearly won't get according to the spec with non-antialiased lines).
Wide line rendering along with points is really messed up imho.

Roland


> 
>> 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
>>
>>
>>
> 
>