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

[Marek Olšák]

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.

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

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

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

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

Marek