08:10 austriancoder: zmike: if you could have another look at !31512, that would be really cool.
09:22 Venemo: MrCooper: have you managed to look into the high VRAM use issue that we talked about?
09:24 MrCooper: no, the comments looked like it's mostly expected between gnome-shell & Mesa
09:24 Venemo: MrCooper: I got some pretty hostile replies from other gnome-shell / mutter developers, although the issue is 100% reproducible, steps are provided how to reproduce it, and a part of the problem was identified (keeping the background in vram as a texture at its original size). I don't see what more I need to do on my end or why. it should be trivially reproducible for anyone who replied to that thread
09:24 MrCooper: didn't notice any hostility
09:25 Venemo: MrCooper: no, it's not between gnome-shell and Mesa. the issue is: (1) mutter keeps a copy of the background image at its full resolution, that consumes an absurd amount if it was a high-res image, and (2) gnome-sheel allocates more BOs than necessary
09:25 MrCooper: it's most likely gnome-shell, not mutter
09:25 Venemo: whether it's mutter or gnome-shell or whatever, as a user it doesn't matter to me
09:29 Venemo: MrCooper: mainly, I don't understand, why do you/they expect me to provide more info? the issue is trivially reproducible if you log into a gnome session and run umr
09:29 MrCooper: FWIW, you were asked to provide numbers for standalone mutter, as opposed to gnome-shell; that would help further isolate the issue between the two
09:30 MrCooper: why do you expect anyone else to do that for you?
09:30 Venemo: wdym "for me"?
09:31 MrCooper: you're expecting others to gather info instead of doing it yourself
09:31 Venemo: issue affects all users of gnome 100% of the time. why is it on me
09:31 MrCooper: doesn't affect me, haven't really seen other complaints either
09:32 Venemo: you see, this is exactly what I was talking about when I said I prefer not to open bug reports about gnome
09:32 Venemo: have you actually checked umr to verify that it doesn't affect you?
09:32 MrCooper: BTW, "not leaving enough for applications" is probably a red herring, inactive BOs can be evicted from VRAM to make space for others
09:33 MrCooper: what umr says is irrelevant for the fact it doesn't affect me
09:33 Venemo: well, does it not keep the desktop background in VRAM for you?
09:34 MrCooper: no idea
09:34 Venemo: so you actually don't know if it affects you
09:34 MrCooper: yes I do
09:35 Venemo: it's very easy to test, just set a higher resolution background and see if umr reports higher vram use
09:35 MrCooper: I have no issues, so it doesn't matter either way
09:35 Venemo: MrCooper: can you please actually check?
09:37 Venemo: Re: "inactive BOs can be evicted from VRAM" - if it was eviced, then why would umr report it as using vram?
09:38 Venemo: when you say "I have no issues" does that mean you checked and it doesn't consume that amount of vram for you?
09:43 MrCooper: Venemo: have you checked with umr that gnome-shell's BOs actually keep a game's out of VRAM?
09:43 Venemo: as best as I can tell, this is the case yes.
09:46 MrCooper: is that with Mesa using AMDGPU_GEM_CREATE_VM_ALWAYS_VALID for the game's BOs? There was an issue where BOs created like that couldn't push others out of VRAM, not sure if that's solved yet
09:47 Venemo: regardless of whether the BO is evicted or not, gnome-shell should still not create a huge BO for the background. even if it's eviced from VRAM it shouldn't consume system RAM either
09:48 jadahl: MrCooper: it'd only affect you if you use the gigantic default background
09:48 Venemo: it would affect you always. it just affects you less if your background is not huge
09:48 Venemo: also, have you considered the use case when the user has two monitors plugged in? in that case the shell will still have to draw the background for the second monitor so the BO can't be evicted
09:48 MrCooper: you don't get to decide what does or doesn't affect me, I'm the judge of that
09:49 jadahl: anyhow, I think the solution is to not cache the whole background image in vram, but in cpu memory, and cache only the actual background images used for compositing
09:49 Venemo: thank you jadahl
09:50 Venemo: additionally, it would be nice to figure out what the other BOs are
09:53 jadahl: client buffers? textures from shm? could also check if you end up with a shadow buffer. then there is the panel, which gets cached as a texture
09:53 Venemo: I can try to check what happens if I run umr remotely, I assume that would exclude XWayland and any client creating any buffers
09:54 jadahl: nvtop at least showed me memory usage that included vulkan/egl client buffers
10:11 Venemo: jadahl: that's a good point. so, running umr remotely means that it runs as a server without a gui, which should mean there are no clients, and therefore no client buffers, so we'll take those out of the equation entirely
10:17 pq: DEs tend to have helper clients, so there would still be clients, just not ones that you can easily avoid.
10:18 pq: Also any Wayland client using wl_shm buffers, that is, software rendering, will show up as compositor VRAM usage because they compositor needs to copy them into textures.
10:19 pq: Wasn't there a way to put labels on BOs? Do the tools print those labels?
10:20 Venemo: pq: at the moment the best we can do is AMD_DEBUG=extra_md which allows to inspect some metadata of the BOs
10:23 Venemo: umr can also actually look at the contents of the BOs, but this part is still in development
10:34 Venemo: jadahl: how do you start mutter without xwayland? I tried 'mutter --wayland' but this still starts xwayland
10:36 Venemo: ah never mind, it has a --no-x11 option
10:38 jadahl: that is indeed the one
10:38 jadahl: it also doesn't start xwayland unless an x11 client connects
10:42 Venemo: then I wonder what could have been the client that connected, as I didn't start any clients
10:43 jadahl: good question
10:46 jani: mripard: tzimmermann: mlankhorst: thoughts on https://lore.kernel.org/r/cover.1761126446.git.jani.nikula@intel.com
10:51 MrCooper: i.e. IME standalone mutter starts Xwayland during its startup, and shuts down if Xwayland dies
10:51 jadahl: MrCooper: why would it do that?
10:51 MrCooper: because the systemd stuff needed for running Xwayland on demand seems missing
10:51 jadahl: mutter --devkit doesn't here at least
10:54 MrCooper: indeed doesn't seem to here either, running mutter from a VT console does though
11:02 Venemo: jadahl, MrCooper I added more information to the ticket, comparing the memory consumption of just plain mutter vs. gnome shell, both without clients. mutter without gnome shell seems fine, although it has two BOs that I'm not sure what they are. gnome-shell itself seems to create a BO from the background in its original resoluton, which I think it shouldn't do. besides that, it creates several more framebuffer sized BOs which seem excessive
11:04 Venemo: just fixing the background will probably already improve the situation a lot, but won't fix the problem on its own. there are still a bunch of BOs that seem excessive
11:09 jadahl: how big is the unexplained one in mutter?
11:13 emersion: Venemo: multi-monitor makes it tricky to store a single background image lower than original resolution
11:14 tzimmermann: jani, makes sense
11:14 emersion: swaybg creates one texture per monitor size, and reloads the image from the file when needed
11:15 Venemo: jadahl: 9 MB
11:16 Venemo: emersion: it should be enough to store it at the resolution of the highest res monitor.
11:17 Venemo: emersion: it should of course reload from disk when you attach a higher res monitor than what is currently plugged in
11:38 pq: huh, I thought patches for adding userspace labels to DRM BOs must have had landed ages ago, but apparently not. The latest I see are driver specific ioctls proposed for it.
11:59 lassebq: I cannot fork Mesa. Is something up with freedesktop infra?
12:00 lassebq: I wanted to make PR with certain PRIME fixes that others may benefit from
12:02 glehmann: lassebq: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home#how-can-i-contribute-to-an-existing-project-or-create-a-new-one
12:36 zmike: mareko: how were you testing mesh pipeline stats? do you have mesh shaders in shaderdb?
12:53 zmike: seems like it's working to me
12:55 Venemo: maybe radv doesn't expose the feature correctly on all gpus? or doesn't even support it, I don't remember
12:55 zmike: idk I'm just running cts on rdna3 and it seems to work
12:58 Venemo: zmike: may support different stuff on rdna2
12:59 zmike: shrug
12:59 zmike: it's all vulkan properties/features
13:06 Venemo: i know, just sayin
13:20 tzimmermann: jani, i simply wouldn't want to revert the driver include changes is anything breaks. that's all
13:53 emersion: Venemo: scaling the original image to a 1280px image will give better results than scaling a 1920px image to a 1280px one
13:53 emersion: also, if you do that no need to perform the scaling each frame
13:54 emersion: a memory vs. quality/GPU time trade-off, i suppose
13:59 jani: tzimmermann: got it
14:43 Venemo: emersion: yes, that's a good point too. I suppose there are no right or wrong answers, just a tradeoff
17:59 mareko: zmike: I have a test that I'm working on that uses mesh shaders
18:00 mareko: zmike: see my zink MR
18:01 zmike: ohhh I thought you meant shaderdb
18:03 zmike: thanks for the fix
18:03 zmike: and congrats on making the aco switch
18:04 alyssa: seconded
18:04 alyssa: big news for aco fans
18:04 zmike: llvm fans in shambles
18:06 alyssa: chat is this real
18:06 llyyr: i915 without llvm next
18:17 mareko: aux/draw without llvm would be sufficient for i915, r300
18:51 alyssa: rusticl :(
18:56 karolherbst: we should just write a C compiler 🙃
18:58 HdkR: OpenCL++ would be so sad
19:08 alyssa: HdkR: it is already
19:09 alyssa: stop doing opencl++
19:09 alyssa: GPUs were not meant to run C++
19:09 HdkR: :D
19:09 HdkR: But my vtables!
19:09 alyssa: wanted templates anyway as a treat? we had a tool for that, #define
19:11 HdkR: Doesn't new C have something to improve that?
19:11 alyssa: _Generic yeah
19:11 alyssa: well
19:11 HdkR: I hate the keyword, but I guess if it gets close.
19:11 alyssa: _Generic is a crappy version of function overloading, not templates.
19:11 pac85: C with templates and none of the rest of c++ would be kinda cool
19:12 alyssa: I'd like to stick methods on structs..
19:12 HdkR: womp womp
19:12 alyssa: like just "x.foo()" that desugars to "whatever_foo(x)"
19:12 alyssa: but it is not worth it to bring in the rest of c++'s baggage
19:13 pac85: Also destructors
19:13 alyssa: real women use free()
19:14 HdkR: ~my_struct() { free(this); }
19:14 pac85: ^
19:15 alyssa: too robust
19:15 alyssa: not C enough
19:15 alyssa: needs more footguns
19:16 HdkR: The destructor is actually a stack inline function that gets executed with a RWX stack so it explodes in weird and unexplained code paths.
19:18 HdkR: ...Stack functions probably cause so much SMC overhead in FEX.
19:18 pac85: SMC?
19:18 HdkR: self-modifying-code
19:18 pac85: Oh self modifying
19:18 pac85: I see
19:23 HdkR: Created an issue to track that nightmare that can occur. wee
19:24 karolherbst: alyssa: well.. clang supports function overloading in C for reasons you very well know 🙃
19:25 pac85: What are the reasons
19:25 pac85: How does it even work without mangling across objects
19:25 karolherbst: OpenCL C
19:26 pac85: Ah I see
19:26 karolherbst: it's just a function attribute
19:26 pac85: Yeah I see, I thought you meant regular C
19:26 karolherbst: "__attribute__((overloadable))"
19:27 karolherbst: well it is available in C
19:27 pac85: Ah
19:27 pac85: And when you stick that attribute there the symbol gets mangled ig.?
19:27 karolherbst: mhh https://clang.llvm.org/docs/AttributeReference.html#overloadable
19:27 karolherbst: it implies it also works in GCC?
19:28 karolherbst: mhh maybe not
19:28 HdkR: What does that do to the symbols? That sounds wacky.
19:28 HdkR: Oh
19:28 karolherbst: HdkR: well mangling them
19:28 HdkR: Name mangling matches c++
19:28 karolherbst: yeah
19:29 HdkR: I guess that's not super evil
19:29 karolherbst: that's why we have a C++ symbol demangler in mesa 🙃
19:29 HdkR: :D
19:30 karolherbst: it's not the best one, but...
19:30 HdkR: If it works, whatever. I never make claims that my code is the best one either.
19:32 Mis012[m]: petition to get the mangling into C as extern "C++"
19:33 HdkR: Does it need a petition or just someone to write the support in to GCC and Clang?
19:33 pac85: petition to force someone to write that code
19:33 Mis012[m]: the attribute makes more sense for an extension
19:34 karolherbst: I mean gcc should just do whatever clang is doing
19:34 Mis012[m]: there are a few extensions that applies to ngl
19:36 Mis012[m]: but extern clearly could use more love, they went through the trouble of making it accept a string and yet even C++ still only supports "C" afaik :P
19:38 pac85: seems like you can do extern "C++" in c++
19:46 alyssa: p
19:48 pac85: is that missing a column
19:49 pac85: colon*
20:02 dwfreed: extern "C++" is the same as not specifying it
20:55 Venemo: pac85: you have my +1 on C with templates and none of the rest of c++
21:22 soreau: what would be a good incantation to build virgl for the default debian linux container on chromebook?
21:23 soreau: like the barebones without stuff I don't need
21:23 soreau: just need virgl xwayland and wayland
21:32 soreau: oof meson.build:661:4: ERROR: Problem encountered: glslang >= 12.2 is required.
21:34 soreau: why doesn't Khronos jump on the meson bandwagon already? :P
21:37 soreau:enters the labyrinth
21:38 soreau: well glslang is building, it was just a .py away from working by default :P
21:41 Lynne: glslang is not designed for anything but offline command line usage
21:41 Lynne: its the second worst codebase I've seen
21:42 soreau: tell me about it :P
21:42 soreau: Lynne: what's the #1 worst codebase you've witnessed?
21:43 Lynne: it had an absolutely awful non-threadsafe global state, which was then attempted to be made threadsafe, but was not at all successful, and so we had to sent patches to make it safe
21:44 Lynne: I'm so absolutely sick of it, and of GLSL, that I'd love to write SPIR-V assembly, only there IS NO ESCAPE
21:44 Lynne: since the spriv assembler tools are a different branch of the same tree that glslang comes from
21:44 Lynne: same awful tooling
21:45 Lynne: us in ffmpeg, libplacebo and mpv lust after the glsl compiler from mesa, but its far too large to take out since there's NIR involved in there
21:46 Lynne: oh, llvm recently (7 months ago) got support for native spirv, and clang has an opencl frontend, so you'd think that you could simply write opencl and compile into vulkan spirv
21:47 Lynne: but no, https://github.com/llvm/llvm-project/issues/135905 it just segfaults
21:48 Lynne: slang was promising, is at least able to be integrated, but it takes integration so far that integration is the only thing it is designed for
21:48 Lynne: the language is not fixed, so you're expected to freeze the compiler in your codebase and update all your shaders and the compiler all at once
21:50 Lynne: in conclusion, everything is terrible, I should go back to my idea of writing a simple runtime SPIRV assembler for ffmpeg/libplacebo, if there's one thing we do well in ffmpeg its assembly
21:50 soreau: Sorry, didn't mean to strike one of your nerves ;)
21:51 Lynne: its those nerves that will one day make the spirv assembler written, mark my words
21:51 soreau: Hey, I like that sense of confidence.
21:52 Lynne: the worst codebae I've ever seen is RESERVED as per RFC2119
21:52 soreau:marks Lynne's words on the board
21:52 Lynne: *codebase
21:53 soreau: Lynne: What happened, they ran out of names or were very poor at naming things in the first place?
21:54 soreau: Come on lowliest chromebook they had at BestBuy! 62% compiled...
21:55 soreau: A Celeron with a whopping two cores @ at a blistering 1.10 GHz each
21:57 soreau: but it runs with an HD external monitor farily decently
21:57 soreau: I even have VLC streaming HD RTSP streams.. it works.
21:58 soreau: Lynne: ffmpeg wlgrab when?
21:59 Lynne: I have some pipewire code written, but it only works for webcams and video streams
21:59 Lynne: the part to use dbus and call the compositor is missing, because its around 2.5k lines of terrible dbus code
22:00 Lynne: oh, the native wayland protocol, I forgot about it
22:00 soreau: well if everyone could agree that any1's wayland-protocol's for catpure are The Best, we might be in a better place by now...
22:00 soreau: yea
22:00 soreau: dbus FTL :P
22:02 soreau: my other wish is that ffmpeg rtsp recording to segments wouldn't keep starting over at 000.mp4 :P
22:16 Venemo: which macros should we use for printing stuff in the kernel? in amdgpu I've seen DRM_INFO/DRM_WARN, drm_info/drm_warn and also dev_info/dev_warn
22:20 soreau: ugh, it complains thhat rustc is too old but I have -Dgallium-rusticl=false -Dgallium-rusticl-enable-drivers="".. what else uses the rust compiler in mesa?
22:20 soreau: is it an oversight that it's required unconditionally?
22:21 Sachiel: nvk does
22:21 soreau: Venemo: printk :P
22:21 soreau: Sachiel: ah thanks
22:21 soreau: lemme see if that's getting pulled in
22:22 soreau: well darn, I don't see any nvk in mesa/meson.options
22:23 Venemo: soreau :)
22:23 soreau: hehe
22:23 soreau: Roll your own MACRO
22:24 soreau: Sachiel: is rustc a hard dep for mesa?
22:24 Sachiel: soreau: it's nouveau in vulkan-drivers, I think
22:24 soreau: oh
22:24 soreau: ok
22:25 soreau: Sachiel: do you happen to know if virgl and virtio are related in any way?
22:25 soreau: like, if I am targetting virgl, should I want virtio for vulkan-drivers too?
22:25 Sachiel: sorry, no idea
22:25 soreau: ok thanks anyway
22:32 soreau: Awesome, it worked. 1199 targets to go
22:32 soreau: Sachiel: ty
22:32 soreau: time for a much needed break.