[PATCH] drm/amdgpu: Place new CPU-accessbile BOs in GTT if visible VRAM is full

Michel Dänzer michel at daenzer.net
Mon May 22 01:30:42 UTC 2017


On 20/05/17 12:21 PM, John Brooks wrote:
> On Sat, May 20, 2017 at 10:27:14AM +0900, Michel Dänzer wrote:
>> On 20/05/17 04:23 AM, John Brooks wrote:
>>> On Fri, May 19, 2017 at 04:03:28PM +0900, Michel Dänzer wrote:
>>>> On 19/05/17 12:04 PM, John Brooks wrote:
>>>>> Set GTT as the busy placement for newly created BOs that have the
>>>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag, so that they don't cause
>>>>> established BOs to be evicted from visible VRAM.
>>>>
>>>> This is an interesting idea, but there are some issues with this patch.
>>
>> [...]
>>
>>>>> +	    flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
>>>>> +		bo->placement.num_placement = 1;
>>>>> +		bo->placement.num_busy_placement = 1;
>>>>> +		bo->placement.busy_placement = &bo->placement.placement[1];
>>>>> +	}
>>>>
>>>> The original placements set by amdgpu_fill_placement_to_bo need to be
>>>> restored before returning from this function, otherwise I suspect such
>>>> BOs which end up being created in GTT will stay there permanently.
>>>>
>>>
>>> I'm curious, what makes you think that the BOs cannot move back to VRAM
>>> otherwise? VRAM is still in the placements and prefered/allowed domains, just
>>> not in the busy placements.
>>
>> If there is not enough free space when the BO is created, there probably
>> won't be either when it's validated for GPU command streams later.
>>
>>
>>>> Does the patch still help for Dying Light if you fix this?
>>
>> Please test this. The result should tell us whether the problem with
>> Dying Light is really pressure on CPU visible VRAM, or something else.
>>
> 
> I did some tests. The patch still helps if I restore the old placement values
> after ttm_bo_init_reserved. But while doing this, I made another observation
> that throws a wrench into things: It *does* kill performance if I remove
> AMDGPU_GEM_DOMAIN_GTT from bo->prefered_domains. I think that GTT getting into
> prefered_domains was what "fixed" the game this whole time and the BO creation
> was irrelevant.

Ah, right, so the problem I was thinking of was actually caused by the
second hunk, not the first one. :) amdgpu_cs_bo_validate re-generates
the placements for each command stream according to bo->prefered_domains
or bo->allowed_domains.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the amd-gfx mailing list