path: root/drivers/gpu/drm/radeon/radeon_semaphore.c
diff options
authorChristian König <deathsimple@vodafone.de>2012-05-09 15:34:56 +0200
committerDave Airlie <airlied@redhat.com>2012-05-09 17:22:39 +0100
commitc3b7fe8b8a0b717f90a4a0c49cffae27e46e3fb7 (patch)
treead2756cf15f8986f7e41f3470c0bd60b30397cde /drivers/gpu/drm/radeon/radeon_semaphore.c
parent0085c95061e836f3ed489d042b502733c094e7e4 (diff)
drm/radeon: multiple ring allocator v3
A startover with a new idea for a multiple ring allocator. Should perform as well as a normal ring allocator as long as only one ring does somthing, but falls back to a more complex algorithm if more complex things start to happen. We store the last allocated bo in last, we always try to allocate after the last allocated bo. Principle is that in a linear GPU ring progression was is after last is the oldest bo we allocated and thus the first one that should no longer be in use by the GPU. If it's not the case we skip over the bo after last to the closest done bo if such one exist. If none exist and we are not asked to block we report failure to allocate. If we are asked to block we wait on all the oldest fence of all rings. We just wait for any of those fence to complete. v2: We need to be able to let hole point to the list_head, otherwise try free will never free the first allocation of the list. Also stop calling radeon_fence_signalled more than necessary. v3: Don't free allocations without considering them as a hole, otherwise we might lose holes. Also return ENOMEM instead of ENOENT when running out of fences to wait for. Limit the number of holes we try for each ring to 3. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'drivers/gpu/drm/radeon/radeon_semaphore.c')
0 files changed, 0 insertions, 0 deletions