01:03zzoon: Lynne: Looking into av1 dec on anv now..
01:04zzoon: found some issues on handling cdf bufs
01:41Lynne: glehmann: my issue is that I'm several function calls in, most very hot, and checking for the return of every single one of them adds branches in a part where I don't really want branches
04:31DemiMarie: Lynne: patch Mesa to add the support :P
04:32Lynne: can't be fixed, its a glsl issue, and as we all know, glsl issues never get fixed
04:33Lynne: pretty sure there's nothing illegal about outputting spirv OpKill from compute shaders
04:39Lynne: I'd write in spirv asm if I could, if only spirv assemblers weren't part of the same trainwreck that glsl compilers are, and the IR in spirv was less IR-y and took a book from x86
04:40HdkR: Time to implement VK_EXT_ARB_shader
04:41DemiMarie: Why GLSL and not HLSL?
04:42DemiMarie: Or if this is Mesa-specific just patch Mesa to add a compiler intrinsic.
04:42Lynne: all roads lead to rome, in other words, anything that touches spirv (except mesa) uses the same piece of cursed libs
04:42airlied: opkill isn't legal in compute I don't htink
04:43airlied: I think you just return from the function
04:43DemiMarie: Can GPUs implement longjmp?
04:43airlied: at least for kernels
04:44DemiMarie: Lynne: what is this for?
04:44Lynne: video decoder running on vulkan
04:45DemiMarie: Interesting! Is this for when the HW does not support decoding in fixed function?
04:46Lynne: you can read junk or eos during entropy decoding so rather than overreading, you just want to terminate the invocation immediately
04:46Lynne: no, its for codecs with no fixed function implementations
04:46DemiMarie: Interesting! I thought that decompression was too serial to be fast on GPUs.
04:47Lynne: codecs where the entropy coding state gets reset between blocks can be parallelized
04:47DemiMarie: Which ones are those?
04:48Lynne: prores, vc-2, mjpeg, ffv1, many
04:48Lynne: gopro's old intra codec too
04:48DemiMarie: Darn it! I was hoping to see the big ones on the list.
04:49HdkR: ProRes might be a big one in certain circles
04:52Lynne: prores isn't big enough for you?
04:52Lynne: 99% of what you see has been prores at some point
04:53Lynne: though I'm currently writing ffv1, which is what most archival libraries use
04:54DemiMarie: I don't work in the video production space.
04:55DemiMarie: I trust that you are right about ProRes being a big deal, but it doesn't come up in my line of work.
04:55DemiMarie: Or if it does, I'm not aware of it.
04:57DemiMarie: What got me excited was the possibility of not needing to expose the fixed-function HW blocks and the corresponding attack surface.
05:54zzoon: Lynne: could u recommend a branch of FFMpeg for testing vk av1 decoding?
05:54Lynne: git master will work fine
05:55zzoon: ok
06:38mareko: eric_engestrom: how do I add -Wno-inconsistent-missing-override to debian-android?
06:42mareko: eric_engestrom: it ignores options in meson.build
08:48mareko: jenatali: hi, any idea why this is failing? Assertion failed: var->data.location_frac == 0 && old_length <= 4 - https://gitlab.freedesktop.org/mesa/mesa/-/jobs/68427130
10:36soreau: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535
10:37soreau: daniels: have you had a chance to take a look? ^^
13:16jenatali: mareko: thanks for the ping, I'll take a look
14:43daniels: karolherbst: :( :( :( https://gitlab.freedesktop.org/daniels/mesa/-/jobs/68444277#L4591
14:44karolherbst: daniels: ohh right.. I should fix that, there was an issue already. Let me get it done aspa
14:45daniels: karolherbst: <3 <3 <3
15:18karolherbst: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32723
15:18daniels: thankyou!
15:19karolherbst: uhh.. hopefully that still compiles wiht 1.78 🙃 but yeah
15:19karolherbst: though we might not want to compile with `-D warning` in CI
15:19karolherbst: not sure what's adding that
15:20karolherbst: we also don't fail on warnings in C code there
15:21karolherbst: but maybe it's fine :)
15:24daniels: passing --werror to Meson does that
15:25daniels: and there's no way to enable it only for C but not Rust, so if we don't do it then Mesa just becomes a sea of warnings instead :\
15:39phasta: sima, hi… FYI, I today messed up by applying a patch twice, once to dri-misc-next and dri-misc-fixes. "drm/sched: Fix drm_sched_fini() docu generation" – content is the same, so shouldn't cause a merge conflict, but definitely not good… Mea culpa. Will be very careful in the future
15:41sima: phasta, ping drm misc maintainers as heads up, so tzimmermann, mlankhorst and mripard
15:42sima: phasta, also for intentional cherry-picking (e.g. pushed to -next, later on realized it's a bugfix) there's dim cherry-pick
15:42phasta: ping via mail?
15:42sima: nah here is good enough
15:42sima: otherwise no worries, it's not a disaster
15:43phasta: for me it's the cherry on the icing of a horrible week ^^'
15:43phasta: thx, will look into dim cherry-pick for next time
15:43sima: phasta, if you've pushed to -fixes first I would have not bothered with also -next, if that's where you wanted it
15:43phasta: no, was to -next first
15:43sima: but if it's accidentally to -next instead of -fixes, pls ask drm-misc maintainers first, they would have told you about dim cherry-pick
15:43MrCooper: daniels: could pass -Werror via c{,pp}_args ?
15:44sima: phasta, yeah in general just ask here instead of trying to rectify it yourself, we generally have a process/docs for almost every possible screw-up :-)
15:44phasta: sima, ACK, thx
15:46daniels: MrCooper: meh tbh
15:55mripard: sima: I think we said that cherry-picks were maintainer-only operations though, so we probably shouldn't advertise it :)
15:56sima: mripard, yeah that's why I told phasta to ping drm-misc maintainers first and not try to rectify themselves
15:56sima: because if you just cherry-pick no one remembers to check whether dim has a command for that
17:33mlankhorst: Ohh I got pinged, reminds me to pull request today. :)
18:17mlankhorst: sima: shouldn't be a big problem to have it applied twice for once though?
18:20sima: mlankhorst, yeah it's no big deal
20:56karolherbst: daniels: yeah.. it looks like we simply disable specific warnings causing errors on the C/C++ side then... oh well
21:04karolherbst: daniels: anyway, if you verify that my MR fixes those build issues I can merge it, though I might just assign to marge right away 🙃 It's not like anything there can break anything
21:04karolherbst: just would be good to know if there is more or if it's everything
22:05dcbaker: daniels, karolherbst: We could change `--werror` to accept languages...