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.
On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
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
Lauri, I'm out of the office until monday, I'll take a look then. Thanks,
Thomas
Hi, Lauri.
On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
Hi list, Thomas,
I'd like to know if this is going in the right direction.
This looks fine with me.
However, if possible I'd like the drivers to enable both alloc_threshold and priority queue on a per-memory-type basis.
That would mean no new arguments (use_pqueue, alloc_threshold) in ttm_bo_device_init(). Instead, set default values in ttm_bo_init_mm(), and let the driver change them in the init_mem_type() callback.
Do you think that would work?
/Thomas
On Mon, 07 Apr 2014 14:25:28 +0200 Thomas Hellstrom thellstrom@vmware.com wrote:
Hi, Lauri.
On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
Hi list, Thomas,
I'd like to know if this is going in the right direction.
This looks fine with me.
However, if possible I'd like the drivers to enable both alloc_threshold and priority queue on a per-memory-type basis.
That would mean no new arguments (use_pqueue, alloc_threshold) in ttm_bo_device_init(). Instead, set default values in ttm_bo_init_mm(), and let the driver change them in the init_mem_type() callback.
Do you think that would work?
Thanks for the review.
Alloc_threshold was removed, and the current patch (in drm-next) replaced it with a placement flag. So now that logic is in the driver.
Making the pqueue a per-type option would certainly work, I'll edit it to do so. I don't see why it would improve GTT or SYSTEM given their perf characteristics, but I suppose future devices can always do weird things.
- Lauri
On 04/07/2014 04:39 PM, Lauri Kasanen wrote:
On Mon, 07 Apr 2014 14:25:28 +0200 Thomas Hellstrom thellstrom@vmware.com wrote:
Hi, Lauri.
On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
Hi list, Thomas,
I'd like to know if this is going in the right direction.
This looks fine with me.
However, if possible I'd like the drivers to enable both alloc_threshold and priority queue on a per-memory-type basis.
That would mean no new arguments (use_pqueue, alloc_threshold) in ttm_bo_device_init(). Instead, set default values in ttm_bo_init_mm(), and let the driver change them in the init_mem_type() callback.
Do you think that would work?
Thanks for the review.
Alloc_threshold was removed, and the current patch (in drm-next) replaced it with a placement flag. So now that logic is in the driver.
Making the pqueue a per-type option would certainly work, I'll edit it to do so. I don't see why it would improve GTT or SYSTEM given their perf characteristics, but I suppose future devices can always do weird things.
Yes. You don't have to explicitly check for VRAM, and drivers can also set up other fixed memory types, like a pre-allocated chunk of GTT.
Thanks, Thomas
- Lauri
dri-devel@lists.freedesktop.org
-
Lauri Kasanen -
Thomas Hellstrom