[Mesa-dev] Expected wide line rendering with clipping

[Iago Toral]

On Sat, 2015-02-07 at 13:41 +0100, Erik Faye-Lund wrote:
> On Fri, Feb 6, 2015 at 1:11 PM, Iago Toral <itoral at igalia.com> wrote:
> > 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
> >          |                      |
> >         *|                      |
> >        **|                      |
> >       ***|                      |
> >      ****|                  ****|
> >     **** |                 **** |
> >    ****  |                ****  |
> 
> Is that drawing correct? I would expect it to look like this:
> 
>           |                      |
>          *|                      |
>         **|                    **|**
>        ***|                   ***|*
>       ****|                  ****|
>      **** |                 **** |
>     ****  |                ****  |

Yes, it is correct. Your expectation makes sense if things happen as
Roland described (first we clip the 1px line, then we expand), but the
result in i965 looks more like what you would obtain if you do it the
other way around.

As I mentioned in my response to Roland, I think i965 can't render what
you expect (at least directly), the reason being that it renders wide
lines as parallelograms instead of multiple 1px lines.

> From the drawing, it looks like the line is exactly 45 degrees, so I
> believe this particular case is actually undefined, because of the
> following spec wording:

Right, that was just my drawing. The dEQP test case renders an x-major
line.

> "Line segment rasterization begins by characterizing the segment as
> either x-major or y-major. x-major line segments have slope in the
> closed interval [−1, 1]; all other line segments are y-major (slope is
> determined by the segment’s endpoints)."
> 
> A 45 degree line should have a slope of 1, and should in theory be
> identified as an x-major line, giving the result dEQP expects (i965 is
> in this case rendering the line as similar to y-major, except y-major
> rendering should also generate fragments outside the viewport, as
> pointed out in my drawing above). However, since we're exactly at the
> break-off point, previous calculations are allowed to be off by some
> small value, leaving the characterization undefined.
> 
> So I think in this case, both results are allowed, and the test is
> therefore somewhat bogus. If the line was tilted a tiny amount so it's
> guaranteed to be characterized as an x-major, then it should be
> correct again. Not having access to the tests myself, they might
> already have done this, though.
>