[Mesa-dev] Intel: Please help define the common rectangle primitive type

[Jason Ekstrand]

On Aug 4, 2016 10:33 AM, "Marek Olšák" <maraeo at gmail.com> wrote:
>
> On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:
> > Hey Marek,  Thanks for working on this!
> >
> > On Aug 4, 2016 7:39 AM, "Marek Olšák" <maraeo at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> This is my definition so far, which is an intersection of AMD and NV
> >> rectangles:
> >>
> >> Definition and behavior:
> >> - The rectangle primitive is defined by its first 3 vertices.
> >> - The 4th vertex is derived (extrapolated) during rasterization.
> >> - It's treated as a triangle by all stages before rasterization.
> >> - The rectangle edges must be parallel or perpendicular to X and Y
> >> axes ("axis-aligned), i.e. the rectangle can only be rotated in
> >> 90-degree increments and flipped over.
> >> - It must be rasterized as a rectangle (no diagonal tearing allowed,
> >> no artifacts on the diagonal allowed)
> >
> > More requirements:
> > - Must be solid
>
> I take it you mean the polygon mode.

Yes

> > - No cut index (GS is supposed to be fine and Tess looks OK too)
>
> I'd be OK with dropping GS and Tess support for rectangles.

I don't know that we need to but the docs say cut index doesn't work.

> >
> > Our hardware docs *say* that the vertices have to come in a particular
> > order.  That said, I've gotten it wrong without the hardware exploding
> > before.  I think we could write a Piglit test that checks all the
orders and
> > test for it fairly easily.
>
> This is the most tricky one. I'd need a clear definition of what "a
> particular order" means. The rasterization order is different between
> windows and FBOs.

The docs say that you have to do it as follows:

v2---+
| \  |
|  \ |
|   \|
v1--v0

It also says that the fourth vertex is computed as v2 + v0 - v1 and had
some words about screen alignment.  But those are the docs which don't tell
you how it works but rather "if you program it this way it will work".  In
reality it probably just takes the different edges from the different
vertices or something like that.  I don't know the details.

> > Also, clipping... The docs say that we can't clip them with the normal
> > clipper.  It also says that we need to disable the viewport which means
we
> > are left with no clipping whatsoever and OOB rectangles may write to
random
> > memory outside the surface.  This is bad.  Without further
experimentation,
> > I can't say how much of this is true and how much of it is just
> > recommendation.  Given that RECTLIST is intended for internal operations
> > only, it could be anywhere on that spectrum and may be different on
> > different hardware.  We could, in theory apply the viewport and do
clipping
> > either in a geometry shader or as something we append onto the end of
the
> > VS.  A bit ugly, but it would work.
>
> I declared clipping as undefined, including frustum clipping. That
> means all vertices must be inside the viewport and all user clipping
> must be disabled.
>
> If your driver uses guard bands (which skips clipping), it probably
> also uses a scissor test of some kind to cull pixels out of viewport
> bounds.

I'll have to look a little closer but we may be able to do that.

> It's not clear yet whether or not this information gathering will be any
useful.

I think everyone agrees that the extension is useful, especially for glamor
and the like.  At some point we need to just draft something, plumb it
through, write Piglit tests, and keep speccing until we can all do it.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160804/a987abc1/attachment.html>