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

[Christian König]

Am 17.07.2014 18:29, schrieb Alex Deucher:
> On Thu, Jul 17, 2014 at 10:28 AM, Christian König
> <deathsimple at vodafone.de> wrote:
>> 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.
>
> How about that attached patches?

LGTM. My thinking was more complicated, but this should be fine as well.

Patches are: Reviewed-by: Christian König <christian.koenig at amd.com>

Christian.

>
> Alex