[PATCH 10/20] glamor: Add glamor_program based fill/set/get spans

[Keith Packard]

Markus Wick <markus at selfnet.de> writes:

> This will crash when GL_ARB_instanced_arrays isn't available.

Yeah, we need some infrastructure for testing and saving GL features...

> What are common values for RegionNumRects(gc->pCompositeClip)?

1.

> For lots (3+) of boxes, it's likely faster to pass the box as attribute 
> (with a much higher divisor) and discard in the pixel shader.

I'd like to avoid running the pixel shader at all when we have only one
clip rect, which the scissors technique does nicely.

For some operations, could we use instancing to intersect geometry
with each clip box in the vertex shader?

We could (obviously) have more than one code path here, but getting
performance data from real applications should be how we decide.

> Do bitsPerPixel have to be a multiple of 8? Isn't there a shared 
> function to calculate this pitch?

Yes, for anything living in GL it will be 8, 16 or 32 bpp. I'm not sure
there's a good convenience macro for dividing by 8 though.

> tbh, without an PBO, this is wrose than the fb fallback as it's one 
> stall per span.

Yes, it's completely miserable. However, it will never be called as the
only paths to get here are short-circuited above this in the driver. The
only way to even test this code is to disable much of the remaining
acceleration code.

> Also with PBO, it's still a huge overhead per span. I guess it's faster 
> for lots of spans (maybe 20+) to always fall back to fb.
> But I don't see another non-hacky way to implement this.

And, as it won't be executed in the future, we'd best leave it as simple
as possible. Bits of the X 2D API are 'sub-optimally designed' :-)

> We do have to find a way to upload this texture at once and to emit one 
> draw call (per fbo + box?).
> eg temporary 1D texture, better a texture buffer object.
> Everything is better than calling one gl function per span, also fb.

Again, this function cannot actually be reached without changing other
areas to re-direct to the MI image code, so efficiency doesn't matter,
only correctness when we are debugging other areas of the driver.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140320/9a4fab0c/attachment.sig>