[Mesa-dev] [PATCH 0/6] Add support for GL_NV_fill_rectangle

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 3:33 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul <lyude at redhat.com> wrote:
>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák <maraeo at gmail.com>
>>> wrote:
>>> > Is there any user of this extension?
>>>
>>> Based on the spec, it seems like it would be useful for glamor.  No
>>> idea is anyone has code to use it yet.
>> Actually me, robclark and airlied were talking specifically about using
>> this for glamor and trying to implement it on other platforms using
>> rectangular primitives. No idea if that'll work (especially since I'm
>> new here), but it sounds promising enough to try :).
>>
>> Once I get this patch series upstream I'll probably look into writing
>> an implementation for softpipe and some other drivers
>
> Well radeons can't support or emulate the NV extension, so this is all
> just for nouveau. I doubt that airlied would want a nouveau-only
> codepath in glamor.
>
> Below is my definition of what a hypothetical MESA_rectangle_primitive
> should specify. It takes into account all we know about existing
> desktop hardware (AMD - we have the hw spec; Intel - I talked with
> them; NV - I read the NV fill extension).
>
>
> 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, 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)
> - The content of gl_FrontFacing is undefined.

Might want to mention something about smooth-interpolated varyings.
(See what NV_fill_rectangle has to say about it.)

>
> Return a GL error:
> - if clip planes, clip distances, or cull distances are enabled.
> - if face culling is enabled. (face determination is undefined)
> - if polygon mode is not fill
> - if primitive restart is enabled
> - if geometry or tessellation shaders are enabled
>
> 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 two-sided lighting is enabled and the colors are not the same for
> both sides.
>
> TODO:
> - Add piglit to verify that the order of vertices doesn't matter on Intel.

A few things to note:
 - NV_fill_rectangle is only supported on the newest GPUs
 - Software other than glamor (which I personally don't care much
about in the context of NV hardware) may start using NV_fill_rectangle

Are you objecting to the implementation of this nvidia-hw-only
extension? Or just mentioning that there's another way of specifying
this that will make it implementable on other hardware?

I don't have a killer use case for this extension, it's not like we
MUST start providing it for some piece of software to work well.
However irrespective of other extensions that may be added that work
well across a range of hw, I think it's worthwhile supporting this one
in nouveau.

Cheers,

  -ilia