[PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.

Christian König christian.koenig at amd.com
Fri Sep 25 07:39:30 UTC 2020


Am 25.09.20 um 01:14 schrieb Dave Airlie:
> On Thu, 24 Sep 2020 at 22:42, Christian König <christian.koenig at amd.com> wrote:
>> Am 24.09.20 um 07:18 schrieb Dave Airlie:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> All the accel moves do the same pattern here, provide a helper
>> And exactly that pattern I want to get away from.
> Currently this is just refactoring out the helper code in each driver, but I see
> since it calls bo_mem_space we are probably moving a bit in the wrong direction.

Exactly that's why I'm noting this.

>
>> See what happens if we (for example) have a VRAM -> SYSTEM move is the
>> following:
>>
>> 1. TTM allocates a new ttm_resource object in the SYSTEM domain.
>> 2. We call the driver to move from VRAM to SYSTEM.
>> 3. Driver finds that it can't do this and calls TTM  to allocate GTT.
>> 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to
>> SYSTEM and call driver again.
>>
>> This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we
>> should stop that immediately.
>>
>> My suggestion is that we rewrite how drivers call the ttm_bo_validate()
>> function so that we can guarantee that this never happens.
>>
>> What do you think?
> I think that is likely the next step I'd like to take after this
> refactor, it's a lot bigger, and I'm not sure how it will look yet.

Agree, yes. I have some ideas in mind for that, but not fully baked either.

> Do we envision the driver calling validate in a loop but when it can't
> find space it tells the driver and the driver does eviction and
> recalls validate?

Not in a loop, but more like in a chain.

My plan is something like this:
Instead of having "normal" and "busy" placement we have a flag in the 
context if evictions are allowed or not.
The call to ttm_bo_validate are then replaced with two calls, first 
without evictions and if that didn't worked one with evictions.

Then the normal validate sequence should look like this:
1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first 
with evictions=true.
2. If a BO should be in VRAM we then validate it to VRAM. If evictions 
are only allowed if the GEM flags say that GTT is not desired.

For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special 
domains that will obviously look a bit different.

Christian.

>
> Dave.



More information about the dri-devel mailing list