i965/bufmgr: Garbage-collect vma cache/pruning

This was done because the kernel has 1 global address space, shared
with all render clients, for gtt mmap offsets, and that address space
was only 32bit on 32bit kernels.

This was fixed  in

commit 440fd5283a87345cdd4237bdf45fb01130ea0056
Author: Thierry Reding <[email protected]>
Date:   Fri Jan 23 09:05:06 2015 +0100

    drm/mm: Support 4 GiB and larger ranges

which shipped in 4.0. Of course you still want to limit the bo cache
to a reasonable size on 32bit apps to avoid ENOMEM, but that's better
solved by tuning the cache a bit. On 64bit, this was never an issue.

On top, mesa never set this, so it's all dead code. Collect an trash it.

Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>

1 files changed, 0 insertions, 3 deletions

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index 1d3404c3bf2..fee963129ce 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -119,7 +119,6 @@ struct brw_bo {
    /** WC CPU address for the buffer, saved across map/unmap cycles */
    void *wc_virtual;
    int map_count;
-   struct list_head vma_list;
 
    /** BO cache list */
    struct list_head head;
@@ -253,8 +252,6 @@ struct brw_bo *brw_bo_gem_create_from_name(struct brw_bufmgr *bufmgr,
                                            const char *name,
                                            unsigned int handle);
 void brw_bufmgr_enable_reuse(struct brw_bufmgr *bufmgr);
-void brw_bufmgr_gem_set_vma_cache_size(struct brw_bufmgr *bufmgr,
-                                       int limit);
 int brw_bo_map_unsynchronized(struct brw_bo *bo);
 int brw_bo_map_gtt(struct brw_bo *bo);