02:13 DemiMarie: What are AMD’s stride requirements?
12:35 mareko: does anybody know how to make MS Teams screen sharing work with XWayland?
12:40 mareko: AMD requires 256B pitch alignment for linear (it must exactly 256B, not less and not more); some AMD generations allow less, but Mesa always allocates with 256B alignment to make multi-GPU interop possible
12:41 mareko: AFAIK Intel also allocates with 256B alignment for linear because it's the only way to have interop with AMD GPUs
12:46 ccr:thinks about the Holy Handgrenade.
12:47 Company: I wonder if llvmpipe should do that, too
12:47 Company: it currently does 64 I think
12:47 mareko: ideally we would have linear modifiers for different alignments
12:48 Company: that would be neat
12:49 mareko: because the current linear modifier is always exposed but is not usable depending on the pitch alignment
12:50 Company: yeah, GTK has fallbacks using mmap() for linear and doesn't accept LINEAR for fourccs it can't handle
12:50 Company: and those fallbacks are SLOW
13:50 DemiMarie: mareko: what are the rules for offsets and for non-LINEAR modifiers?
13:52 DemiMarie: Company: why fallback instead of failing?
13:53 Company: 1. because the fallbacks aren't always slow
13:53 Company: 2. because sometimes it doesn't matter that they're slow
13:53 Company: 3. because nobody can handle failure
13:54 jannau: should v3d (rpi4b) in the upstream kernel use DMA?
13:54 DemiMarie: Company: how does one avoid the fallbacks?
13:55 jannau: I'm seeing 'vc4-drm gpu: swiotlb buffer is full (sz: 540672 bytes), total 32768 (slots), used 1381 (slots)' and garbled graphics
13:55 Company: DemiMarie: one uses drivers that don't need them
13:55 jannau: https://bugzilla.redhat.com/show_bug.cgi?id=2270430 for more details
13:56 DemiMarie: Company: which drivers?
13:56 Company: DemiMarie: the ones you are using
13:56 Company: you need to know what the target's requirements are and make sure your sources produce content that doesn't fallback
13:57 DemiMarie: Does GTK help with that?
13:57 Company: no
13:58 DemiMarie: Does GTK provide enough information to know the target?
13:58 Company: no
13:58 DemiMarie: How can one discover the target?
13:59 Company: you'd probably need to poke the GL and Vulkan default drivers
14:00 Company: but even that won't help too much, because half that info isn't available that way
14:00 DemiMarie: That doesn't seem reasonable. One doesn't know what GTK will be importing into.
14:00 Company: that's correct
14:01 DemiMarie: What is the solution?
14:01 Company: the target and source offer compatible formats in all cases
14:01 DemiMarie: How can one ensure that?
14:01 Company: you talk to everyone involved and get them to agree
14:02 DemiMarie: How does one do that?
14:02 Company: I don't know that
14:02 Company: which is why I implemented fallback
14:03 Company: my hope is that it works well enough so that in the few cases where it doesn't, users file bugs against the drivers so their developers are aware of the issues and then go and fix things
14:04 Company: or they come to GTK and suggest faster fallbacks
14:05 DemiMarie: Is the proper solution an omniscient userspace allocator like gralloc or minigbm?
14:05 Company: if I toggle some flags in GTK, my 4k video deadlocks my app for ~10s until an image appears and then another 10s for the next image
14:05 Company: by default, GPU and CPU stay in low power and take like ~5% each while playing that same 4k video
14:06 DemiMarie: In that case it might be better to fail and force the source to fallback to rendering to a CPU buffer.
14:06 Company: yeah, but I can't do that
14:06 DemiMarie: Why?
14:06 Company: because I don't have any easy tools to achieve that
14:07 Company: the source here is some random application developed by someone somewhere
14:07 Company: which will hopefully work fine in >95% of cases
14:08 Company: but sometimes some nerds read the Arch wiki and copy its tips into their /etc/environment.d
14:08 Company: and sometimes somebody has a driver for some new mobile chip they want to test on
14:09 DemiMarie: I found that GSK_RENDERER=cairo fixed some GTK apps that didn't render properly.
14:10 Company: yeah, it's the slow fallback (that also can't do 3D, but most GTK apps don't do any 3D)
14:11 Company: "slow" being relative there, because if you don't have a GPU, Cairo can be faster than GL/Vulkan software
14:13 DemiMarie: It seems that on Fedora 40 the default renderer is buggy with software rendering and X11.
14:15 Company: I'm not aware of any issues
14:15 Company: but I've also done a ton of work on the renderer this cycle, so I might be losing track
14:21 DemiMarie: It would be nice if there was a way for GTK to switch at runtime depending on whether 3D is in use, but this is off-topic.
14:24 Company: It would be nice if people stopped running UIs on devices without a GPU
14:24 Company: and didn't even consider it an option
14:24 DemiMarie: Company: never going to happen
14:25 Company: I'm pretty sure it's going to happen
14:25 Company: because UI software will flat out stop working
14:25 DemiMarie: That would break tens of thousands of users
14:25 DemiMarie: At least
14:25 Company: absolutely
14:25 Company: and then they will buy new hardware
14:26 Company: GTK 4.18 will do color management and linear compositing
14:26 Company: which will kill Cairo performance
14:27 DemiMarie: Could llvmpipe be made faster with better use of SIMD?
14:27 DemiMarie: Or is it memory bandwidth bound?
14:27 Company: I do think llvmpipe is the better choice compared to Cairo, but I have no idea what the limits are there
14:28 Company: the limit depends a bit on what you're doing, but on my machine llvmpipe stops getting much faster for my benchmark at ~4 threads
14:29 Company: so I assume that's the memory bandwidth limit
14:30 DemiMarie: Not everyone can afford new hardware.
14:32 Company: they'll have to use older GTK versions with older hardware then
14:32 DemiMarie: Or switch to non-GTK applications, which is what I may recommend to Qubes OS users
14:33 Company: yeah, fine with me
14:33 DemiMarie: Why are you okay with breaking working systems?
14:33 Company: GTK runs on pretty much anything that supports GLES3, anything older doesn't usually even have the CPU power to do the tasks that GTK applications want to do
14:36 DemiMarie: You forgot VDI, VMs, and systems where drivers are being brought up.
14:37 Company: I don't forget them, I just don't think they should be holding anyone back
14:37 Company: and VMs not getting their GPU story in order has been an ongoing thing for the last 10+ years
15:05 Company: DemiMarie: just tested it, the linear compositing color management stuff has pretty much no measurable impact on Mesa software rendering
15:05 Company: it just trashes Cairo, because unlike GL/Vulkan, Cairo has no support for it
15:09 emersion: could GTK disable the fancy color stuff with cairo?
15:10 Company: no
15:10 Company: well, it technically could, but it's a bad idea
15:10 Company: because it changes the result too much
15:11 emersion: it does
15:11 emersion: but usable and different result would be better than unusable
15:12 Company: yes and no
15:12 Company: people blame GTK if things look like shit, not their setup
15:12 emersion: and they don't blame GTK if it's super slow?
15:12 Company: no, because they know their setup is bad
15:13 emersion:doesn't really get why a calculator app or a file manage would require a fancy GPU
15:13 Company: I mean, they will initially, because they will see the regression from 4.16 => 4.18
15:14 Company: a calculator doesn't need a fancy gpu
15:14 emersion: a GTK4 calculator does
15:14 Company: because you don't care if it takes 100ms to repaint
15:15 emersion: and drains your battery?
15:15 Company: it doesn't because it only repaints once
15:15 Company: but file managers these days want to do smooth scrolling of fancy renderings for their files
15:16 Company: it's not like 20 years ago where you dragged the scrollbar, then it repainted once and was done
15:16 Company: you swipe the trackpad or wheel around
15:18 Company: and GTK won't stop running on those setups, it's just that people get annoyed once you get <10fps (roughly)
15:19 Company: and I'm sure you could make software rendering a lot faster (both in Mesa and in GTK), but that would require some serious engineering effort
15:19 Company: and nobody is willing to do that
15:21 DemiMarie: Company: this could be solved by making it a runtime flag
15:21 Company: GTK_BROKEN_RENDERING=1
15:21 DemiMarie: What kind of engineering effort, and how much faster? 2x?
15:22 Company: it's hard to make such generic statements because they depend on use case
15:23 Company: example: the table in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7570
15:29 Company: but to give some guesses:
15:30 Company: I expect Cairo to lose 50% of rendering perf because of linear compositing - pixman supports reading images as SRGB but Cairo doesn't expose a CAIRO_FORMAT_SRGB
15:31 Company: the Cairo renderer doesn't cache any converted images, and PNGs come out as unpremultiplied RGBA, but Cairo wants premultiplied BGRA - that's probably gonna buy you a bunch of speed on image-heavy cases (like a file manager showing a grid of thumbnails)
15:32 Company: lavapipe recently gained dmabuf support, which seems to have made perf of the software Vulkan renderer go up by roughly 3x
15:32 Company: but that's on a system with a GPU
15:33 Company: no idea what you'd get from using Cairo with udmabuf instead of wl_shm
15:34 Company: then GTK is absolutely not optimized for reducing shader instruction count
15:34 Company: because we're usually either CPU-bound or VRAM memory bandwidth
15:35 Company: but that is different on old hardware
15:35 Company: on with software rendering with low CPU count
15:38 Company: one could also write a GTK backend using skia
15:59 mareko: DemiMarie: non-linear modifiers have complex alignment rules
16:18 DemiMarie: mareko: are they written down anywhere?
16:19 DemiMarie: Also, is there an opaque counterpart to every format that has an alpha channel? If so, is it safe to pass a buffer with an alpha channel with the opaque format, or will that break with non-linear modifiers?
16:20 DemiMarie: If this is not safe, then I need to make a copy.
16:24 mareko: DemiMarie: yes, yes
16:24 DemiMarie: mareko: where are the written down?
16:25 mareko: nowhere
16:25 mareko: I was replying to the second message
16:25 mareko: trying to write down alignment rules for tiling is futile
16:25 DemiMarie: Futile?
16:25 mareko: yes
16:25 DemiMarie: Why?
16:26 mareko: every GPU is different
16:26 DemiMarie: Does Mesa know the rules?
16:26 DemiMarie: And if so, does it strictly validate them when importing external dmabufs?
16:26 mareko: for some, yes; for others, it has to compute them based on which GPU is plugged in
16:27 DemiMarie: Was the second yes “yes, it is safe” or “yes, you must make a copy”?
16:30 mareko: it's safe
16:30 mareko: but if you go RGBX->RGBA, A can be random
16:31 DemiMarie: mareko: is it safe to treat RGBA as RGBX?
16:31 mareko: yes
16:33 mareko: DemiMarie: what are you working on?
16:33 DemiMarie: Does that include lying to a Wayland compositor about the buffer type?
16:33 DemiMarie: mareko: A Wayland proxy for Qubes OS
16:33 mareko: I don't know much about compositors
16:35 DemiMarie: Client requests come from guest VMs and are assumed malicious. Furthermore, transparency is not allowed: the guest (which runs its own proxy) is responsible for compositing subsurfaces, and each format that supports transparency is transformed into one that does not.
16:47 zamundaaa[m]: Demi: it's safe, but it'll cause a lot of problems for apps
16:48 zamundaaa[m]: Oh, nvm, with subsurfaces out of the way, it should usually be fine
16:59 Company: it won't be fine
16:59 Company: unless you take control over shadows
17:00 Company: because Adwaita draws 60-90px wide shadows
17:01 Company: people not running compositors on X11 still file bugs to this day
17:26 karolherbst: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30831 (there is a couple of more stuff, and I still need to figure out the interop parts, but I _think_ the nir/vtn/clc parts are correct)
17:31 jenatali: karolherbst: cool, clc and vtn patches look good to me
17:32 karolherbst: feel free to use the MR as a checklist on what to add to your CL impl :D
17:33 DemiMarie: Company: those shadows will be clipped
17:33 karolherbst: anyway.. I think the interop stuff fails, because iris probably needs special handling for msaa exports
17:35 DemiMarie: Company: but also Adwaita should support not drawing shadows that will be clipped anyway
17:35 Company: there was some work along those lines, yeah
17:35 Company:didn't follow that
17:36 DemiMarie: this is also why I posted the change to xdg-decoration, because for tiling compositors not drawing server-side decorations doesn’t make sense at all
17:36 DemiMarie: but that is off-topic here
17:37 Company: xdg-decoration first needs to learn to cooperate with GTK anyway
19:50 Company: so apparently my mesa shader cache has 50 parts
19:50 Company: each of those have 2 files
19:50 Company: and I have 2 GPUs and llvmpipe
19:50 Company: so now I have 50 * 2 * 3 = 300 open fds
20:01 Company: good news everyone: if I use Vulkan and GL, I get even more fds
20:17 DemiMarie: Company: how would it cooperate?
20:18 DemiMarie: There are compositors that will draw server-side decorations no matter what the client does. It’s up to the client to deal with this situation.
20:18 DemiMarie: But that is a topic for #_oftc_#wayland:matrix.org
20:18 Company: there are clients that will draw client-side decorations no matter what the compositor does. It's up to the compositor to deal with this situation.
20:18 Company: now what?
20:19 DemiMarie: duplicate decorations
20:20 Company: that's not what the protocol says though
20:20 DemiMarie: #_oftc_#wayland:matrix.org
20:24 emersion: the protocol says the client must obey
20:25 Company: exactly
20:26 Company: and GTK can't do that
20:48 DemiMarie: no, GTK can
20:49 DemiMarie: "obey" does not mean "no CSDs"