Index of /archives/NetBSD/NetBSD-release-10/xsrc/external/mit/xf86-video-intel/dist/src/sna
Name Last modified Size Description
![[PARENTDIR]](/icons/back.gif)
Parent Directory -
![[TXT]](/icons/text.gif)
xassert.h 2019-03-20 15:34 2.0K
sna_video_textured.c 2019-03-20 15:34 12K
sna_video_sprite.c 2019-03-20 15:34 25K
sna_video_overlay.c 2019-03-20 15:34 22K
sna_video_hwmc.h 2014-03-22 07:42 1.6K
sna_video_hwmc.c 2015-01-17 06:27 6.4K
sna_video.h 2022-07-15 13:13 7.7K
sna_video.c 2019-03-20 15:34 25K
sna_vertex.c 2014-11-06 02:56 1.4K
sna_trapezoids_precise.c 2019-03-20 15:34 86K
sna_trapezoids_mono.c 2019-03-20 15:34 41K
sna_trapezoids_imprecise.c 2019-03-20 15:34 94K
sna_trapezoids_boxes.c 2019-03-20 15:34 38K
sna_trapezoids.h 2015-01-17 06:27 11K
sna_trapezoids.c 2015-01-17 06:27 32K
sna_transform.c 2015-01-17 06:27 5.4K
sna_tiling.c 2019-03-20 15:34 31K
sna_threads.c 2014-11-06 02:56 8.2K
sna_stream.c 2014-11-06 02:56 4.0K
sna_render_inline.h 2019-03-20 15:34 9.3K
sna_render.h 2019-03-20 15:34 23K
sna_render.c 2019-03-20 15:34 63K
sna_reg.h 2014-11-06 02:56 2.8K
sna_present.c 2019-03-20 15:34 27K
sna_module.h 2014-03-22 07:42 54
sna_io.c 2019-03-20 15:34 50K
sna_gradient.c 2014-11-06 02:56 12K
sna_glyphs.c 2019-03-20 15:34 60K
sna_driver.c 2019-03-20 15:49 37K
sna_dri3.c 2019-03-20 15:34 11K
sna_dri2.c 2019-03-20 15:49 103K
sna_display_fake.c 2019-03-20 15:34 8.5K
sna_display.c 2019-03-20 15:49 248K
sna_damage.h 2019-03-20 15:34 9.0K
sna_damage.c 2014-11-06 02:56 45K
sna_cpuid.h 2014-11-06 02:56 2.1K
sna_cpu.c 2014-11-06 02:56 2.9K
sna_composite.c 2019-03-20 15:34 33K
sna_blt.c 2019-03-20 15:34 115K
sna_acpi.c 2019-03-20 15:49 5.1K
sna_accel.c 2022-07-15 13:13 472K
sna.h 2019-03-20 15:49 35K
rop.h 2014-03-22 07:42 6.3K
![[ ]](/icons/unknown.gif)
meson.build 2019-03-20 15:34 2.7K
kgem_debug_gen7.c 2014-03-22 07:42 17K
kgem_debug_gen6.c 2019-03-20 15:34 31K
kgem_debug_gen5.c 2019-03-20 15:34 18K
kgem_debug_gen4.c 2019-03-20 15:34 18K
kgem_debug_gen3.c 2014-03-22 07:42 43K
kgem_debug_gen2.c 2014-11-06 02:56 20K
kgem_debug.h 2014-03-22 07:42 1.0K
kgem_debug.c 2014-11-06 02:56 17K
kgem.h 2019-03-20 15:34 23K
kgem.c 2019-03-20 16:17 203K
git_version.h.in 2019-03-20 15:34 47
gen9_render.h 2019-03-20 15:34 45K
gen9_render.c 2019-03-20 15:34 109K
gen8_vertex.h 2014-11-06 02:56 337
gen8_vertex.c 2014-11-06 02:56 9.2K
gen8_render.h 2019-03-20 15:34 45K
gen8_render.c 2019-03-20 15:34 106K
gen8_eu.h 2014-11-06 02:56 886
gen8_eu.c 2015-01-17 06:27 34K
gen7_render.h 2014-03-22 07:42 53K
gen7_render.c 2019-03-20 15:34 106K
gen6_render.h 2014-03-22 07:42 59K
gen6_render.c 2019-03-20 15:34 101K
gen6_common.h 2019-03-20 15:34 5.0K
gen6_common.c 2014-11-06 02:56 2.1K
gen5_render.h 2019-03-20 15:34 82K
gen5_render.c 2019-03-20 15:34 93K
gen4_vertex.h 2014-11-06 02:56 514
gen4_vertex.c 2015-01-17 06:27 78K
gen4_source.h 2014-03-22 07:42 424
gen4_source.c 2014-03-22 07:42 5.6K
gen4_render.h 2019-03-20 15:34 78K
gen4_render.c 2019-03-20 15:34 88K
gen4_common.h 2014-11-06 02:56 1.7K
gen4_common.c 2014-11-06 02:56 2.0K
gen3_render.h 2014-03-22 07:42 55K
gen3_render.c 2019-03-20 15:34 169K
gen2_render.h 2014-03-22 07:42 28K
gen2_render.c 2019-03-20 15:34 100K
![[DIR]](/icons/folder.gif)
fb/ 2022-12-18 05:58 -
debug.h 2019-03-20 15:34 1.5K
compiler.h 2019-03-20 15:34 3.2K
brw/ 2022-12-18 05:58 -
blt.c 2019-03-20 15:34 46K
atomic.h 2014-03-22 07:42 3.1K
README 2014-03-22 07:42 1.7K
Makefile.in 2019-03-20 16:17 41K
Makefile.am 2019-03-20 15:34 3.7K
CVS/ 2022-12-18 05:58 -
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.