OSDN Git Service

i965/bufmgr: Garbage-collect vma cache/pruning
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Thu, 6 Apr 2017 06:48:08 +0000 (08:48 +0200)
committerKenneth Graunke <kenneth@whitecape.org>
Mon, 10 Apr 2017 21:33:18 +0000 (14:33 -0700)
commit7f3c85c21e0e18bbedb2f59ba13838d963f0a106
tree1dbc8d7028b1c1cf458da156da2333a99a17c1b7
parent1f965d3f7ac309f519b0216a8a916cda5cb5d1e3
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 <treding@nvidia.com>
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 <daniel.vetter@ffwll.ch>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
src/mesa/drivers/dri/i965/brw_bufmgr.c
src/mesa/drivers/dri/i965/brw_bufmgr.h