<p dir="ltr">Hey Marek,  Thanks for working on this!</p>
<p dir="ltr">On Aug 4, 2016 7:39 AM, "Marek Olšák" <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> This is my definition so far, which is an intersection of AMD and NV rectangles:<br>
><br>
> Definition and behavior:<br>
> - The rectangle primitive is defined by its first 3 vertices.<br>
> - The 4th vertex is derived (extrapolated) during rasterization.<br>
> - It's treated as a triangle by all stages before rasterization.<br>
> - The rectangle edges must be parallel or perpendicular to X and Y<br>
> axes ("axis-aligned), i.e. the rectangle can only be rotated in<br>
> 90-degree increments and flipped over.<br>
> - It must be rasterized as a rectangle (no diagonal tearing allowed,<br>
> no artifacts on the diagonal allowed)</p>
<p dir="ltr">More requirements:<br>
 - Must be solid<br>
 - No cut index (GS is supposed to be fine and Tess looks OK too)</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> The behavior is undefined:<br>
> - if the rectangle edges are not axis-aligned.<br>
> - if Z coordinates of all 3 vertices are not equal.<br>
> - if the rectangle intersects the clip space boundaries. (all options<br>
> are allowed: clip, cull, or accept the primitive)<br>
> - if clip planes, clip distances, or cull distances are enabled.<br>
> - if face culling is enabled. (face determination is undefined)<br>
> Likewise, the content of gl_FrontFacing is undefined.<br>
><br>
> It's possible to implement this on top of GL_NV_fill_rectangle. It's<br>
> not possible to implement GL_NV_fill_rectangle on top of this.<br>
><br>
> What do we need to add to accommodate Intel?<br>
><br>
> Thanks,<br>
> Marek<br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
><a href="mailto:mesa-dev@lists.freedesktop.org"> mesa-dev@lists.freedesktop.org</a><br>
><a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev"> https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</p>