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

[Jason Ekstrand]

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
- No cut index (GS is supposed to be fine and Tess looks OK too)

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.

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.

My reading of the docs seems to indicate that it's treated like a TRILIST
all the way through until right before rasterization where it's handled
differently.  If true, that may imply that it will work fine and the
failure mode for disobeying the rules is just wonky rectangles.  In any
case, *lots* of Piglit tests are in order, especially ones that break or
bend the rules.

> The behavior is undefined:
> - if the rectangle edges are not axis-aligned.
> - if Z coordinates of all 3 vertices are not equal.
> - if the rectangle intersects the clip space boundaries. (all options
> are allowed: clip, cull, or accept the primitive)
> - if clip planes, clip distances, or cull distances are enabled.
> - if face culling is enabled. (face determination is undefined)
> Likewise, the content of gl_FrontFacing is undefined.
>
> It's possible to implement this on top of GL_NV_fill_rectangle. It's
> not possible to implement GL_NV_fill_rectangle on top of this.
>
> What do we need to add to accommodate Intel?
>
> Thanks,
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160804/6b2131e1/attachment-0001.html>