On 3/27/2025 2:54 PM, Christian König wrote:
Over all this change doesn't seem to make much sense to me.
Why exactly is isolation->spearhead not pointing to the dummy kernel job we
submit?
Does the owner check or gang_submit check in
amdgpu_device_enforce_isolation() fail to set up the spearhead?
I'm currently debugging exactly that.
Good news is that I can reproduce the problem.
I have to take that back. I've tested the cleaner shader functionality
a bit this morning and as far as I can see this works exactly as intended.
Srini, what exactly is your use case which doesn't work?
Hi Christian, Good Morning!
The usecase is to trigger the cleaner shader, using sysfs
"run_cleaner_shader" independent of enabling "enforce_isolation", so
that cleaner shader packet gets submitted to COMP_1.0.0 ring by default,
without prior enabling any enforce_isolation via sysfs,
AFAIK, this "isolation->spearhead" initialization is not being takencare
in this *path **"amdgpu_gfx_run_cleaner_shader ->
amdgpu_gfx_run_cleaner_shader_job" (ie., when we trigger *cleaner
shader, using sysfs "run_cleaner_shader"), and this check
"*&job->base.s_fence->scheduled == isolation->spearhead;" * is having
the problem ie., "*&job->base.s_fence->scheduled" address are is not
matching with**"**isolation->spearhead" address, which results into zero
& thus fails to emit cleaner shader, when running using
"run_cleaner_shader" sysfs entry, **in "amdgpu_vm_flush()" function
*
Best regards,
Srini
Regards,
Christian.
Regards,
Christian.
