RFC TTM priority queue logic

Lauri Kasanen dri-devel 1 version Apr 4, 2014 In review

Get series with b4

b4 am [email protected]

Versions newest first

v1 RFC Latest Apr 4, 20143 patches 4 repliesIn review

Patches in v1 No applies recorded yet

#	Subject and files	Size	Replies
1/3	drm/ttm: Add a priority queue`drivers/gpu/drm/ttm/Makefile` `drivers/gpu/drm/ttm/ttm_priority.c` `include/drm/ttm/ttm_priority.h`	+243 -1	0 replies
2/3	drm/ttm: Add the priority queue to appropriate structs`drivers/gpu/drm/ast/ast_ttm.c` `drivers/gpu/drm/bochs/bochs_mm.c` `drivers/gpu/drm/cirrus/cirrus_ttm.c` +8 more	+19 -3	0 replies
3/3	drm/ttm: Enable the priority queue for VRAM`drivers/gpu/drm/ttm/ttm_bo.c`	+54 ~~-14~~	0 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC 0/3] TTM priority queue logic

Hi list, Thomas,

I'd like to know if this is going in the right direction.

I've implemented a priority queue on top of the kernel rb tree and linked list. It's been tested well in userspace.

I hardcoded radeon to input the buffer size as the score. Nothing blew up, games ran fine, and even got ~2% more fps on average*.

The only thing missing from this code is the "if score is too low, and there is no room without eviction, tell driver so" logic.

- Lauri

* This is a fairly bad strategy, and according to my simulator achieves 16% worse results compared to LRU in heavier situations. The games tested here all fit in VRAM, which should explain the improvement.

Read the cover letter in its thread