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)

1 files changed, 3 insertions, 3 deletions

diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
index 61943f0d..ef046f49 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;