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

Christian König deathsimple at vodafone.de
Thu Mar 12 02:23:51 PDT 2015


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.

>
>
> 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?
>
>



More information about the dri-devel mailing list