[PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Philipp Stanner]

dma_fence's backend_ops functions ops->wait() and ops->release() are
problematic because they prevent fence producers from unloading.
Moreover, they can easily be implemented through simpler means more
aligned with the dma_fence contract.

Since the declared goal of dma_fence is to move towards an
implementation that supports driver-unload in all circumstances, we must
prevent more parties from implementing those callbacks.

Deprecate ops->release() and ops->wait() and document what users should
do instead.

Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
 include/linux/dma-fence.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index dd07d128adc3..59af0159cd25 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -220,6 +220,8 @@ struct dma_fence_ops {
 	/**
 	 * @wait:
 	 *
+	 * DEPRECATED!
+	 *
 	 * Custom wait implementation, defaults to dma_fence_default_wait() if
 	 * not set.
 	 *
@@ -236,6 +238,10 @@ struct dma_fence_ops {
 	 * Implementing this callback prevents the fence from detaching after
 	 * signaling and so it is necessary for the module providing the
 	 * dma_fence_ops to stay loaded as long as the dma_fence exists.
+	 *
+	 * Deprecated for the reason mentioned above. No new users must be
+	 * implemented. Consumers of a fence can instead notify themselves by
+	 * registering a callback on the fence.
 	 */
 	signed long (*wait)(struct dma_fence *fence,
 			    bool intr, signed long timeout);
@@ -243,6 +249,8 @@ struct dma_fence_ops {
 	/**
 	 * @release:
 	 *
+	 * DEPRECATED!
+	 *
 	 * Called on destruction of fence to release additional resources.
 	 * Can be called from irq context.  This callback is optional. If it is
 	 * NULL, then dma_fence_free() is instead called as the default
@@ -254,6 +262,12 @@ struct dma_fence_ops {
 	 *
 	 * If the callback is implemented the memory backing the dma_fence
 	 * object must be freed RCU safe.
+	 *
+	 * Deprecated because it prevents the producer of a fence from
+	 * unloading. No new users must be implemented. Parties with a
+	 * hypothetical need for this callback can instead simply and directly
+	 * perform their custom release operations one RCU grace period after
+	 * they have signaled the fence.
 	 */
 	void (*release)(struct dma_fence *fence);
 

base-commit: 2302669bb4b52d581cc2589b90b3af7bb3783a28
-- 
2.55.0

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Christian König]

On 9/23/26 17:03, Philipp Stanner wrote:
> dma_fence's backend_ops functions ops->wait() and ops->release() are
> problematic because they prevent fence producers from unloading.
> Moreover, they can easily be implemented through simpler means more
> aligned with the dma_fence contract.
> 
> Since the declared goal of dma_fence is to move towards an
> implementation that supports driver-unload in all circumstances, we must
> prevent more parties from implementing those callbacks.
> 
> Deprecate ops->release() and ops->wait() and document what users should
> do instead.
> 
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
> ---
>  include/linux/dma-fence.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index dd07d128adc3..59af0159cd25 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -220,6 +220,8 @@ struct dma_fence_ops {
>  	/**
>  	 * @wait:
>  	 *
> +	 * DEPRECATED!
> +	 *
>  	 * Custom wait implementation, defaults to dma_fence_default_wait() if
>  	 * not set.
>  	 *
> @@ -236,6 +238,10 @@ struct dma_fence_ops {
>  	 * Implementing this callback prevents the fence from detaching after
>  	 * signaling and so it is necessary for the module providing the
>  	 * dma_fence_ops to stay loaded as long as the dma_fence exists.
> +	 *
> +	 * Deprecated for the reason mentioned above. No new users must be
> +	 * implemented.

>	Consumers of a fence can instead notify themselves by
> +	 * registering a callback on the fence.

Mhm, the wait callback is transparent to consumers it's just that implementations used it for quite a number of different hacks.

I would just drop that sentence.

>  	 */
>  	signed long (*wait)(struct dma_fence *fence,
>  			    bool intr, signed long timeout);
> @@ -243,6 +249,8 @@ struct dma_fence_ops {
>  	/**
>  	 * @release:
>  	 *
> +	 * DEPRECATED!
> +	 *
>  	 * Called on destruction of fence to release additional resources.
>  	 * Can be called from irq context.  This callback is optional. If it is
>  	 * NULL, then dma_fence_free() is instead called as the default
> @@ -254,6 +262,12 @@ struct dma_fence_ops {
>  	 *
>  	 * If the callback is implemented the memory backing the dma_fence
>  	 * object must be freed RCU safe.
> +	 *
> +	 * Deprecated because it prevents the producer of a fence from
> +	 * unloading. No new users must be implemented. Parties with a
> +	 * hypothetical need for this callback can instead simply and directly
> +	 * perform their custom release operations one RCU grace period after
> +	 * they have signaled the fence.

Yeah that is a bit problematic.

We need my patch set to explicit signal fences instead of returning true/false from callback for that so that a backend can properly implement this.

It's on my TODO list, but not the highest priority at the moment.

Regards,
Christian.
>  	 */
>  	void (*release)(struct dma_fence *fence);
>  
> 
> base-commit: 2302669bb4b52d581cc2589b90b3af7bb3783a28

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Philipp Stanner]

On Wed, 2026-09-23 at 17:13 +0200, Christian König wrote:
> On 9/23/26 17:03, Philipp Stanner wrote:
> > 

[…]

> 
> > 	Consumers of a fence can instead notify themselves by
> > +	 * registering a callback on the fence.
> 
> Mhm, the wait callback is transparent to consumers it's just that implementations used it for quite a number of different hacks.

Right…

but doesn't the question then become why dma_fence_wait_timeout() even
exists? IOW, shall we deprecate it, too?

It seems to be a reimplementation of waitqueues. The driver could get
this functionality by using a waitqueue whose event gets triggered by a
fence callback.

dma_fence_default_wait() interacts directly with the task state with
__XX_task() functions which looks very.. deep to me :)

> 
> I would just drop that sentence.
> 
> >  	 */
> >  	signed long (*wait)(struct dma_fence *fence,
> >  			    bool intr, signed long timeout);
> > @@ -243,6 +249,8 @@ struct dma_fence_ops {
> >  	/**
> >  	 * @release:
> >  	 *
> > +	 * DEPRECATED!
> > +	 *
> >  	 * Called on destruction of fence to release additional resources.
> >  	 * Can be called from irq context.  This callback is optional. If it is
> >  	 * NULL, then dma_fence_free() is instead called as the default
> > @@ -254,6 +262,12 @@ struct dma_fence_ops {
> >  	 *
> >  	 * If the callback is implemented the memory backing the dma_fence
> >  	 * object must be freed RCU safe.
> > +	 *
> > +	 * Deprecated because it prevents the producer of a fence from
> > +	 * unloading. No new users must be implemented. Parties with a
> > +	 * hypothetical need for this callback can instead simply and directly
> > +	 * perform their custom release operations one RCU grace period after
> > +	 * they have signaled the fence.
> 
> Yeah that is a bit problematic.
> 
> We need my patch set to explicit signal fences instead of returning true/false from callback for that so that a backend can properly implement this.

Well, what I'm trying to say in this docu is that the driver can kick
off custom operations that shall be performed once everyone is "done"
with the fence after signaling it. Any driver data that might still be
around cannot be accessed by fence consumers after signaling anymore.
So the driver could trigger cleanup work after a graceperiod, as long
as it does not involve kfree()-ing the fence itself.


P.

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Christian König]

On 9/23/26 17:27, Philipp Stanner wrote:
> On Wed, 2026-09-23 at 17:13 +0200, Christian König wrote:
>> On 9/23/26 17:03, Philipp Stanner wrote:
>>>
> 
> […]
> 
>>
>>> 	Consumers of a fence can instead notify themselves by
>>> +	 * registering a callback on the fence.
>>
>> Mhm, the wait callback is transparent to consumers it's just that implementations used it for quite a number of different hacks.
> 
> Right…
> 
> but doesn't the question then become why dma_fence_wait_timeout() even
> exists? IOW, shall we deprecate it, too?

Yes, without the wait callback it is only a wrapper to block the current thread for a dma_fence to signal using a callback.

It's still quite useful to have a common function for that I think.

> It seems to be a reimplementation of waitqueues. The driver could get
> this functionality by using a waitqueue whose event gets triggered by a
> fence callback.
> 
> dma_fence_default_wait() interacts directly with the task state with
> __XX_task() functions which looks very.. deep to me :)

That is *exactly* what I pointed out as well >10 years ago before that stuff was merged upstream :)

A wait_event based implementation would be tons of cleaner if you ask me.

>>
>> I would just drop that sentence.
>>
>>>  	 */
>>>  	signed long (*wait)(struct dma_fence *fence,
>>>  			    bool intr, signed long timeout);
>>> @@ -243,6 +249,8 @@ struct dma_fence_ops {
>>>  	/**
>>>  	 * @release:
>>>  	 *
>>> +	 * DEPRECATED!
>>> +	 *
>>>  	 * Called on destruction of fence to release additional resources.
>>>  	 * Can be called from irq context.  This callback is optional. If it is
>>>  	 * NULL, then dma_fence_free() is instead called as the default
>>> @@ -254,6 +262,12 @@ struct dma_fence_ops {
>>>  	 *
>>>  	 * If the callback is implemented the memory backing the dma_fence
>>>  	 * object must be freed RCU safe.
>>> +	 *
>>> +	 * Deprecated because it prevents the producer of a fence from
>>> +	 * unloading. No new users must be implemented. Parties with a
>>> +	 * hypothetical need for this callback can instead simply and directly
>>> +	 * perform their custom release operations one RCU grace period after
>>> +	 * they have signaled the fence.
>>
>> Yeah that is a bit problematic.
>>
>> We need my patch set to explicit signal fences instead of returning true/false from callback for that so that a backend can properly implement this.
> 
> Well, what I'm trying to say in this docu is that the driver can kick
> off custom operations that shall be performed once everyone is "done"
> with the fence after signaling it. Any driver data that might still be
> around cannot be accessed by fence consumers after signaling anymore.
> So the driver could trigger cleanup work after a graceperiod, as long
> as it does not involve kfree()-ing the fence itself.

That sounds sane to me, but I'm not sure how to phrase it cleaner either.

For now I'm ok with it, maybe somebody else has a better idea to how write this.

Thanks,
Christian.

> 
> 
> P.

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Philipp Stanner]

On Wed, 2026-09-23 at 17:35 +0200, Christian König wrote:
> On 9/23/26 17:27, Philipp Stanner wrote:
> > On Wed, 2026-09-23 at 17:13 +0200, Christian König wrote:
> > > On 9/23/26 17:03, Philipp Stanner wrote:
> > > > 
> > 
> > […]
> > 
> > > 
> > > > 	Consumers of a fence can instead notify themselves by
> > > > +	 * registering a callback on the fence.
> > > 
> > > Mhm, the wait callback is transparent to consumers it's just that
> > > implementations used it for quite a number of different hacks.
> > 
> > Right…
> > 
> > but doesn't the question then become why dma_fence_wait_timeout() even
> > exists? IOW, shall we deprecate it, too?
> 
> Yes, without the wait callback it is only a wrapper to block the
> current thread for a dma_fence to signal using a callback.

I agree that it's probably quite a common use-case. I'm not sure
whether it's possible to write a convenient wrapper, though, since you
need to carry a waitqueue around.

Maybe we can put a task for it onto the DRM TODO list?

> 
> It's still quite useful to have a common function for that I think.
> 
> > It seems to be a reimplementation of waitqueues. The driver could get
> > this functionality by using a waitqueue whose event gets triggered by a
> > fence callback.
> > 
> > dma_fence_default_wait() interacts directly with the task state with
> > __XX_task() functions which looks very.. deep to me :)
> 
> That is *exactly* what I pointed out as well >10 years ago before that stuff was merged upstream :)
> 
> A wait_event based implementation would be tons of cleaner if you ask me.

So you objected and it was merged anyways? With any rationale?

I think I understand now why sometimes people apply a Nacked-by, so
that it's documented that people objected against merging.

[…]

> > 
> > 
> > Well, what I'm trying to say in this docu is that the driver can kick
> > off custom operations that shall be performed once everyone is "done"
> > with the fence after signaling it. Any driver data that might still be
> > around cannot be accessed by fence consumers after signaling anymore.
> > So the driver could trigger cleanup work after a graceperiod, as long
> > as it does not involve kfree()-ing the fence itself.
> 
> That sounds sane to me, but I'm not sure how to phrase it cleaner either.
> 
> For now I'm ok with it, maybe somebody else has a better idea to how write this.

I try to come up with something slightly better.


P.

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Christian König]

On 9/24/26 10:14, Philipp Stanner wrote:
> On Wed, 2026-09-23 at 17:35 +0200, Christian König wrote:
>> On 9/23/26 17:27, Philipp Stanner wrote:
>>> On Wed, 2026-09-23 at 17:13 +0200, Christian König wrote:
>>>> On 9/23/26 17:03, Philipp Stanner wrote:
>>>>>
>>>
>>> […]
>>>
>>>>
>>>>> 	Consumers of a fence can instead notify themselves by
>>>>> +	 * registering a callback on the fence.
>>>>
>>>> Mhm, the wait callback is transparent to consumers it's just that
>>>> implementations used it for quite a number of different hacks.
>>>
>>> Right…
>>>
>>> but doesn't the question then become why dma_fence_wait_timeout() even
>>> exists? IOW, shall we deprecate it, too?
>>
>> Yes, without the wait callback it is only a wrapper to block the
>> current thread for a dma_fence to signal using a callback.
> 
> I agree that it's probably quite a common use-case. I'm not sure
> whether it's possible to write a convenient wrapper, though, since you
> need to carry a waitqueue around.
> 
> Maybe we can put a task for it onto the DRM TODO list?

Maybe, but I'm not even sure if that is even possible/doable/make sense now.

A dma_fence is indeed very similar to a waitqueue, but with different locking semantics (at least at the moment) and different callbacks etc...

All of that is changeable, e.g. no uAPI dependencies, but also rather tricky to do because a lot of different components are involved.

On the other hand that code now works, it is just quite awkward to re-implement more or less the same functionality as a workqueue.
>>
>> It's still quite useful to have a common function for that I think.
>>
>>> It seems to be a reimplementation of waitqueues. The driver could get
>>> this functionality by using a waitqueue whose event gets triggered by a
>>> fence callback.
>>>
>>> dma_fence_default_wait() interacts directly with the task state with
>>> __XX_task() functions which looks very.. deep to me :)
>>
>> That is *exactly* what I pointed out as well >10 years ago before that stuff was merged upstream :)
>>
>> A wait_event based implementation would be tons of cleaner if you ask me.
> 
> So you objected and it was merged anyways? With any rationale?

Well not quite, I didn't explicitly NAKed it.

I just pointed out the different problems I saw, but at that time nobody (including me) expected that I was Nostradamus foretelling the future and putting the finger on exactly what we have forgotten to take into account.

A good bunch of the issues have been fixed over the years. Especially the dma_fence today is way more resilient to coding errors it was in the beginning, we basically had random memory corruptions all over the place because of avoidable driver bugs.

Some problems like the locking design are still WIP, but we are slowly moving towards that.

But some problems like parts of the dma_fence uAPI are unfixable without time travel.

> I think I understand now why sometimes people apply a Nacked-by, so
> that it's documented that people objected against merging.

Well I rather learned that I should take all concerns into account and explicitly say NAK when I see something fundamentally problematic which can't be fixed later on.

Regards,
Christian.

> 
> […]
> 
>>>
>>>
>>> Well, what I'm trying to say in this docu is that the driver can kick
>>> off custom operations that shall be performed once everyone is "done"
>>> with the fence after signaling it. Any driver data that might still be
>>> around cannot be accessed by fence consumers after signaling anymore.
>>> So the driver could trigger cleanup work after a graceperiod, as long
>>> as it does not involve kfree()-ing the fence itself.
>>
>> That sounds sane to me, but I'm not sure how to phrase it cleaner either.
>>
>> For now I'm ok with it, maybe somebody else has a better idea to how write this.
> 
> I try to come up with something slightly better.
> 
> 
> P.

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Philipp Stanner]

On Fri, 2026-09-25 at 10:21 +0200, Christian König wrote:
> Some problems like the locking design are still WIP, but we are
> slowly moving towards that.

The question will be whether we can reach common ground with that one.

> 
> But some problems like parts of the dma_fence uAPI are unfixable
> without time travel.

I would be especially interested in learning about who the party is
that apparently is spinning on dma_fence_is_signaled(), supposedly
preventing us from getting the memory ordering right.

Also learning more about the users that definitely *need* ops-
>signaled() and ops->enable_signaling() would be interesting. drm_sched
users cannot make use of these, since the sched-fence does not pass the
request through to the hardware fence.

So who are the users? Parties like Nouveau implement these callbacks,
but it's not clear whether they actually need them.

(btw, funnily enough, with the Rust-fence design we finally have the
ability to fully support all callbacks with or without a scheduler,
since the need for an intermediate fence disappeared)


P.

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Christian König]

On 9/25/26 10:42, Philipp Stanner wrote:
> On Fri, 2026-09-25 at 10:21 +0200, Christian König wrote:
>> Some problems like the locking design are still WIP, but we are
>> slowly moving towards that.
> 
> The question will be whether we can reach common ground with that one.

I haven't had a chance to look into your alternative to using RCU, but you mentioned that you found a solution to the problem on the RUST side so it sounded to me that we at least have a path forward.

>>
>> But some problems like parts of the dma_fence uAPI are unfixable
>> without time travel.
> 
> I would be especially interested in learning about who the party is
> that apparently is spinning on dma_fence_is_signaled(), supposedly
> preventing us from getting the memory ordering right.

Well there isn't spinning on it. It's just that in a SMP system it takes some time for state to transfer between CPU cores and that communication channel often becomes a bottleneck.

By implementing the is_signaled callback you avoid that device->CPU core A->CPU core B signaling making things much more responsive.

Even on ancient drivers like radeon people start to complain when the is_signaled callback is removed, so it is definitely necessary.
> Also learning more about the users that definitely *need* ops-
>> signaled() and ops->enable_signaling() would be interesting. drm_sched
> users cannot make use of these, since the sched-fence does not pass the
> request through to the hardware fence.
> 
> So who are the users? Parties like Nouveau implement these callbacks,
> but it's not clear whether they actually need them.

The eviction fence and KFD fence in amdgpu as well as the preemption fence in XE and i915 depend on that to note whenever somebody starts depending on the fence.

Additional to that I just last week have talked with some Qualcomm folks who desperately want device to device signaling without waking up the CPU. The enabling_signaling callback is necessary for that as well.

For Nouveau I think that it is pretty much pointless to implement those callbacks, but I'm not 100% sure.

Regards,
Christian.

> 
> (btw, funnily enough, with the Rust-fence design we finally have the
> ability to fully support all callbacks with or without a scheduler,
> since the need for an intermediate fence disappeared)
> 
> 
> P.

Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

[Philipp Stanner]

+Cc Danilo

On Tue, 2026-09-29 at 15:32 +0200, Christian König wrote:
> On 9/25/26 10:42, Philipp Stanner wrote:
> > On Fri, 2026-09-25 at 10:21 +0200, Christian König wrote:
> > > Some problems like the locking design are still WIP, but we are
> > > slowly moving towards that.
> > 
> > The question will be whether we can reach common ground with that
> > one.
> 
> I haven't had a chance to look into your alternative to using RCU,

That was just a nasty, still half broken RFC that doesn't really work
(yet), just to see how the rough idea might resonate.

Basically, I think that at the heart of fence's problems are these
issues:

a) fence and fence_context can share a lock
b) thus, the driver often protects driver data with that lock
c) drivers now are allowed to take the fence-lock manually
d) thus, the fence-state cannot consistently be protected with the lock

The fundamental problems were IMO worked around with RCU.

I think if we re-designed dma_fence today, we would do it like that:

a) each fence has its own lock
b) the driver cannot (legally) access a fence-lock
c) the entire fence state is protected by the lock
d) the fence lifetime is completely covered by refcounting
e) signaling is the decoupling point. Signaled-state is guarded by the lock
f) fence->ops access is, through the signaled-state guard, also guarded by the lock.
g) all fence API functions are locking-atomic. For example,
   dme_fence_set_error() should not exist, but dma_fence_signal(err)
   should take the code and do all operations while holding the
   lock.

If the driver can never take the lock, then there cannot be a lock
inversion (unless the driver would signal while holding its own lock,
which should be avoidable).


So my idea would have been that, similarly to how you added the
inline_lock a year ago, we add another super_lock to dma_fence, which
is always present, for all users.

We could then add this lock as a second locking layer around the
existing inline / shared lock and implement the rules listed above with
it.

This is just a crazy idea – it's obviously horribly dangerous and
fragile because of locking order. So I'm not sure if it's worth
exploring further.

But if we had a time-machine I think that's what we would tell
ourselves to do.


> but you mentioned that you found a solution to the problem on the
> RUST side so it sounded to me that we at least have a path forward.

In Rust we just obey 100% to the current dma_fence contract. We do use
RCU, and establish the signaled-state as strict decoupling point for
driver-unload.

Since all the code is new, we just don't implement deprecated
callbacks, and we use inline_lock.

I take the fence lock manually where necessary, and sometimes where
half-necessary.

Fence::is_signaled() for example takes and releases the lock like you
do in the AMD code example below, so that all future API users know
with 100% certainty that all callbacks have run once the function
returns true.

(what our Rust design, ironically, solves is ops->signaled() not being
usable for users of drm_sched, because of drm_sched_fence being in
between)

> 
> > > 
> > > But some problems like parts of the dma_fence uAPI are unfixable
> > > without time travel.
> > 
> > I would be especially interested in learning about who the party is
> > that apparently is spinning on dma_fence_is_signaled(), supposedly
> > preventing us from getting the memory ordering right.
> 
> Well there isn't spinning on it. It's just that in a SMP system it
> takes some time for state to transfer between CPU cores and that
> communication channel often becomes a bottleneck.

No no, that's not what I mean. Having ops->signaled() is unrelated to
my question.

I'm asking about this:

static inline bool
dma_fence_is_signaled(struct dma_fence *fence)
{
	const struct dma_fence_ops *ops;

	if (dma_fence_test_signaled_flag(fence))
		return true;


You said once that I cannot add lock protection to that if-evaluation.
And IIRC the reason was that someone would complain about performance.
Who is that someone?

That's what I meant: that someone would have to be looping on
dma_fence_is_signaled() to feel the lock.

The reason I want the lock there is that I want to get rid of things
like that:

void amdgpu_vm_fini(struct amdgpu_device *adev, struct amdgpu_vm *vm)
{
	[…]

	/* Make sure that all fence callbacks have completed */
	dma_fence_lock_irqsave(vm->last_tlb_flush, flags);
	dma_fence_unlock_irqrestore(vm->last_tlb_flush, flags);


> 
> By implementing the is_signaled callback you avoid that device->CPU
> core A->CPU core B signaling making things much more responsive.
> 
> Even on ancient drivers like radeon people start to complain when the
> is_signaled callback is removed, so it is definitely necessary.

We can keep the callback, I think it being there is not a decisive
issue.

Though I don't get why it being there would make things faster. My
understanding so far was that it's only good for parties that do not
signal fences via interrupt.

Who triggers the check via ops->is_signaled()? You once said it's
typically the compositor.

Since you mention Radeon I suppose it can indeed only be drivers that
don't use drm_sched.

> > Also learning more about the users that definitely *need* ops-
> > > signaled() and ops->enable_signaling() would be interesting.
> > > drm_sched
> > users cannot make use of these, since the sched-fence does not pass
> > the
> > request through to the hardware fence.
> > 
> > So who are the users? Parties like Nouveau implement these
> > callbacks,
> > but it's not clear whether they actually need them.
> 
> The eviction fence and KFD fence in amdgpu as well as the preemption
> fence in XE and i915 depend on that to note whenever somebody starts
> depending on the fence.
> 
> Additional to that I just last week have talked with some Qualcomm
> folks who desperately want device to device signaling without waking
> up the CPU. The enabling_signaling callback is necessary for that as
> well.
> 
> For Nouveau I think that it is pretty much pointless to implement
> those callbacks, but I'm not 100% sure.

I tried to remove them 1-2 years ago and then ran into massive
performance degradations, which indicates that Nouveau uses them for
some performance trick, maybe to reduce interrupt load. Didn't explore
it further.


P.

> 
> Regards,
> Christian.
> 
> > 
> > (btw, funnily enough, with the Rust-fence design we finally have
> > the
> > ability to fully support all callbacks with or without a scheduler,
> > since the need for an intermediate fence disappeared)
> > 
> > 
> > P.