The previous approach gave a sort of round-robin behavior which made
sense because we didn't want to walk the entire list looking for the
first idle BO. Now that everything is idle, we can pick any BO in the
list and it should be fine. Using the most recently used BO should give
us less over-all thrash than the round-robin because we will be trying
to re-use BOs as much as possible.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index ef918315c65..02aea435e84 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -539,14 +539,10 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
retry:
alloc_from_cache = false;
if (bucket != NULL && !list_empty(&bucket->head)) {
- /* For non-render-target BOs (where we're probably
- * going to map it first thing in order to fill it
- * with data), check if the last BO in the cache is
- * unbusy, and only reuse in that case. Otherwise,
- * allocating a new buffer is probably faster than
- * waiting for the GPU to finish.
+ /* Allocate BOs from the tail (MRU) of the list as it will likely be
+ * hotter in the GPU cache and in the aperature for us.
*/
- bo = LIST_ENTRY(struct brw_bo, bucket->head.next, head);
+ bo = LIST_ENTRY(struct brw_bo, bucket->head.prev, head);
assert(!brw_bo_busy(bo));
alloc_from_cache = true;
--
2.17.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
