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

[Christian König]

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 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.

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.