The conflict on the ML happened around two related patches:
First, I fixed a bug where the scheduler job completion fence had some debug callbacks that would dereference the scheduler object itself. That would mean that the scheduler would have to outlive its fences. This makes *no sense* because fences are long-lived objects: your fence might be attached to a buffer shared to another driver entirely and could be alive forever. Introducing this job completion fence -> scheduler lifetime dependency is silly, because the scheduler is an object owned by one driver. That means that driver, and the structures it associates with a scheduler, might be blocked from cleaning up forever. And this all just due to some debug pretty-print name callbacks! It wasn't even critical core functionality or some deep design decision, just some debug code. But the maintainer blocked it because he believed it was required, and sensible, to have the scheduler outlive its completion fence.
But wait, how do you even do that? If it's the driver's job to ensure that lifetime, but the completion fence is owned by the scheduler, how would that even work?
The answer is that the job completion fence *holds a reference to the hw fence*, even after the latter completes. And *that reference is supposed to cause the driver to keep the scheduler alive*.
So now we have a lifetime chain of job completion fence -> hw fence -> scheduler.
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
npub1cx…z6wtz
2024-08-30 15:28:45 UTC
in reply to nevent1q…pg3f
Author Public Key
npub1cxqje22r8ewnr30rt625d58cr8gpdjnw405cq5765m2qsvghnmpquz6wtzPublished at
2024-08-30 15:28:45 UTCEvent JSON
{
"id": "302ad40d2098403c54826252cd8c90f0e5c06939e0af177cf3b7cb59af4a0e09",
"pubkey": "c1812ca9433e5d31c5e35e9546d0f819d016ca6eabe98053daa6d40831179ec2",
"created_at": 1725031725,
"kind": 1,
"tags": [
[
"p",
"c1812ca9433e5d31c5e35e9546d0f819d016ca6eabe98053daa6d40831179ec2"
],
[
"e",
"e8d9e0d93ed719da3de622eb59770073e2aa668306514a97f5bebf49801665f3",
"",
"root",
"c1812ca9433e5d31c5e35e9546d0f819d016ca6eabe98053daa6d40831179ec2"
],
[
"proxy",
"https://vt.social/@lina/113051679174845573",
"web"
],
[
"proxy",
"https://vt.social/users/lina/statuses/113051679174845573",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://vt.social/users/lina/statuses/113051679174845573",
"pink.momostr"
],
[
"-"
]
],
"content": "The conflict on the ML happened around two related patches:\n\nFirst, I fixed a bug where the scheduler job completion fence had some debug callbacks that would dereference the scheduler object itself. That would mean that the scheduler would have to outlive its fences. This makes *no sense* because fences are long-lived objects: your fence might be attached to a buffer shared to another driver entirely and could be alive forever. Introducing this job completion fence -\u003e scheduler lifetime dependency is silly, because the scheduler is an object owned by one driver. That means that driver, and the structures it associates with a scheduler, might be blocked from cleaning up forever. And this all just due to some debug pretty-print name callbacks! It wasn't even critical core functionality or some deep design decision, just some debug code. But the maintainer blocked it because he believed it was required, and sensible, to have the scheduler outlive its completion fence.\n\nBut wait, how do you even do that? If it's the driver's job to ensure that lifetime, but the completion fence is owned by the scheduler, how would that even work?\n\nThe answer is that the job completion fence *holds a reference to the hw fence*, even after the latter completes. And *that reference is supposed to cause the driver to keep the scheduler alive*.\n\nSo now we have a lifetime chain of job completion fence -\u003e hw fence -\u003e scheduler.",
"sig": "59f6050f13d26dcd84bc9a5203320847de11f323c8082c5686a83c55449e22314a38028dc9d63e14359a6de9d6e52efb160f01d4e04d48f4ff9ab592ec37400e"
}