agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
mripard has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
dolphin has quit [Quit: Leaving]
alarumbe has joined #dri-devel
hikiko has joined #dri-devel
<mripard>
mlankhorst: it looks like we haven't sent a drm-misc-next PR for a while?
hikiko_ has quit [Ping timeout: 480 seconds]
rjodin has joined #dri-devel
<mlankhorst>
mripard: Yeah, will do so in a bit!
<alyssa>
sima: bbrezillon: what I'm trying to remember is why is the dma-fence memalloc a *cross driver* contract, given the docs *also* say:
<alyssa>
> Note that only GPU drivers have a reasonable excuse for both requiring mmu_interval_notifier and shrinker callbacks at the same time as having to track asynchronous compute work using dma_fence. No driver outside of drivers/gpu should ever call dma_fence_wait() in such contexts.
<alyssa>
does that imply the deadlocks can only happen if
<alyssa>
1. the GPU driver has a shrinker callback that actually tries to block on fences (instead of just hypotehtically being allowed to), or
<alyssa>
2. multiple GPU drivers are in-use simultaneously
warpme has quit []
<alyssa>
that is - the whole cross-driver contract here exists specifically to ensure hybrid GPU setups are correct
fab has quit [Quit: fab]
<sima>
3. kernel maintainers would like to keep a tiny amount of sanity and not have to remember per-driver rules :-)
<sima>
but yeah, technically it's just for hybrid gpus
<alyssa>
yeah ok
<sima>
which is why out of tree android drivers have this all really easy
<alyssa>
which would explain why - despite all the mobile parts being "wrong" - this has never actually blown up in the wild
<sima>
just bend things until it works for you and done
<sima>
alyssa, it's also really hard to hit in practice
<alyssa>
well yes
<sima>
even on big desktop gpus when you run the precise nasty workloads
<alyssa>
but like. as long as the mobile gpu shrinkers don't wait on their own fences... there's no problem, these crappy android SoCs don't have working pcie controllers anyway :p
Company has joined #dri-devel
<sima>
alyssa, people in various discussions did suggest we try to tag fences so you can have different ones with different rules
<sima>
and know when not to wait on some and bail
<alyssa>
this sounds like a different kind of hell.
<sima>
one hang-up is that the mmu notifier path can't fail (unless that process has suffered death-by-oom already)
<sima>
alyssa, yeah consensus I think still is that it's not worth the pain
<alyssa>
what is the mmu notifier path exactly?
kzd has joined #dri-devel
<sima>
alyssa, pte clearing when you userptr that range and must stay in sync
<sima>
the easy option out is userptr with pin_user_pages(FOLL_LONGTERM)
mehdi-djait3397165695212282475 has joined #dri-devel
<alyssa>
i guess these are bug fixes
<alyssa>
that affect the current rc
<alyssa>
so.. drm-misc-fixes?
<alyssa>
for the whole adp series and also that thing?
<alyssa>
and then the vsprintf stuff i guess goes into -misc-next?
<alyssa>
i regret taking that one on
<alyssa>
tangentially
<alyssa>
jannau: you should possibly have drm commit rights yourself
jsa2 has quit [Ping timeout: 480 seconds]
<jannau>
alyssa: agreed, when I start sending out patches for the apple KMS driver I should have commit rights
<alyssa>
ack
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
<jannau>
yes, all fixes for v6.15. adp was merged for 6.15. the Kconfig patch is not that pressing but I expect it will be picked for once it in Linus' tree
<alyssa>
i'd argue the kconfig one is still bug fix enough to go with the rest
<alyssa>
this is a post-hoc argument because i already picked it and started the smoke buildtest
<jannau>
yes, it's a fix
<alyssa>
cool
<alyssa>
will push once the build test finishes
epoch101 has quit []
<jannau>
thanks
lynxeye has quit [Quit: Leaving.]
mehdi-djait3397165695212282475 has quit []
sima has quit [Ping timeout: 480 seconds]
tomaw has quit [Remote host closed the connection]