On Thu, Jul 17, 2014 at 10:28 AM, Christian König
<deathsimple@xxxxxxxxxxx> 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@xxxxxxx>
>>> ---
>>> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
