01:08 dcbaker: LaserEyess: if you're targeting 23.2 just a heads up it might take a few days before it gets pulled, but I will get to it
01:09 LaserEyess: I was hoping for a 23.1 backport
01:09 LaserEyess: wait, is 23.2 out?
01:10 LaserEyess: no? so this should be included in that
01:10 LaserEyess: oh, there's already a staging branch, I guess I don't know how mesa's release cycles work
01:19 alyssa: karolherbst: wonder if we can just use https://www.khronos.org/blog/whats-new-in-clang-release-14-for-opencl-developers
01:19 kisak: dcbaker: fwiw, I'm of the opinion that you don't need to fully clear your backlog before cutting -rc3. You can mark that off anywhere you feel comfortable, and it'll let the few people who do rc testing a chance to jump forward while you have more time for -rc4
01:24 LaserEyess: so to clarify should I put up a backport for MR for 23.1 and 23.2?
02:52 LaserEyess: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25021
02:53 LaserEyess: it won't allow me to assign it to the maintainer, I think because it's my first contribution
03:03 LaserEyess: and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25022 because I didn't get an answer if I should do one or both
04:56 dcbaker: LaserEyess: you should open a backport for each branch you want to have a patch applied to. There are usually two maintainers, one doing the current release and one doing the previous release. So you did the right thing
04:58 dcbaker: kisak: that’s my plan. I kinda forgot that Monday is a holiday in the us (for me), so I guess we’ll have a release on Tuesday and another near the end of the week
09:09 karolherbst: alyssa: we can't
09:09 karolherbst: it's still lacking important features
09:09 karolherbst: but anyway, I think for now clang uses the translator under the hood
09:09 karolherbst: for the spirv targets
09:10 karolherbst: and we can't really use it, because we have to be explicit about the extensions we support and other things
09:10 karolherbst: `But there is one caveat - currently clang requires an external tool ‘llvm-spirv’ from the SPIRV-LLVM-Translator repo to be installed separately` ah yes
09:11 karolherbst: but yeah.. you _can_ manually compile via clang + llvm-spirv directly and just ship that spir-v
10:02 DavidHeidelberg[m]: alyssa: thanks for disabling the WHL
10:02 DavidHeidelberg[m]: https://lava.collabora.dev/scheduler/device_type/dell-latitude-5400-8665U-sarien
13:17 alyssa: karolherbst: ack
16:49 MrCooper: zamundaaa[m]: could be that glFinish waits only for the GPU command stream to finish processing, whereas the fences signal only once all results have been written back to memory; not sure offhand whether the former would be valid or a bug though
17:25 LaserEyess: dcbaker: thanks! I still can't assign the maintainers, but I suppose you are aware of it now. No worries if it takes a bit, just hoping it gets in so that I can finally use vaapi again
19:55 DavidHeidelberg[m]: airlied: https://www.youtube.com/watch?v=HzzLY5TdnZo nice talk! thanks.
22:15 karolherbst: alyssa: btw, there is a clc to spir-v offline compilation script in my cts runner repo, so I can run the entire CTS with SPIR-Vs instead of source code in case you want to see how one would use it
22:16 alyssa: karolherbst: I mean, mesa_clc works fine for me
22:17 alyssa: I'm just thinking about whether it makes sense to avoid the `native: both` mess long-term
22:17 alyssa: But if the long term is actually mesa_clc generating serialized NIR so we can do a pile of lowering+opt ahead-of-time, well, ok the
22:17 karolherbst: ahh, fair enough. It might make sense however to port over to the interface the CTS expects and then we can also use it for CTS runs and ahead-of-time compilations more generally
22:17 karolherbst: there are some people interested in having a tool to precompiled OpenCL C
22:17 karolherbst: *precompile
22:18 alyssa: I don't want to be in the business of supplying a generic tool
22:18 alyssa: and more importantly I don't want Mesa to have that support burden
22:18 karolherbst: me neither, but if we decide to have such a tool, we might as well make it compatible for such use cases
22:18 alyssa: no, I disagree
22:18 alyssa: this is purely for internal use. if later we decide to change how the pipeline looks (doing some NIR in there or whatever), we should be able to do so without regard for external suers
22:18 karolherbst: yeah, that's fair
22:18 alyssa: I explicitly don't want out-of-tree users
22:19 alyssa: especially when there are projetcs better suited for that (namely, clang itself)
22:20 karolherbst: right, but the point of suchs tools is more like shipping the native binary blobs, which I absolutely don't want to support, but I also kinda see the point of having 0 compilation overhead at runtime... it's just that nothing we care about would want to use that. It's more in the HPC space
22:21 karolherbst: but yeah.. I wished the CTS itself would ship that tool.. I should pring people again or just upstream my script
22:23 karolherbst: I'm still wondering if stopping at the spir-v with binary blobs will be a problem as CL has an API to fetch compiled blobs and some applications make heavy use of it. I hope we won't be forced (out of performance reasons) to ship native GPU binaries ever...
22:23 alyssa: right. I recognize that we have differing priorities here probably
22:24 alyssa: you're interested in shipping CL, i'm interested in mesa internally using a subset of CL C for graphics stuff
22:24 karolherbst: yeah.. I just want that mesa provides some compute API so distributions/users/devs can rely on it being there and to crazi things, not really caring about HPC or any of that "let's ship native binaries" nonsense
22:24 alyssa: yeah
22:25 alyssa: for my side, the fact that CL is involved is an implementation detail
22:25 alyssa: what I actually want is just "get a nir_shader for some C code"
22:25 alyssa: not even necessarily invoked as a compute kernel, possibly just a single function that gets inlined into a frag shader by a nir lowering pass
22:25 karolherbst: yeah, that's fair. I just won't be surprised if in the far future we'll end up doing more with such a tool. Or maybe we won't.
22:26 karolherbst: yeah..
22:26 alyssa: sure, and we can discuss those possibilities in the future
22:26 karolherbst: so... some people are working on emiting vulkan spir-v btw
22:26 alyssa: it just.. might involve a second tool, perhaps, and that's finetoo
22:26 karolherbst: from OpenCL C
22:26 alyssa: the spirv is also an implementation detail, that's also what I'm getting at
22:26 karolherbst: not sure if it's going anywhere, but the translator kinda has a bit of support for it
22:27 alyssa: the API i'm exposing is "files in Mesa in, nir_shader* out", and whatever's happening in the middle should be irrelevant to everyone else
22:28 karolherbst: oh sure, I'm just thinking out loud here mostly
22:28 alyssa: that's internally passing through opencl spir-v but again that's an internal impl detail even from the perspective of the GL & VK Mesa drivers that will consume the final nir_shader,
22:28 alyssa: sure
22:28 alyssa: what I'm getting at is "I like your project and I hope you like my project but they're very different projects and trying to share code other than src/compiler/ is probably not what either of us want at this stage"
22:28 alyssa: if that makes sense?
22:29 alyssa: IDK. I could be totally wrong here. It happens a lot :D
22:30 karolherbst: nah, that's perfectly fine. and you are not wrong. I was mostly just rambling and sharing some of my internal toughts around all this binary mess I'm ignoring for now
22:30 alyssa: ah, yeah
22:31 alyssa: TBH the VK_EXT_shader_object model is probably saner than a standalone Mesa compiler.
22:33 lumag: jani, excuse me. I'm trying to understand if the CI failure is a result of the patchset or not: https://patchwork.freedesktop.org/series/120395/
22:33 karolherbst: yeah.. probably. Depends a little on what you want to do I guess?
23:00 DemiMarie: Will the Xe driver have less kernel-side attack surface once it is ready?
23:01 airlied: what is a kernel side attack surface and how to you have less of it?
23:02 airlied: like if you can't answer that sort of question, it's unlikely anyone else can, your threat model is not my threat model etc
23:03 karolherbst: I think there is a disconnect with those kinda discussions. I understand why one would like to esstimate "security" from a theoretical point of view, _but_ sadly that's just some academic approach and irrelevant to reality and users. What matters is, how many bugs are known and how quickly do they get fixed.
23:03 karolherbst: and that bugfixes (not security fixes) get backported in time
23:04 karolherbst: we can have academical discussion on how secury something is in theory, but that's really a pointless discussion if you want to know about actual security
23:04 karolherbst: and actual security you only know about finding bugs and writing exploits to get them fixed quickly
23:13 DemiMarie: There is also the question of “how likely is somebody to be able to find and exploit a 0day for this”.
23:13 DemiMarie: That happens quite a bit in browsers for example.
23:13 karolherbst: sure, but if you want to know that, you pay sec people to do an audit
23:13 karolherbst: normally
23:14 karolherbst: maybe intel does audits themselves, maybe they don't
23:14 DemiMarie: yeah
23:14 karolherbst: but it's really hard for random kernel developers to anwer general statements about code security, because I suspect most of the kernel devs don't actually know enough about security to actually give reliable statements here
23:15 DemiMarie: you are probably right, which is sad
23:15 DemiMarie: maybe my expectations were too high
23:15 karolherbst: well.. nobody gets taught about programing security :P
23:15 DemiMarie: I blame the schools for that.
23:15 karolherbst: same
23:16 DemiMarie: When I was in university, I was taught that one can always assume one’s inputs to be valid, which is a great way to learn to write extremely vulnerable code.
23:16 airlied: in the old internet, everyone was nice, I blame the new internet :-P
23:17 karolherbst: I thought that's the reason to valide html forms in javascript :P
23:18 DemiMarie: On the one side, I have users someone might be willing to burn a 0day on. On the other side, I have toolkit authors who have decided that ordinary applications being nearly unusable without GPU acceleration isn’t a bug.
23:19 karolherbst: yeah....
23:19 DemiMarie: And if I can’t figure out what the risks of GPU acceleration are, then my userbase has no hope of doing so.
23:20 karolherbst: though if a toolkit is unusably slow with software rendering, that's kinda... uhm.. weird
23:20 karolherbst: and somebody should probably optimize the toolkit instead
23:20 DemiMarie: For me gnome-text-editor used 80% CPU scrolling quickly on a certain text file
23:20 DemiMarie: That toolkit is GTK4 btw
23:21 karolherbst: yeah... smooth scaling might do that if software rendered...
23:21 karolherbst: ehh
23:21 karolherbst: smooth scrolling
23:21 DemiMarie: smooth scrolling?
23:21 karolherbst: like instead of scrolling row by row, it's all smothed out
23:22 karolherbst: dunno.. maybe they listen more if you show it's also slow on "usual" intel GPUs?
23:22 DemiMarie: are some of those pretty slow?
23:22 karolherbst: I know that intel can't keep up on a 4k display
23:23 karolherbst: on gnome that is. And that problem kinda isn't prioritized enough, so it's all suboptimal
23:23 DemiMarie: which Intel?
23:23 karolherbst: 10th gen or something
23:23 DemiMarie: do they only care about fancy dGPUs?
23:24 karolherbst: I have no idea
23:24 karolherbst: they problably just don't run on 4k
23:25 karolherbst: anyway, I suspect people will stop caring about sw rendering, because that's kinda a maintainance burdon, what however can do is to show that it's slow on normal users machines
23:25 karolherbst: if it's not, then I guess that strategy won't work
23:25 karolherbst: but from my experience, there are a few performance issues in gnome
23:25 DemiMarie: airlied: to a crude approximation, “kernel side attack surface” would be the various uAPI ioctls
23:26 DemiMarie: I’m scared people will also stop caring about old slow iGPUs
23:26 DemiMarie: and then I am really in a bad spot
23:27 karolherbst: maybe desktop environments should set them some goals and say "it should run smoothly on GPUs from the last 10 years" or something :D
23:28 karolherbst: and then it's all more transparent or something
23:30 kchibisov: karolherbst: isn't smooth scrolling is usually done by allocating larger canvas/texture and just moving viewport?
23:30 karolherbst: maybe?
23:30 kchibisov: So I'd guess with 4k they just have pretty large things in memory.
23:30 kchibisov: but gtk stuff is really slow when there's no hwaccel, like gnome-terminal is unusable on Wayland basically.
23:37 DemiMarie: kchibisov: I wonder if they are tripping over a bug in llvmpipe or just doing something really really unoptimized.
23:37 kchibisov: They use cairo.
23:37 kchibisov: no llvmpipe.
23:37 kchibisov: ¯\_(ツ)_/¯
23:38 karolherbst: would llvmpipe be faster though? :D
23:38 kchibisov: alacritty with llvmpipe is faster iirc.
23:38 DemiMarie: karolherbst: thanks for at least being willing to talk to me about this stuff, even when you don’t have an answer.
23:38 kchibisov: I mean, faster than gnome terminal.
23:38 DemiMarie: kchibisov: GTK3 used Cairo for everything. GTK4 uses OpenGL by default. One can switch to Cairo (`GSK_RENDERER=cairo`) but it breaks certain apps and is deprecated.
23:39 kchibisov: DemiMarie: maybe, we just explicitly benchmarked all of those apps recently, and they were sort of slow.
23:39 DemiMarie: kchibisov: those = GTK apps with no HW accel?
23:40 kchibisov: DemiMarie: we were benchmarking input latency though, but some benchmarks showed that frame rate was not that great.
23:40 DemiMarie: kchibisov: did KDE do better?
23:41 alyssa: llvmpipe's shiny new linear renderer probably helps :)
23:41 DemiMarie: alyssa: wait what??? please tell!
23:42 kchibisov: DemiMarie: https://mastodon.online/@YaLTeR/110818542557525729 . We haven't bothered to benchmark kde, because only some kde apps.
23:43 kchibisov: But as I said, we were measuring latency, not fps, it was just observable with some payloads that certain things struggle.
23:49 DemiMarie: Makes sense.
23:51 alyssa: DemiMarie: Apparently it was merged 2 years ago, maybe not so shiny anymore?
23:51 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11969
23:51 alyssa: oh https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24102 is maybe why it's fresh in my mind
23:52 DemiMarie: alyssa: why the hack specifically for gnome-shell and mutter?
23:53 kchibisov: DemiMarie: if you look at PR, it seems like you can configure it.
23:54 DemiMarie: kchibisov: that part doesn’t surprise me, what does surprise me is turning it on for gnome-shell and mutter specifically
23:54 kchibisov: Well, it could be just what was tested.
23:54 DemiMarie: Probably