Re: [RFC PATCH 0/6] Common preempt fences and semantics

["Christian König" <christian.koenig@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

Am 13.11.24 um 03:30 schrieb Matthew Brost:
> [SNIP]
>>>> If you're using gpuvm, just call drm_gpuvm_resv_add_fence. I assume AMD has a
>>>> similarly simple call.
>>> Nope, we try to avoid locking all BOs in the VM as hard as we can.
>>>
>> Why? Calling in to perform fence conversion shouldn't be all that
>> frequent and simplifies things.
>>
>> Also, it's likely that only a few locks are involved, as not too many
>> external BOs are mapped within a VM (i.e., most BOs share the VM's
>> dma-resv lock).

The most common use case are multi GPU systems which share a lot of data 
in a NUMA cluster.

This configuration has almost all BOs shared between GPUs making locking 
the whole VM a task with massive overhead which should be avoided as 
much as possible.

>>>> Now the ordering works inherently in dma-resv and the scheduler. e.g. No
>>>> need to track the last completion fences explictly in preempt fences.
>>> I really don't think that this is a good approach. Explicitly keeping the
>>> last completion fence in the pre-emption fence is basically a must have as
>>> far as I can see.
>>>
>>> The approach you take here looks like a really ugly hack to me.
>>>
>> Well, I have to disagree; it seems like a pretty solid, common design.

What you basically do is to move the responsibility to signal fences in 
the right order from the provider of the fences to the consumer of it.

Since we have tons of consumers of that stuff this is not even remotely 
a defensive design.

>>
>> Anyway, I think I have this more or less working. I want to run this by
>> the Mesa team a bit to ensure I haven't missed anything, and will likely
>> post something shortly after.
>>
>> We can discuss this more after I post and perhaps solicit other
>> opinions, weighing the pros and cons of the approaches here. I do think
>> they function roughly the same, so something commonly agreed upon would
>> be good. Sharing a bit of code, if possible, is always a plus too.

Well to make it clear that will never ever get a green light from my 
side as DMA-buf maintainer. What you suggest here is extremely fragile.

Why not simply wait for the pending completion fences as dependency for 
signaling preemption fences?

That should work for all drivers and is trivial to implement as far as I 
can see.

Regards,
Christian.

>>
>> Matt
>>
>>> Regards,
>>> Christian.
>>>

[-- Attachment #2: Type: text/html, Size: 4237 bytes --]