[PATCH 14/20] glamor: stub out lines
Keith Packard
keithp at keithp.com
Mon Mar 24 12:47:06 PDT 2014
Markus Wick <markus at selfnet.de> writes:
> I don't get it, why are horizontal lines so much faster than vertical
> ones?
Presumably due to memory access patterns. When doing a horizontal line,
you're hitting all of the bytes in several cache lines, rather than only
a few bytes in each one. And, you're using fewer pages overall, which
reduces TLB abuse.
Intel X tiling (used for scanout buffers) is 128 x 8 pixels, so a single
page holds 128 pixels of a horizontal line, but only 8 pixels in a
vertical line. Memory is organized linearly within the tile, so
horizontal lines across the tile will write 128 pixels with only 8 cache
lines, while a vertical line will write 8 pixels and do
read-modify-write access on 8 cache lines. Given that, I'd expect
vertical lines to be about 32 times slower than horizontal ones.
There's also the impact on the TLB -- vertical lines hit 16 times as
many pages, so if you're TLB isn't large enough, you'll end up missing
a lot, and that also hurts performance.
> This sounds like software rasterization for GL_LINES.
> Should this be treated as a mesa bug or shall we write a workaround
> using triangles?
GL_LINES give us the correct semantics; I'd hate to try and match that
with triangles.
Even still, uxa is significantly faster than glamor on this one; uxa has
a simple test for a request that contains only vertical and horizontal
lines and fills those as rectangles. We could easily do the same thing
in glamor, which should yield better performance for this case. In fact,
I suspect we could do the test for all vertical/horizontal with the CPU
and let a vertex shader compute rectangles from the existing line
coordinates. Might be a fun exercise.
1: intel-glamor-line.perf
2: intel-uxa.perf
1 2 Operation
------------ ------------------------- -------------------------
4020000.0 10700000.0 ( 2.662) 500-pixel horizontal line segment
177000.0 9860000.0 ( 55.706) 500-pixel vertical line segment
--
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/20140324/a9c30e0a/attachment.sig>
More information about the xorg-devel
mailing list