Am 17.07.2014 06:02, schrieb Michel Dänzer:
On 17.07.2014 02:26, Alex Deucher wrote:
Now that fallback to gtt is fixed for cpu access, we can
remove this limit.
Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
---
drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
index fdd189b..07a13c9 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -55,8 +55,11 @@ int radeon_gem_object_create(struct radeon_device *rdev, int size,
alignment = PAGE_SIZE;
}
- /* maximun bo size is the minimun btw visible vram and gtt size */
- max_size = min(rdev->mc.visible_vram_size, rdev->mc.gtt_size);
+ /* Maximum bo size is the gtt size since we use the gtt to handle
+ * vram to system pool migrations. We could probably remove this
+ * check altogether with a little additional work.
+ */
+ max_size = rdev->mc.gtt_size;
if (size > max_size) {
DRM_DEBUG("Allocation size %dMb bigger than %ldMb limit\n",
size >> 20, max_size >> 20);
A BO of size rdev->mc.gtt_size can never actually be bound to GTT,
because we have some pinned BOs in there. I think it's a bit
disingenuous to let userspace allocate a BO that can never actually be
used by the GPU. :)
The hack I attached to
https://bugs.freedesktop.org/show_bug.cgi?id=78717 has a start for
dealing with that. I was running that patch for a while and didn't
notice any bad effects from it.
Haven't looked at the patch yet, but can't we just go over all existing
allocations on PIN and figure out the largest free area and save that
value? I mean pinning of GTT memory happens rarely and mostly on system
startup.
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
