On 9/27/26 19:13, Pravin Kumar Ravi wrote:
...
> (Bringing Rob's September 27 reply from the parallel thread
> CACSVV00oBPN=rw1yvbjnm2tmhuq+3iv84jkp4djqcnkrxcv...@mail.gmail.com/)
> Rob Clark <[email protected]> wrote:
>> So I'm just starting to think a bit about this, since it will be
>> potentially relevant when we implement fwsched for adreno..
>>
>> Do we really need anything more than some sort of dma_fence signaling
>> extension? Ie. signaling on the CPU remains exactly the same as
>> today, anything waiting on the CPU would see no change. But if both
>> exporter and importer support the same extension, that can be used to
>> extract extra information to pass to fw.
Yes, I completely agree to you Rob.
The existing uAPI is perfectly fine to handle this use case as far as I can see.
I mean it was designed in the first place to handle this, so that is not so
surprising.
>>
>> The fw might observe the fence getting signaled with lower latency,
>> but that's fine, there isn't really any guarantee (other than timeline
>> ordering) about the order that multiple waiters observe that the fence
>> is signaled. We've just pushed one of the waiters down to firmware,
>> that is all. Ie. something like
>>
>> rcu_read_lock();
>> if (fence->ops->signaling_ext &&
>> do_I_understand_this(fence->ops->signaling_ext)) {
>> fence->ops->get_magic_signaling_foo(fence, &magic);
>> ... pass magic to fw ...
>> } else {
>> ... same as before ...
>> }
>> rcu_read_unlock();
>>
>> If either the importer or exporter don't understand the same signaling
>> extension, everything works as before. For ex, external eGPU/dGPU
>> sharing with say the on-chip ISP. But if both do support it, the
>> signaling extension provides a way to extract whatever magic thing is
>> needed to do the wait in fw.
>>
>> BR,
>> -R
>>
>
> Hi Rob,
> For operations that already satisfy the dma_fence completion contract,
> this looks worth exploring.
>
> Christian, does this fit the case you described about known drivers,
> provided the participating drivers preserve the resource-lifetime
> and recovery guarantees?
Unfortunately not. The problem is that when you have HW specific signaling
paths between your devices you also need HW specific recovery methods.
So for example let's say we have device A and device B and A can notify B about
finished work using shared memory and an interrupt line.
Now let's also say we have a submission to device A which locks up, e.g. an
endless loop in a shader or corrupted video bitstream gets the FW stuck or....,
we somehow need to somehow unstuck submissions to device B.
When we have a CPU round trip for the signaling that isn't much of a problem
since we can pinpoint what submission was problematic and have per submission
timeouts etc...
But when you let the drivers talk directly with each other both submissions to
A and B become inter dependent and you might need stuff like inter device error
handling and resets.
That is a whole different beasts you are tackling here.
> Rob, could we have the shared signaling mechanism in an independent
> and generic synx_global.c layer? dma-fence can tap into this
> layer for the signaling extension you mentioned.
Well to be honest forget about your synx stuff. At least upstream I don't see
that flying at all and I strongly suggest to the issues we are pointing out
here into account for downstream as well.
You basically have repeated a lot of the mistakes we have already seen with
dma_fences and re-implementing it in a different kind of framework doesn't make
such problems go away.
The issue here is that your solution seems to work in testing for you but if
you have fundamental design issues similar to what I have pointed out so far
then that will sooner or later blow up in production use cases.
> The reason for keeping this layer independent is that we have clients
> who use reusable synx objects (signal same handle multiple times)
> which don't interop with dma-fence. And we continue to get more feature
> requirements from performance-critical clients around reusable objects
> with timelines. Assuming this is where global synchronization is headed,
> these clients should be able to tap into reusability via a route other than
> dma-fence.
Yeah that again is a complete no-go for upstreaming any of this.
That dma_fences are one time use and have clear state transitions was one of
the things which has proven to be mandatory for correct operation.
What is re-used in the uAPI are containers for dma_fences, e.g. sync_file and
drm_syncobj.
> For existing dma-fence operations, your extension could expose the
> information firmware needs for its wait, preserving CPU signaling
> and the fallback you described. Other clients could use the synx
> global layer under a separately defined resource-management contract.
> Would such layering address your use case while also supporting
> clients that need reusable remote synchronization?
Well what would be useful is a functionality so that multiple device drivers
can consume dma_fences by utilizing direct interconnects.
E.g. something device tree or dma_fence extension based so that device A and
device B can say "Hey I'm consuming your signals directly, please use this
interrupt line, memory address for polling or whatever functionality we share
and BTW this is the interface for error handling".
But non of this needs any new uAPI at all. That must all be inside the kernel
so that userspace can't mess with it.
Regards,
Christian.
>
> Thanks,
> Pravin
