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

[Marek Olšák]

On Thu, Mar 23, 2017 at 9:59 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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.

My objection was only about Glamor, and the other use cases were for
my curiosity, as I think we are all guilty of doing things that are
"interesting" without any use case, but you could have said that the
goal was to get familiar with the code. :)

Marek