[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Oded Gabbay]

On 03/12/2015 11:23 AM, Christian König wrote:
> On 12.03.2015 10:02, Michel Dänzer wrote:
>> On 12.03.2015 06:14, Alex Deucher wrote:
>>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>>>> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>>>> <deathsimple at vodafone.de> wrote:
>>>>> On 11.03.2015 16:44, Alex Deucher wrote:
>>>>>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>>>>>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>>>>>> uses the ttm bo size to determine when to select top down
>>>>>> allocation but since the ttm bo is not initialized yet the
>>>>>> check is always false.
>>>>>>
>>>>>> Noticed-by: Oded Gabbay <oded.gabbay at amd.com>
>>>>>> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
>>>>>> Cc: stable at vger.kernel.org
>>>>>
>>>>> And I was already wondering why the heck the BOs always made this
>>>>> ping/pong
>>>>> in memory after creation.
>>>>>
>>>>> Patch is Reviewed-by: Christian König <christian.koenig at amd.com>
>>>> And fixing that promptly broke VCE due to vram location requirements.
>>>> Updated patch attached.  Thoughts?
>>> And one more take to make things a bit more explicit for static kernel
>>> driver allocations.
>> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>> problem is really that some BOs are expected to be within a certain
>> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>> would be better to fix that by setting lpfn directly than indirectly via
>> RADEON_GEM_CPU_ACCESS.
> 
> Yeah, agree. We should probably try to find the root cause of this instead.
> 
> As far as I know VCE has no documented limitation on where buffers are
> placed (unlike UVD). So this is a bit strange. Are you sure that it isn't
> UVD which breaks here?
> 
> Regards,
> Christian.
I noticed this bug when trying to allocate very large BOs (385MB) from the
other side of VRAM.
However, even with this fix, the following scenario still fails:
1. Allocate BO of 385MB on VRAM with no CPU access.
2. Map it to VRAM
3. Allocate second BO of 385MB on VRAM with no CPU access

The last step fails as the ttm can't find a place to put this second BO. I
suspect the Top-Down thing isn't being respected at all by the
creation/pinning of BO.

I think that what happens is that the first BO is pinned right after the
first 256 MB, instead of pinning it at the end of the VRAM.
Then, when trying to create the second BO, there is no room for it, as there
is only 256MB before the first BO, and 383MB after the first BO.

I need to debug it further, but will probably only do that on Sunday.

	Oded

> 
>>
>>
>> Anyway, since this isn't the first bug which prevents
>> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
>> wonder if its performance impact should be re-evaluated. Lauri?
>>
>>
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel