32fc0c896e
As demonstrated by the all-important trap300, using the BLT is 2x faster than the RENDER ring for the simple case of solid fills. (Though note that performing the relocations costs 3x as much CPU for 2x GPU performance.) One case that may regress from this change is copywinpix which should benefit from the batching in the RENDER commands, and might warrant revisiting in the future (with realistic and synthetic benchmarks in hand!) However, due to the forced stall when switching rings, we still want to perform RENDER copies on behalf of DRI clients and before page-flips. Checking against cairo-perf-trace indicated no major impact -- I had worried that setting the BLT flag for some clears might have had a knock-on effect causing too many operations that could be pipelined on the RENDER ring to be sent to the BLT ring instead. Reported-by: Michael Larabel <Michael@phoronix.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> |
||
|---|---|---|
| .. | ||
| Makefile.am | ||
| README | ||
| blt.c | ||
| gen2_render.c | ||
| gen2_render.h | ||
| gen3_render.c | ||
| gen3_render.h | ||
| gen4_render.c | ||
| gen4_render.h | ||
| gen5_render.c | ||
| gen5_render.h | ||
| gen6_render.c | ||
| gen6_render.h | ||
| gen7_render.c | ||
| gen7_render.h | ||
| kgem.c | ||
| kgem.h | ||
| kgem_debug.c | ||
| kgem_debug.h | ||
| kgem_debug_gen2.c | ||
| kgem_debug_gen3.c | ||
| kgem_debug_gen4.c | ||
| kgem_debug_gen5.c | ||
| kgem_debug_gen6.c | ||
| sna.h | ||
| sna_accel.c | ||
| sna_blt.c | ||
| sna_composite.c | ||
| sna_damage.c | ||
| sna_damage.h | ||
| sna_display.c | ||
| sna_dri.c | ||
| sna_driver.c | ||
| sna_glyphs.c | ||
| sna_gradient.c | ||
| sna_io.c | ||
| sna_module.h | ||
| sna_reg.h | ||
| sna_render.c | ||
| sna_render.h | ||
| sna_render_inline.h | ||
| sna_stream.c | ||
| sna_tiling.c | ||
| sna_transform.c | ||
| sna_trapezoids.c | ||
| sna_video.c | ||
| sna_video.h | ||
| sna_video_hwmc.c | ||
| sna_video_hwmc.h | ||
| sna_video_overlay.c | ||
| sna_video_textured.c | ||
README
SandyBridge's New Acceleration ------------------------------ The guiding principle behind the design is to avoid GPU context switches. On SandyBridge (and beyond), these are especially pernicious because the RENDER and BLT engine are now on different rings and require synchronisation of the various execution units when switching contexts. They were not cheap on early generation, but with the increasing complexity of the GPU, avoiding such serialisations is important. Furthermore, we try very hard to avoid migrating between the CPU and GPU. Every pixmap (apart from temporary "scratch" surfaces which we intend to use on the GPU) is created in system memory. All operations are then done upon this shadow copy until we are forced to move it onto the GPU. Such migration can only be first triggered by: setting the pixmap as the scanout (we obviously need a GPU buffer here), using the pixmap as a DRI buffer (the client expects to perform hardware acceleration and we do not want to disappoint) and lastly using the pixmap as a RENDER target. This last is chosen because when we know we are going to perform hardware acceleration and will continue to do so without fallbacks, using the GPU is much, much faster than the CPU. The heuristic I chose therefore was that if the application uses RENDER, i.e. cairo, then it will only be using those paths and not intermixing core drawing operations and so unlikely to trigger a fallback. The complicating case is front-buffer rendering. So in order to accommodate using RENDER on an application whilst running xterm without a composite manager redirecting all the pixmaps to backing surfaces, we have to perform damage tracking to avoid excess migration of portions of the buffer.