09:24 snowycoder[d]: `Remaining: 16:17:20` Holy moly, I know I'm running deqp on an old server but I didn't know it was so CPU-bound
09:25 karolherbst[d]: probably spends 90% of the time doing mem transfers over PCIe 😛
12:35 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1392846688401621002/IMG_20250710_180436_792.webp?ex=68710510&is=686fb390&hm=54ad776ec9609b4adc51d9d678c067e4e11666c4df2c70f2f41e9dd2da4afa83&
12:35 tiredchiku[d]: tiredchiku[d]: I got to yell at the university's dean and controller of examinations, worth
12:40 kwizart: Hello there, I was wondering if nova_core, as nowadays provides in (fedora) distro kernel, is still likely to cause issue with nouveau ? Given that modinfo -F alias nova_core and nouveau share the same wildcard aliases both drivers will be loaded, but is there a mean to have one or the other to discard and hand-over if one is more relevant than the other ?
12:43 magic_rb[d]: Should a rtx 5080 work with nouveau enough to get to a gnome/kde desktop?
12:44 magic_rb[d]: Cause we have a situation in the nixos matrix room where it doesnt
12:45 karolherbst: not really
12:45 karolherbst: well..
12:45 karolherbst: it should use the software renderer
12:46 magic_rb[d]: So llvmpipe, but display out should be there, thanks
12:47 TheHypervisor[m]: Wouldn't any card with a UEFI firmware (so all of them as far as I know) be able to get to the desktop through the default UEFI frame buffer of something?
12:47 karolherbst: yeah
12:47 karolherbst: but things can fail in all sorts of way
12:47 magic_rb[d]: Yeah we dont get anything even with nomodeset
12:48 karolherbst: mhhhh
12:48 magic_rb[d]: So yes problem is somewhere in llvmpipe or something
12:48 karolherbst: maybe a firmare issue then?
12:48 magic_rb[d]: Was just confirming the nouveau side
12:48 karolherbst: because like.. you should see something with onmodeset
12:48 karolherbst: *nomodeset
12:48 karolherbst: not that it would change much
12:48 magic_rb[d]: Yeah not my computer so hard to debug
12:48 karolherbst: is it a laptop?
12:48 magic_rb[d]: Im just doing a proxy :P
12:48 magic_rb[d]: Dont think so, they mentioned xeon
12:48 karolherbst: mhh
12:49 karolherbst: they should check the iGPU outputs if they have an iGPU
12:49 karolherbst: it might be that it's loading on the iGPU driver just fine, but because nouveau can't load, they won't get additional outputs on the nv GPU
12:49 karolherbst: some firmwares have a setting to flip the hybrid GPU behavior there
12:50 TheHypervisor[m]: magic_rb[d]: Ohh, I had this issue too!
12:50 TheHypervisor[m]: On my Supermicro board there's an on-board graphics controller. If there is a VGA port on the rear IO perhaps it may be connected to the on-board graphics which is outputting something.
12:50 magic_rb[d]: Yeah its xeon
12:51 TheHypervisor[m]: Check to see if they have a workstation/server board with on-board graphics out
12:51 TheHypervisor[m]: I've had issues on my board with my GPU not outputting anything until its modeset driver is loaded.
15:08 gfxstrand[d]: airlied[d]: Because I can't remember: Are sync files and dma-buf FDs already CLOEXEC? If not, should we add flags to allow for creating them CLOEXEC?
15:42 gfxstrand[d]: mhenning[d]: Did you want a crack at reviewing the texdepbar pass before I merge it?
17:37 mhenning[d]: yeah, just left a few comments
17:43 gfxstrand[d]: Okay. I added a follow-on. I think we probablyneed another round before we merge.
17:44 gfxstrand[d]: That's okay. It's getting better and I think we'll have it in before the branch (or I can ask for a backport)
17:49 mhenning[d]: Are we hoping to ship kepler with 25.2 now that it's conformant?
17:49 mhenning[d]: If kepler is still behind I_WANT_A_BROKEN_VULKAN_DRIVER then I think it's okay for us to miss branchpoing
17:49 gfxstrand[d]: Yes, that's my plan
17:49 gfxstrand[d]: 25.2 will have both Kepler and Blackwell
17:53 mhenning[d]: Do we know how nvk perf compares to nouveau gl on kepler? Sometimes I wonder if we made a mistake in shipping maxwell nvk given reports like https://gitlab.freedesktop.org/mesa/mesa/-/issues/13291
18:01 gfxstrand[d]: IDK. As long as it's not super slow for UIs and they're not getting it by default it doesn't seem terrible. But it would be good to fix the cbuf thing
18:02 TheHypervisor[m]: <mhenning[d]> "Do we know how nvk perf compares..." <- I would imagine Kepler would have the benefit of power state changing, right?
18:02 mhenning[d]: Yeah, I'm mostly just worried that things with both an opengl backend and a vulkan backend will pick the vulkan driver and end up slower as a result
18:03 mhenning[d]: and yes, kepler can reclock but that probably helps nvk and nouveau gl roughly equally
18:20 snowycoder[d]: mhenning[d]: I'm running CTS on my GTX 770 and I found a couple bugs (there are still something like 6 hours left)
18:27 snowycoder[d]: In most of my tests on Kepler NVK is a little slower but performance is mostly comparable (we're faster on pixmark-piano!).
18:27 snowycoder[d]: I didn't test both texbar and instr-latencies though
18:28 snowycoder[d]: I'll test more games in the next days
18:34 mhenning[d]: "a little slower" is probably fine. I mostly just want to make sure we don't regress things significantly
19:04 gfxstrand[d]: snowycoder[d]: Uh oh... We were CTS clean at one point but there may be regressions.
19:04 marysaka[d]: oh wait 25.2-rc1 is very soon I just realized, I have some stuffs I forgot to MR :blobcatnotlikethis:
19:09 karolherbst[d]: somebody might want to review the coop matrix stuff as well 🙃
19:11 snowycoder[d]: gfxstrand[d]: The 770 is strange, is the only card with problems in ambient occlusion. I don't know why
19:11 karolherbst[d]: snowycoder[d]: zink or native gl?
19:12 karolherbst[d]: or uhm.. vulkan?
19:12 snowycoder[d]: Both zink and vulkan native, gl native works fine
19:12 karolherbst[d]: heh...
19:12 karolherbst[d]: doubt
19:12 karolherbst[d]: mind checking if https://gitlab.freedesktop.org/mesa/mesa/-/commit/dae57e184aafdd7da562cb3120d530504a2426fc regressed it?
19:13 snowycoder[d]: snowycoder[d]: Image reference from yesterday: ^
19:13 karolherbst[d]: though that's for native and zink
19:13 karolherbst[d]: I saw a regression with ambient occlusion in unigine heaven
19:13 karolherbst[d]: bisected it to the commit above
19:13 karolherbst[d]: haven't debugged it yet
19:13 karolherbst[d]: obviously that shouldn't impact vulkan driver...
19:14 snowycoder[d]: I have it in vulkan too 0_o.
19:14 snowycoder[d]: I'll check tomorrow
19:46 gfxstrand[d]: Could have regressed Zink as well as nouveau, I suppose
20:00 gfxstrand[d]: But that should have nothing to do with Talos
20:21 gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1392964067508879440/snapshot.png?ex=68717261&is=687020e1&hm=a8b073c85d0380540debdae91aef8b42bcdd950916493d4698af741f6e5b1626&
20:21 gfxstrand[d]: So.. steam is black?
20:22 gfxstrand[d]: Or do I need DRI_PRIME=1 for black steam?
20:28 gfxstrand[d]: Okay, yeah, DRI_PRIME=1 does it
20:30 mhenning[d]: fwiw, it's not black but rather uninitialized - you get a pattern if you NVK_DEBUG=trash_memory
20:31 gfxstrand[d]: Okay, I think I might know what's going on
20:35 gfxstrand[d]: Well, some ideas
20:47 airlied[d]: gfxstrand[d]: Sorry on the road with no laptop!
20:48 gfxstrand: no worries
20:59 gfxstrand[d]: Ugh.. Why are parts of steam 32-bit?!? 😩
21:00 mhenning[d]: i know right
21:03 x512[m]: gfxstrand[d]: https://github.com/ValveSoftware/steam-for-linux/issues/3518
21:04 TheHypervisor[m]: I like how Steam still requires x86_64 on Linux even though not being pure 64 bit. Only compatible with impure distributions
21:04 gfxstrand[d]: And only compatible with double-built drivers!
21:05 gfxstrand[d]: No idea if my mesa-run script will even work
21:06 mhenning[d]: I managed to nest two meson devenvs in the past
21:06 HdkR: "impure" is a funny way to say multi-arch.
21:07 HdkR: Just wait until you need three builds :blobsweat:
21:08 magic_rb[d]: Im still waiting on a hybrid architecture system, x86, x86\_64 and riscv
21:09 magic_rb[d]: What a fun mess to support that would be
21:09 HdkR: Fat elfs would have made it a lot easier.
21:09 magic_rb[d]: Multi arch kernel though >:)
21:10 gfxstrand: Okay, I'm getting my driver build now
21:12 gfxstrand[d]: Time to figure out what arcane glx magic Steam is using
21:12 HdkR: The main thing is sharing the CEF buffer across the IPC boundary to the 32-bit process.
21:14 HdkR: Just some pbuffer sharing?
21:16 HdkR: I think the only thing that doesn't render in CEF is the notification tray menu at this point :D
21:17 TheHypervisor[m]: <HdkR> ""impure" is a funny way to say..." <- I hate having to install multiple copies of worse versions of libraries that already exist on my computer. I'm a desktop user as is 99% of other Steam users, why do I need lib32-sdl2-image or whatever for their stupid web browser/game downloader app
21:18 gfxstrand[d]: Okay, so steam refuses to start if I hack EXT_texture_from_pixmap off. This isn't loooking good...
21:21 kayliemoony[d]: TheHypervisor[m]: Linux has no WoW64 equivalent and realistically cannot. at minimum 32-bit mesa and glibc will likely have to live on
21:21 HdkR: Indeed
21:22 kayliemoony[d]: So unless Valve starts doing something really, really fancy to older steam runtimes, we're stuck with it
21:23 HdkR: Everything else can eventually be pulled from their SLR runtimes, but glibc, video driver, and the video driver dependencies all need to come from the host, both 32-bit and 64-bit :D
21:25 kayliemoony[d]: (and obviously this only solves legacy Steam-powered applications, not legacy everything else)
21:33 HdkR: Legacy everything-else is hard without guaranteed UAPIs.
21:35 asuasuasu[d]: kayliemoony[d]: something i couldn't find an answer to is what is the extent of WoW64 on native windows, do they use stubs for a lot of libs over there or is that mostly a wine thing?
21:35 kayliemoony[d]: Afaict the majority of 32-bit libs are WoW64 stubs
21:35 TheHypervisor[m]: <kayliemoony[d]> "The Hypervisor: Linux has no WoW..." <- I'm thinking more so that most people are using Proton (Wine + various wrappers like DXVK) to run the Windows versions of games with all modern games AFAIK being AMD64 only, why should I download 32 bit libraries just for their client?
21:35 TheHypervisor[m]: Yes I'm sure it wouldn't be great for people playing Half-Life Source on Linux with the old 32-bit Source Engine, but why can't we have Steam x86_64 then an optional x86/32-bit runtime for distros that support multilib so that you could play older games. I really dislike multilib
21:36 asuasuasu[d]: that is neat, i'm not sure why basically all resources don't mention this aspect of WoW64 and focus on the syscall thing
21:36 kayliemoony[d]: Because multilib isn't just about steam, it's software compatibility.
21:36 kayliemoony[d]: I don't like dealing with 32-bit either but there's a massive trove of applications and games that aren't being recompiled any time soon
21:37 TheHypervisor[m]: Isn't modern Vulkan 64 bit only?
21:37 HdkR: arm64ec is a bit cooler in this regard, where they make "fat" PE libraries that contain both Arm64 and x86-64 and share data structures in the library to slim them down.
21:37 HdkR: TheHypervisor[m]: lol, no.
21:37 TheHypervisor[m]: As I said, I don't play Half-Life Source
21:37 kayliemoony[d]: Not afaict; and most of these games aren't using it they're on DX9 or DX10
21:37 kayliemoony[d]: I don't play hl source either
21:37 kayliemoony[d]: I play hyperlight drifter, simcity 4, and other older titles
21:38 kayliemoony[d]: EA isn't going into the archives to rebuild a game they don't profit on (SC4) any time soon
21:38 kayliemoony[d]: (HLD even has a native linux build it's just old)
21:39 kayliemoony[d]: It's extremely shortsighted to try and pin this to one or two things when there's entire eras of 32-bit software people still mess with
21:40 HdkR: Preservation of gaming is important.
21:41 kayliemoony[d]: (simcity 4 is a directx 7 game, by the way. Nightmare.)
21:41 HdkR: DX7K when? :P
21:41 HdkR: D7VK? :thonk:
21:44 kayliemoony[d]: Major distros aren't going to get to drop multilib any time soon as Linux has no way forward on that compat wise besides keeping it
21:45 HdkR: Even FEX leans directly on distro multi-arch support to run things on arm64.
21:45 asuasuasu[d]: it's also only a real practical issue when you're like, running gentoo or something, tbh; if you cared about the disk space _that_ much you'd reclaim much more than that by using a fs with transparent compression
21:46 kayliemoony[d]: Yeh
21:46 orowith2os[d]: Steam can't ship a fully separate 32-bit runtime without becoming flatpak, and fully isolating itself from system libraries
21:47 orowith2os[d]: Fwiw
21:48 orowith2os[d]: It relies on host glibc and mesa, and only uses runtime glibc if the host is older than the runtime
21:48 kayliemoony[d]: orowith2os[d]: And it can't do this without major breakage in regards to VR, steaminput, and other hardware conscious functionality
21:49 orowith2os[d]: Oh, it can keep hardware support, it's just that flatpak does it in a way that isn't comfortable with all that
21:49 orowith2os[d]: I meant "become flatpak" in the fully-independent runtime kind of way
21:50 magic_rb[d]: How do you fully separate from the host in the case of nvidia drivers, you need to pull those from the host
21:50 orowith2os[d]: Flatpak vendors EVERYTHING and reads host driver versions, downloading from Flathub for that
21:50 kayliemoony[d]: magic_rb[d]: cry
21:50 esdrastarsis[d]: HdkR: Today: https://github.com/AlpyneDreams/d8vk/tree/d3d7
21:50 HdkR: esdrastarsis[d]: ooo, didn't realize they had a d3d7 branch.
21:51 orowith2os[d]: Flatpak also has a Host driver mountpoint where, if you build a gl driver against an old enough glibc (and only rely on that), it'll work on every single flatpak runtime that exists
21:51 magic_rb[d]: orowith2os[d]: So itll be like "ah i see nvidia version X, let me just pull that from my own repos" ?
21:51 orowith2os[d]: Yeah
21:51 kayliemoony[d]: Sounds awful to maintain
21:51 orowith2os[d]: It's all automated
21:51 magic_rb[d]: Still ew
21:51 orowith2os[d]: You just need to run flatpak update after a Nvidia driver update
21:51 orowith2os[d]: Most distros don't like to use the Host driver mountpoint
21:52 orowith2os[d]: Endless does, and it doesn't cost anything
21:52 orowith2os[d]: Not even downloading another copy of Nvidia drivers
21:52 orowith2os[d]: https://blog.tingping.se/2018/08/26/flatpak-host-extensions.html
21:53 orowith2os[d]: Any Linux distro can skip the Nvidia pain with flatpak and work with this, but they refuse to.
21:54 orowith2os[d]: Asahi Linux builds their forked Mesa for a specific Flatpak runtime version and mounts it in the same place.
21:54 orowith2os[d]: https://copr.fedorainfracloud.org/coprs/g/asahi/flatpak/
21:55 magic_rb[d]: Interesting, now i wonder what nixos does
21:56 orowith2os[d]: It doesn't
21:56 orowith2os[d]: But it could
21:57 orowith2os[d]: Libcapsule is also very interesting here, because it means you can fully isolate Mesa and ship it from the host for Flatpak without ABI concerns, or conflicts with llvm
21:57 orowith2os[d]: LLVM conflicts are an issue even now, running normal Mesa
21:59 linkmauve: orowith2os[d], Asahi doesn’t have a forked Mesa any longer AFAIK, it’s all upstream nowadays.
21:59 orowith2os[d]: It's disabled by default iirc, still an unstable uapi
21:59 HdkR: UAPI is upstreamed as well even
22:00 HdkR: UAPI is upstreamed in the kernel even, otherwise mesa wouldn't accept it. Impl isn't although.
22:01 orowith2os[d]: Hm
22:01 orowith2os[d]: Well. That's what asahi did when it *was* an unstable uapi.
22:02 HdkR: yea, stable now since `include/uapi/drm/asahi_drm.h` exists :)
22:02 orowith2os[d]: You can also have distros provide optional packages that provide host Mesa for specific Flatpak runtime versions.
22:02 orowith2os[d]: That way, you can have your patched Mesa on Flatpak too, without needing to really learn Flatpak fuckery.
22:06 gfxstrand[d]: Okay, so nouveau GL can't run steam with DRI_PRIME=1 either 😩
22:06 HdkR: womp womp
22:08 gfxstrand[d]: At least not on AMD+NVIDIA
22:09 gfxstrand[d]: Maybe on AMD+Intel? I'm gonna start running out of test HW soon here
22:10 gfxstrand[d]: But that's a tomorrow problem.
22:12 mhenning[d]: gfxstrand[d]: oh, yeah, that's why I didn't complain about it before we turned zink on - it isn't a regression
22:13 gfxstrand[d]: Well, I know why Steam even tries to run. GLX erroneously advertises EXT_texture_from_pixmap with Kopper
22:13 gfxstrand[d]: Standard DRM GLX doesn't
22:14 gfxstrand[d]: Because, well, you kinda can't if you aren't the display GPU
22:16 gfxstrand[d]: But that might also be a red herring
22:23 gfxstrand[d]: I do think the GLX Kopper stuff is likely more mixed up than EGL was but I haven't spent enough time with it to be sure.
22:52 gfxstrand[d]: Historically Kopper has been swrast with extra hooks. But that's not really what Kopper is, though. And GLX is complicated enough I'm not sure that pretending Zink is swrast is gonna hold up.
22:52 gfxstrand[d]: But also, ugh... GLX...
23:31 bylaws[d]: kayliemoony[d]: The stubs are only for syscalls
23:31 bylaws[d]: Everything else is a copy