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

Alex Deucher alexdeucher at gmail.com
Thu Jul 17 08:49:49 PDT 2014


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.

yeah, I had the same thought.

Alex


More information about the dri-devel mailing list