[PATCH v1] drm/amdgpu: give each kernel job a unique id

[Pierre-Eric Pelloux-Prayer]

Le 13/06/2025 à 10:35, Danilo Krummrich a écrit :
> On Fri, Jun 13, 2025 at 10:23:15AM +0200, Christian König wrote:
>>> Another option is to just add an interface to get a kernel client_id from the
>>> same atomic / IDA.
>>
>> That won't give us fixed numbers for in kernel clients.
> 
> That's fine, then let's come up with an API that reserves fixed numbers.
> 
> My main concern is that drivers silently rely on DRM API internals, i.e. that
> client_id is an u64 atomic, etc.

Let me express the need then: an id that is printed in gpu_scheduler_trace events and this id needs 
to be mappable by a userspace tool to a semantic.

The current solution implements this need using:
* fixed ids which are u64 numbers because drm client id are u64.
* hard-coded mapping in the tool between these ids and their meaning ("u64_max - 1" interpreted as 
"vm_update" and so on).

It doesn't depend on how drm internally manage these ids.

Adding an API to reserve fixed numbers would work but:
* if the fixed numbers are chosen by the driver ("drm_reserve_id(u64_max -1)"), I don't see the 
benefit over the current patch
* if the fixed numbers are allocated by drm (drm_reserve_id("vm_update") -> u64), it would then 
require a way to expose them to userspace (through /sys/kernel/debug/dri/x/clients?)


Thanks,
Pierre-Eric