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 at amd.com>
> ---
> 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.
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
