mirror of
https://github.com/archlinuxarm/PKGBUILDs.git
synced 2024-11-18 22:54:00 +00:00
41 lines
1.5 KiB
Diff
41 lines
1.5 KiB
Diff
|
From 469655fab7a56eb32ff8cdefb33992813342353a Mon Sep 17 00:00:00 2001
|
||
|
|
From: Eric Anholt <eric@anholt.net>
|
||
|
|
Date: Mon, 18 May 2009 23:07:45 +0000
|
||
|
|
Subject: intel: Only do BO caching up to 64MB objects.
|
||
|
|
|
||
|
|
This avoids making objects significantly bigger than they would be
|
||
|
|
otherwise, which would result in some failing at binding to the GTT.
|
||
|
|
Found from firefox hanging on:
|
||
|
|
http://upload.wikimedia.org/wikipedia/commons/b/b7/Singapore_port_panorama.jpg
|
||
|
|
due to a software fallback trying to do a GTT-mapped copy between two 73MB
|
||
|
|
BOs that were instead each 128MB, and failing because both couldn't fit
|
||
|
|
simultaneously.
|
||
|
|
|
||
|
|
The cost here is that we get no opportunity to cache these objects and
|
||
|
|
avoid the mapping. But since the objects are a significant percentage
|
||
|
|
of the aperture size, each mapped access is likely having to fault and rebind
|
||
|
|
the object most of the time anyway.
|
||
|
|
|
||
|
|
Bug #20152 (2/3)
|
||
|
|
---
|
||
|
|
diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
|
||
|
|
index 61943f0..ef046f4 100644
|
||
|
|
--- a/libdrm/intel/intel_bufmgr_gem.c
|
||
|
|
+++ b/libdrm/intel/intel_bufmgr_gem.c
|
||
|
|
@@ -80,10 +80,10 @@ struct drm_intel_gem_bo_bucket {
|
||
|
|
int num_entries;
|
||
|
|
};
|
||
|
|
|
||
|
|
-/* Arbitrarily chosen, 16 means that the maximum size we'll cache for reuse
|
||
|
|
- * is 1 << 16 pages, or 256MB.
|
||
|
|
+/* Only cache objects up to 64MB. Bigger than that, and the rounding of the
|
||
|
|
+ * size makes many operations fail that wouldn't otherwise.
|
||
|
|
*/
|
||
|
|
-#define DRM_INTEL_GEM_BO_BUCKETS 16
|
||
|
|
+#define DRM_INTEL_GEM_BO_BUCKETS 14
|
||
|
|
typedef struct _drm_intel_bufmgr_gem {
|
||
|
|
drm_intel_bufmgr bufmgr;
|
||
|
|
|
||
|
|
--
|
||
|
|
cgit v0.8.2
|