summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_context.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2016-08-24 20:35:46 +0100
committerChris Wilson <chris@chris-wilson.co.uk>2016-08-26 09:09:34 +0100
commitf92a87a14068dd17a32b41b1586421cef6eaa37f (patch)
treeb047683597a18ab4c5983004ad0042e94ba45459 /src/mesa/drivers/dri/i965/brw_context.c
parentbc5be5323f14c4f790ecaf29991158be1f5435b0 (diff)
downloadexternal_mesa3d-f92a87a14068dd17a32b41b1586421cef6eaa37f.zip
external_mesa3d-f92a87a14068dd17a32b41b1586421cef6eaa37f.tar.gz
external_mesa3d-f92a87a14068dd17a32b41b1586421cef6eaa37f.tar.bz2
i965: Embrace "unlimited" GTT mmap support
From about kernel 4.9, GTT mmaps are virtually unlimited. A new parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the feature so query it and use it to avoid limiting tiled allocations to only fit within the mappable aperture. A couple of caveats: - fence support is still limited by stride to 262144 and the stride needs to be a multiple of tile_width (as before, and same limitation as the current 3D pipeline in hardware) - the max_gtt_map_object_size forcing untiled may be hiding a few bugs in handling of large objects, though none were spotted in piglits. See kernel commit 4cc6907501ed ("drm/i915: Add I915_PARAM_MMAP_GTT_VERSION to advertise unlimited mmaps"). v2: Include some commentary on mmap virtual space vs CPU addressable space. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'src/mesa/drivers/dri/i965/brw_context.c')
-rw-r--r--src/mesa/drivers/dri/i965/brw_context.c17
1 files changed, 2 insertions, 15 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
index d6f0d7b..1364393 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1044,21 +1044,6 @@ brwCreateContext(gl_api api,
brw->urb.max_ds_entries = devinfo->urb.max_ds_entries;
brw->urb.max_gs_entries = devinfo->urb.max_gs_entries;
- /* Estimate the size of the mappable aperture into the GTT. There's an
- * ioctl to get the whole GTT size, but not one to get the mappable subset.
- * It turns out it's basically always 256MB, though some ancient hardware
- * was smaller.
- */
- uint32_t gtt_size = 256 * 1024 * 1024;
-
- /* We don't want to map two objects such that a memcpy between them would
- * just fault one mapping in and then the other over and over forever. So
- * we would need to divide the GTT size by 2. Additionally, some GTT is
- * taken up by things like the framebuffer and the ringbuffer and such, so
- * be more conservative.
- */
- brw->max_gtt_map_object_size = gtt_size / 4;
-
if (brw->gen == 6)
brw->urb.gs_present = false;
@@ -1069,6 +1054,8 @@ brwCreateContext(gl_api api,
brw->predicate.state = BRW_PREDICATE_STATE_RENDER;
+ brw->max_gtt_map_object_size = screen->max_gtt_map_object_size;
+
brw->use_resource_streamer = screen->has_resource_streamer &&
(env_var_as_boolean("INTEL_USE_HW_BT", false) ||
env_var_as_boolean("INTEL_USE_GATHER", false));