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
