[PATCH] drm/radeon: remove visible vram size limit on bo allocation

Michel Dänzer michel at daenzer.net
Wed Jul 16 21:02:47 PDT 2014


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


More information about the dri-devel mailing list