ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
amarsh04 has quit []
u-amarsh04 has joined #dri-devel
iive has quit [Quit: They came for me...]
SquareWinter68 has joined #dri-devel
SquareWinter68 has quit [Remote host closed the connection]
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
a-865_ has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
a-865_ is now known as a-865
a-865 has left #dri-devel [#dri-devel]
cascardo_ is now known as cascardo
epoch101 has joined #dri-devel
<Lynne>
zzoon[m]: thanks, I'll test it now
<Lynne>
did you figure out the seeking in hevc issue btw?
epoch101 has quit []
Daanct12 has joined #dri-devel
pcercuei has quit [Quit: dodo]
The_Company has joined #dri-devel
<zzoon[m]>
Lynne: I remember I mentioned about that, it tries to get query results without query.
<zzoon[m]>
That's also what happening for seek during av1 decoding
Company has quit [Ping timeout: 480 seconds]
<Lynne>
but h264 works?
<zzoon>
yeah
<Lynne>
I think the driver should just return not ready or invalid or something
<Lynne>
and I don't even see how its possible we query results without a prior query, because the code explicitly checks
<zzoon>
ok.. could u let me know where it is(explicitly checking)? I'm going to work on it again.
<Lynne>
libavcodec/vulkan_decode.c, anywhere had_submission is used
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<zzoon>
ok thanks.
<Lynne>
ah... I see what you mean, when you reset, the previous queries are gone
<Lynne>
not sure how to solve that, but afaik the vulkan spec doesn't specify that anything should happen to queries when a video reset cmd is used
<zzoon>
you mean,, it resets after query but before getting results?
<Lynne>
yes, and then it gets results from a submission from before the reset
<zzoon>
ok. I think I need to read spec first and I'll be thinking about that case.
<Lynne>
we could remove the queries entirely, since they're only there to provide feedback for the user that something went wrong, though since we parse and verify the slices and headers ourselves, decoding on corrupt files doesn't generally happen
sukuna has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alane has quit []
alanc has joined #dri-devel
alane has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.5.1]
sukuna has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.4.4]
Daanct12 has joined #dri-devel
<zzoon>
Lynne: or you don't set VK_QUERY_RESULT_WAIT_BIT so it couldn't lead to timeout ..
<zzoon>
no idea other than that.
<Lynne>
we don't set the bit because we wait on the fence before
<zzoon>
Hmm... there is "ret = ff_vk_exec_get_query(&ctx->s, exec, (void **)&result, VK_QUERY_RESULT_WAIT_BIT); "
<Lynne>
I'll send a patch to remove the query, it was a hack anyway since what good is an error after a frame's been decoded
<Lynne>
and probably presented
<zzoon[m]>
ok
<Lynne>
btw, llvmpipe regressed and errors out when trying to create exportable opaque FD semaphores
<Lynne>
not sure who to blame, git log is unclear
kts has joined #dri-devel
Duke`` has joined #dri-devel
kts has quit [Quit: Leaving]
sguddati has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Quit: WeeChat 3.8]
The_Company has quit []
kaiwenjon has joined #dri-devel
sguddati has joined #dri-devel
kts has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
clfbbn has joined #dri-devel
coldfeet has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
coldfeet_ has joined #dri-devel
coldfeet has quit [Ping timeout: 480 seconds]
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
<MrCooper>
soreau: indeed it would, it would be a rather blunt solution though, so I'd avoid it if possible
<MrCooper>
I'd rather argue this is a special enough case that compositors should handle it explicitly
<DemiMarie>
MrCooper: Would this require compositors to special-case llvmpipe in any way? If so, please don’t do that. Sincerely, a Qubes OS developer who is often frustrated by stuff assuming GPU acceleration.
<soreau>
MrCooper: Is there a way to detect the case of having no fences/sync mechanism?
<MrCooper>
there is checking the renderer string for llvmpipe :)
<soreau>
i.e. can it be done conditionally so that the 'normal' paths stay in tact?
<MrCooper>
sure
<DemiMarie>
checking the renderer string is not a good option
<soreau>
ok, I'll look out for that MR ;)
<MrCooper>
neither is glFlush behaving like glFinish
<MrCooper>
it's a "pick your poison" kind of situation
<DemiMarie>
What about an env var to select the slow behavior?
NiGaR has quit [Remote host closed the connection]
<soreau>
MrCooper: DemiMarie: I just got wayfire working in a gh ci workflow runner using udmabuf+llvmpipe+headless: https://oshi.at/LjWP/screenshot.png
NiGaR has joined #dri-devel
<DemiMarie>
Also, is this just compositors or are apps also affected?
<MrCooper>
soreau: I'm not planning to work on this, just trying to help finding a solution
<DemiMarie>
soreau: udmabuf sounds great
<DemiMarie>
especially if explicit sync can be used with it
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
<soreau>
MrCooper: Aw, that's too bad. There's room for improvement, with your name all over it ;)
<MrCooper>
not really near my core of interest I'm afraid
<DemiMarie>
soreau: I just want to be able to run stuff in my no-GPU VMs and not have it break
<soreau>
DemiMarie: I think maybe apps work because they use swapbuffers?
<soreau>
but I have no idea really
<DemiMarie>
MrCooper: Why would glFlush and glFinish be noticeably different with SW rendering? I thought the difference was because the GPU is separate from the CPU and running in parallel with it.
<MrCooper>
yeah, this is only an issue if the compositor uses udmabuf to share its drawing with KMS or another entity
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
glennk has joined #dri-devel
<MrCooper>
DemiMarie: glFinish still blocks the calling thread and might prevent it from doing something else
<soreau>
MrCooper: yea, an env var doesn't sound too bad.. LP_FORCE_SYNC?
<DemiMarie>
MrCooper: is there something that is more important than running the llvmpipe compute threads?
<MrCooper>
not sure I see the point, the compositor can just call glFinish as needed?
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
<DemiMarie>
MrCooper: this is for compositors that don't check for SW rendering
<soreau>
MrCooper: but every compositor has to special case this instead of doing it once in the driver?
NiGaR has quit [Remote host closed the connection]
<DemiMarie>
soreau: exactly
<soreau>
doesn't make sense
<MrCooper>
and they expect what exactly with udmabuf?
<soreau>
that it works as the other drivers
<DemiMarie>
yup
<MrCooper>
well it can't
<DemiMarie>
why?
NiGaR has joined #dri-devel
<DemiMarie>
Is it the lack of dmafence finite-time signalling guarantees?
<MrCooper>
dma-fences can't be backed by software
<soreau>
MrCooper: that it works as where llvmpipe has fences
<MrCooper>
it would allow user space to hang / deadlock the kernel
<soreau>
this has 'driver bug' written all over it
<soreau>
there's no reason to start specially handling the llvmpipe case in compositors
<MrCooper>
it's deeper than that
<MrCooper>
it's an unavoidable issue in the core kernel memory management
<soreau>
well maybe we can start with a glFinish in glFlush patch to see if it provably works
<DemiMarie>
MrCooper: It is unavoidable with implicit sync, but what about explicit sync?
<DemiMarie>
Syncobjs explicitly have no finite time guarantees at all.
<MrCooper>
false dichotomy
<MrCooper>
it's rather dma-fence vs drm_syncobj, and as I wrote on GitLab, KMS only supports the former
<DemiMarie>
Is it? Yes, it's all dmafence under the hood, but an already-signaled fence doesn't need to be backed by anything.
<DemiMarie>
Ah, I was missing (and do not care about) KMS.
kts has joined #dri-devel
<DemiMarie>
All of my use-cases are with nested compositors.
<soreau>
but there are many more
<DemiMarie>
soreau: I'm not saying their aren't.
<DemiMarie>
Actually, now that I think about it, there are GPU passthrough situations on Arm where what you are talking about would matter.
<MrCooper>
I guess adding drm_syncobj support to KMS should be possible
<soreau>
MrCooper: reportedly, lavapipe works fine with udmabuf, do you happen to know what the difference is there?
<MrCooper>
with KMS, or nested?
<MrCooper>
if the latter, could be due to using drm_syncobj for synchronization
<soreau>
MrCooper: do you know whether KMS drm_syncobj would require kernel changes?
<MrCooper>
the K does stand for kernel, yes :)
<soreau>
heh
<soreau>
but I'm not sure what the case was for lavapipe
<soreau>
is there a way to use zink on top of lavapipe btw?
<MrCooper>
there is indeed, don't remember the magic incantation offhand though, it's tested in Mesa's CI FWIW
<soreau>
ok, thanks
haaninjo has joined #dri-devel
jsa1 has joined #dri-devel
<MrCooper>
just to be clear, if drm_syncobj support was added to KMS, the compositor would have to explicitly make use of that, it's not an automagic thing
<MrCooper>
and since it would involve somehow waiting for the GL rendering to finish and then signalling the drm_syncobj timeline acquire point, not sure there's really a point vs just delaying the KMS atomic commit until GL rendering finishes
<MrCooper>
maybe the drm_syncobj timeline acquire point could be signalled on another thread
KAL9000 has quit [Quit: KAL9000]
KAL9000 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
<ccr>
happy holidays etc to all of you :)
clfbbn has quit [Quit: Konversation terminated!]
rasterman has joined #dri-devel
warpme has joined #dri-devel
warpme is now known as Guest3979
fab has quit [Quit: fab]
JRepin has quit [Remote host closed the connection]
JRepin has joined #dri-devel
pcercuei has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
fab has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
gouchi has joined #dri-devel
guludo has joined #dri-devel
sravn has quit []
dsimic is now known as Guest3981
dsimic has joined #dri-devel
Guest3981 has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
fab has quit [Quit: fab]
clfbbn has joined #dri-devel
snowflask has joined #dri-devel
Guest3979 has quit []
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
alane has quit []
alane has joined #dri-devel
neniagh has joined #dri-devel
heat has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
u-amarsh04 has quit []
CME has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.4.4]
davispuh has joined #dri-devel
clfbbn has quit []
sguddati has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
CME has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
robertfoss has quit [Quit: WeeChat 4.1.1]
Guest1057 has quit []
guru_ has joined #dri-devel
guru_ has quit []
Company has joined #dri-devel
kzd has joined #dri-devel
clfbbn has joined #dri-devel
clfbbn has quit []
feaneron has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
kts has joined #dri-devel
snowflask has quit [Remote host closed the connection]
snowflask has joined #dri-devel
feaneron has quit [Remote host closed the connection]