NameDateSize

..10-Nov-20254 KiB

atomic.hH A D10-Nov-20253.1 KiB

blt.cH A D10-Nov-202528.3 KiB

brw/H10-Nov-20254 KiB

compiler.hH A D10-Nov-20253 KiB

debug.hH A D10-Nov-20251.5 KiB

fb/H10-Nov-20254 KiB

gen2_render.cH A D10-Nov-202591.8 KiB

gen2_render.hH A D10-Nov-202528.1 KiB

gen3_render.cH A D10-Nov-2025165.3 KiB

gen3_render.hH A D10-Nov-202555.1 KiB

gen4_common.cH A D10-Nov-20252 KiB

gen4_common.hH A D10-Nov-20251.7 KiB

gen4_render.cH A D10-Nov-202586.3 KiB

gen4_render.hH A D10-Nov-202578.4 KiB

gen4_source.cH A D10-Nov-20255.6 KiB

gen4_source.hH A D10-Nov-2025424

gen4_vertex.cH A D10-Nov-202577.8 KiB

gen4_vertex.hH A D10-Nov-2025514

gen5_render.cH A D10-Nov-202591 KiB

gen5_render.hH A D10-Nov-202581.7 KiB

gen6_common.cH A D10-Nov-20252.1 KiB

gen6_common.hH A D10-Nov-20254.6 KiB

gen6_render.cH A D10-Nov-202599.1 KiB

gen6_render.hH A D10-Nov-202558.7 KiB

gen7_render.cH A D10-Nov-2025103.4 KiB

gen7_render.hH A D10-Nov-202553.2 KiB

gen8_eu.cH A D10-Nov-202533.9 KiB

gen8_eu.hH A D10-Nov-2025886

gen8_render.cH A D10-Nov-2025103.1 KiB

gen8_render.hH A D10-Nov-202545.2 KiB

gen8_vertex.cH A D10-Nov-20259.2 KiB

gen8_vertex.hH A D10-Nov-2025337

kgem.cH A D10-Nov-2025187.1 KiB

kgem.hH A D10-Nov-202521.9 KiB

kgem_debug.cH A D10-Nov-202517.3 KiB

kgem_debug.hH A D10-Nov-20251 KiB

kgem_debug_gen2.cH A D10-Nov-202520.1 KiB

kgem_debug_gen3.cH A D10-Nov-202543.3 KiB

kgem_debug_gen4.cH A D10-Nov-202518.3 KiB

kgem_debug_gen5.cH A D10-Nov-202517.8 KiB

kgem_debug_gen6.cH A D10-Nov-202531 KiB

kgem_debug_gen7.cH A D10-Nov-202517.3 KiB

Makefile.amH A D10-Nov-20253.6 KiB

Makefile.inH A D10-Nov-202533.5 KiB

READMEH A D10-Nov-20251.7 KiB

rop.hH A D10-Nov-20256.3 KiB

sna.hH A D10-Nov-202531.3 KiB

sna_accel.cH A D10-Nov-2025462.8 KiB

sna_acpi.cH A D10-Nov-20255.1 KiB

sna_blt.cH A D10-Nov-2025113.9 KiB

sna_composite.cH A D10-Nov-202532 KiB

sna_cpu.cH A D10-Nov-20252.9 KiB

sna_cpuid.hH A D10-Nov-20252.1 KiB

sna_damage.cH A D10-Nov-202545.3 KiB

sna_damage.hH A D10-Nov-20258.9 KiB

sna_display.cH A D10-Nov-2025194 KiB

sna_display_fake.cH A D10-Nov-20258.5 KiB

sna_dri2.cH A D10-Nov-202588.5 KiB

sna_dri3.cH A D10-Nov-202510.2 KiB

sna_driver.cH A D10-Nov-202534.1 KiB

sna_glyphs.cH A D10-Nov-202559.8 KiB

sna_gradient.cH A D10-Nov-202512 KiB

sna_io.cH A D10-Nov-202549.7 KiB

sna_module.hH A D10-Nov-202554

sna_present.cH A D10-Nov-202512.5 KiB

sna_reg.hH A D10-Nov-20252.8 KiB

sna_render.cH A D10-Nov-202561.4 KiB

sna_render.hH A D10-Nov-202520.9 KiB

sna_render_inline.hH A D10-Nov-20258.8 KiB

sna_stream.cH A D10-Nov-20254 KiB

sna_threads.cH A D10-Nov-20258.2 KiB

sna_tiling.cH A D10-Nov-202531.3 KiB

sna_transform.cH A D10-Nov-20255.4 KiB

sna_trapezoids.cH A D10-Nov-202531.9 KiB

sna_trapezoids.hH A D10-Nov-202510.8 KiB

sna_trapezoids_boxes.cH A D10-Nov-202538.4 KiB

sna_trapezoids_imprecise.cH A D10-Nov-202594.7 KiB

sna_trapezoids_mono.cH A D10-Nov-202539.1 KiB

sna_trapezoids_precise.cH A D10-Nov-202586.7 KiB

sna_vertex.cH A D10-Nov-20251.4 KiB

sna_video.cH A D10-Nov-202518.8 KiB

sna_video.hH A D10-Nov-20255.7 KiB

sna_video_hwmc.cH A D10-Nov-20256.4 KiB

sna_video_hwmc.hH A D10-Nov-20251.6 KiB

sna_video_overlay.cH A D10-Nov-202522.7 KiB

sna_video_sprite.cH A D10-Nov-202519.6 KiB

sna_video_textured.cH A D10-Nov-202510.7 KiB

xassert.hH A D10-Nov-20251.6 KiB

README

1SandyBridge's New Acceleration
2------------------------------
3
4The guiding principle behind the design is to avoid GPU context switches.
5On SandyBridge (and beyond), these are especially pernicious because the
6RENDER and BLT engine are now on different rings and require
7synchronisation of the various execution units when switching contexts.
8They were not cheap on early generation, but with the increasing
9complexity of the GPU, avoiding such serialisations is important.
10
11Furthermore, we try very hard to avoid migrating between the CPU and GPU.
12Every pixmap (apart from temporary "scratch" surfaces which we intend to
13use on the GPU) is created in system memory. All operations are then done
14upon this shadow copy until we are forced to move it onto the GPU. Such
15migration can only be first triggered by: setting the pixmap as the
16scanout (we obviously need a GPU buffer here), using the pixmap as a DRI
17buffer (the client expects to perform hardware acceleration and we do not
18want to disappoint) and lastly using the pixmap as a RENDER target. This
19last is chosen because when we know we are going to perform hardware
20acceleration and will continue to do so without fallbacks, using the GPU
21is much, much faster than the CPU. The heuristic I chose therefore was
22that if the application uses RENDER, i.e. cairo, then it will only be
23using those paths and not intermixing core drawing operations and so
24unlikely to trigger a fallback.
25
26The complicating case is front-buffer rendering. So in order to accommodate
27using RENDER on an application whilst running xterm without a composite
28manager redirecting all the pixmaps to backing surfaces, we have to
29perform damage tracking to avoid excess migration of portions of the
30buffer.
31