00:43mareko: tjaalton: do you mean XWayland doesn't use xf86-video-amdgpu:
00:43mareko: ?
00:49karenw: XWayland does not need that part of the graphics driver stack as it delegates modesettings etc. to the wayland compositor.
01:35damo22: does anyone think its a terrible idea to make a drm server for grub framebuffer?
01:35damo22: i am on a platform with no linux kernel
01:37damo22: ie no modesetting allowed, just passthrough the mode
01:47Ermine: what does grub boot then?
02:16damo22: Ermine: gnumach
02:20damo22: via multiboot table
07:19Ermine: damo22: you can try to port simpledrm and whatever it needs then
07:29damo22: Ermine: I am porting the ioctl interface but i cant mimic it exactly so i will need to hack into libdrm as well
07:40Ermine: damo22: I guess you only need ioctls for DRM dumb buffers, since you don't modeset anyway
07:42damo22: yeah but i probably need the basic ioctls as well for the driver, as there is no linux drm to handle them
07:43damo22: even if most of them are stubs
15:38alyssa: hrm
15:39alyssa: if I do address mode optimizing early, I can handle gl/vk properly and that's all working nicely
15:40alyssa: but then opt_load_store_vectorize does't work, because that's supposed to run late and it's very much unclear to me if I can teach that pass to vectorize the lowered hw load/stores
15:42alyssa: although my hw thing looks like load_smem_amd so.. maybe?
15:45alyssa: oh, maybe this does work, it's just not liking the particular pattern here
17:22alyssa: reordered more passes. meh, good enough
21:02alyssa: although apparently load_store_vectorize can't vectorize lowered globals resulting from lower_ssbo
21:02alyssa: Hm.
21:04dj-death: yeah
21:05alyssa: dj-death: is load/store vectorization supposed to happen early then?
21:48dj-death: alyssa: yeah that was my assumption
21:48dj-death: alyssa: I'm guess it can't work on globals before of robustness
21:49dj-death: alyssa: I'm guessin it can't work on globals because of robustness
21:59redisaigner: So the time is mature to leave the IRC channels , i won't come back anymore! Looked as if none was listening not to mention participating, i must be crazy than. good bye.
22:14alyssa: dj-death: maybe?
22:14alyssa: it has code to handle globals and i've definitely seen it do stuff for opencl
22:14alyssa: it just doesn't handle the mixed 32/64-bit stuff nir_lower_io generates
22:15alyssa: which is.. incidentally the entire problem here
22:15alyssa: s/here/for my address mode branch/
22:18dj-death: :(
22:19alyssa: yeah.....
22:19alyssa: I have something that works nicely for gl at least
22:19alyssa: still haven't done any shader work for vulkan
22:19alyssa: idk how to use fossil-db with my driver
22:33Shibe: I have a strange issue but I'm not sure where to report it. If I attempt to screenshare on applications running on my iGPU (Ryzen 7800x3d) with my RX580 being my primary GPU, I get corrupted output on all applications I've tried (firefox, chrome, discord, obs). I thought maybe this was a KDE portal issue but I tried with hyprland too. Could this be a mesa problem and should I report it there?
22:33Shibe: Maybe this is a wrong modifiers being used problem especially since my rx580 doesn't seem to have modifier support at all
22:33soreau: what version of mesa?
22:34Shibe: This is what screenshare looks like, https://i.imgur.com/n1wAuz5.png
22:34Shibe: soreau: mesa 24.2.5
22:34Shibe: I haven't tried screensharing in this type of setup before, so don't know if this was always broken
22:35Shibe: this only happens when an application is running on the integrated gpu, but I haven't tried running my entire desktop off of the iGPU display outputs and then attempting screenshare
22:35soreau: the only thing I know of that might be possibly related is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725
22:37Shibe: I assume to test this I'd have to run my entire environment off this (compositor included)? I can run applications using mesa git but not sure how to get my entire environment to use this on fedora
22:38soreau: you can install mesa to a nonstandard prefix like /opt/mesa and then point LD_LIBRARY_PATH=/opt/mesa/lib/$libdir/ ./compositor
22:39soreau: this way, you only use the mesa you built if that variable is set, otherwise it will use 'normal' system mesa
22:41soreau: the other thing you might consider is trying older versions of mesa to see if it ever worked before the change that this patch fixes
22:53dj-death: alyssa: fossilize-replay
22:56alyssa: dj-death: yeah but like.. do I need to capture fossils myself? or will e.g. radv fossils replay on hk?
22:56alyssa: allegedly I can grab them from steam's cache but that didn't work when I tried it
22:58Sachiel: I wouldn't expect them to work
22:58alyssa: OK
23:04dj-death: alyssa: ah yeah fair point
23:37DemiMarie: Why are Intel iGPUs so much slower than AMD iGPUs?
23:41HdkR: DemiMarie: I'd blame die investment towards the GPU
23:42DemiMarie: HdkR: why does AMD devote more die area to the GPU?
23:42HdkR: DemiMarie: Seems like they care more about bigger numbers on the GPU :)
23:43airlied: also pwr mgmt balance
23:44HdkR: It's all a game of trade-offs
23:48DemiMarie: One of the factors that made me want to get GPU acceleration into Qubes OS was that M1 die shots showed the GPU being bigger than the CPU.
23:48DemiMarie: Another factor is that CPUs are terrible at math: the vast majority of their die area goes to control logic, not ALUs.
23:56HdkR: Yea, GPU is bigger than the CPU clusters in most hardware. Intel iGPU has been historically anemic aside from their top end 48/72EU things that Apple used to ship
23:56HdkR: https://x.com/Kurnalsalts/status/1848700612181168601/photo/1 Big GPU in the new sm8750 SoC
23:57DemiMarie: I just looked at a Lunar Lake die shot and they could have doubled the GPU if they left out media, NPU, and IPU.
23:58HdkR: That's one of the trade-offs people are making. Sticking wacking huge NPUs on the die even if no one wants it
23:58DemiMarie: The GPU is about the same size as the CPU but has far more area allocated to math.