On Aug 4, 2016 10:33 AM, "Marek Olšák" <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: > > On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > > Hey Marek, Thanks for working on this! > > > > On Aug 4, 2016 7:39 AM, "Marek Olšák" <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> 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. Yes > > - 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. I don't know that we need to but the docs say cut index doesn't work. > > > > 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. The docs say that you have to do it as follows: v2---+ | \ | | \ | | \| v1--v0 It also says that the fourth vertex is computed as v2 + v0 - v1 and had some words about screen alignment. But those are the docs which don't tell you how it works but rather "if you program it this way it will work". In reality it probably just takes the different edges from the different vertices or something like that. I don't know the details. > > 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. I'll have to look a little closer but we may be able to do that. > It's not clear yet whether or not this information gathering will be any useful. I think everyone agrees that the extension is useful, especially for glamor and the like. At some point we need to just draft something, plumb it through, write Piglit tests, and keep speccing until we can all do it. --Jason