On Thu, Mar 23, 2017 at 9:59 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Thu, Mar 23, 2017 at 3:33 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul <ly...@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 <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev