00:00 gfxstrand[d]: Who needs fences? All they ever do is slow you down!
00:11 redsheep[d]: ristovski[d]: I am happy to test windows stuff anytime as it is my main OS, if you or x512 get around to that
00:13 redsheep[d]: Hmm. I feel like building mesa on windows directly is going would be good to get sorted out sooner rather than later. Building with msvc is probably crazy but maybe cygwin or mingw?
00:18 redsheep[d]: Maybe I will try to make that my contribution, get nvk to build directly on windows without having to be inside of wsl2
00:19 redsheep[d]: Oh and I suppose I also probably want to build zink but I suspect that is easier
00:20 mhenning[d]: People already use llvmpipe and zink on windows, so there's presumably some way to build it
00:21 redsheep[d]: Zink? I had heard about llvmpipe. Do you mean like with zink for xplane or actually being able to use zink as a general purpose gl driver?
00:22 redsheep[d]: Environment variables suck so bad on windows I have failed to even get games to run point to a different icd path, this is going to be kind of tough
00:23 redsheep[d]: I hadn't appreciated the life of luxury I was living doing the kind of testing I do for nvk on linux
00:25 mhenning[d]: Yeah, there's xplane. Not sure if anything else uses it though
00:26 rinlovesyou[d]: rinlovesyou[d]: oh
00:26 rinlovesyou[d]: [ 9.736988] nouveau 0000:0b:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x00000065
00:26 rinlovesyou[d]: [ 9.737594] nouveau 0000:0b:00.0: drm: DDC responded, but no EDID for DP-1
00:27 redsheep[d]: Well I'll be. This is a thing that exists: https://github.com/pal1000/mesa-dist-win
00:27 redsheep[d]: I'm sure getting nvk to build will be a few extra steps but a lot of the work has been done
00:29 rinlovesyou[d]: rinlovesyou[d]: that first line shows up *a lot* throughout dmesg
00:29 rinlovesyou[d]: kernel 6.14 moment maybe
00:34 mhenning[d]: rinlovesyou[d]: If that's a kernel regression, please file a report
00:35 rinlovesyou[d]: I definitely didn't have any issues in 6.13 and that's the only significant change i can think of on my system
00:35 rinlovesyou[d]: Where exactly would i report?
00:36 mhenning[d]: https://gitlab.freedesktop.org/drm/nouveau/-/issues for kernel issues
00:36 redsheep[d]: redsheep[d]: The readme actually mentions about environment variables on windows, saying to use batch scripts. That doesn't do me much good for steam games though. Unlike with steam on linux, running steam with an environment variable on windows doesn't seem to work, and it doesn't seem like the %command% trick in game properties works either
00:37 redsheep[d]: Testing anything I build is going to be really limited if I have to hijack my main nvidia ICD or something similarly awful
00:37 mohamexiety[d]: ristovski[d]: do you recall some of them btw? there are quite a few documented here for example https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/sdk/nvidia/inc/ctrl/ctrl2080/ctrl2080perf.h#L254-L289
00:38 redsheep[d]: Though I won't have to be concerned that doing that will break rendering my desktop so I guess maybe I am okay bricking nvidia vulkan
00:41 redsheep[d]: Has anyone heard of people doing vkd3d on windows? Google search results for it seems to turn up nothing
00:42 rinlovesyou[d]: You certainly can
00:43 rinlovesyou[d]: People have been using it recently and discovered Nvidia's vulkan implementation performs up to 44% worse on both windows and Linux under vkd3d vs native dx12 on windows
00:43 redsheep[d]: Part of that might be due to losing game specific optimizations nvidia does, but yeah not hugely surprising either
00:44 rinlovesyou[d]: Yeah it started as a Linux bug report, and then people discovered very similar drops on windows under vkd3d
00:44 rinlovesyou[d]: Looks like Nvidia is tracking it now though so hopefully they can get that sorted
00:45 redsheep[d]: Yeah, I mean it's not hugely important on windows where the nvidia dx12 driver is really good, but on linux where you really need it, yeah absolutely
00:46 rinlovesyou[d]: Yeah i mean Nvidia generally underperforms on Linux whereas amd outperforms windows even *when* translating
00:46 redsheep[d]: I would bet at least some of it is nvidia's dx12 driver just performing better than their vulkan driver
00:46 rinlovesyou[d]: Yeah for sure
00:47 rinlovesyou[d]: I hear amd's windows drivers aren't great either
00:47 rinlovesyou[d]: So not surprising mesa is outperforming it
00:47 redsheep[d]: Depends what aspect you're referring to. Some bits seem quite good, others maybe not. Depends what you care about
00:48 rinlovesyou[d]: Well just strictly talking dx12 on windows vs vkd3d on Linux
00:48 redsheep[d]: Ah, yeah.
00:49 rinlovesyou[d]: In other areas too though, my friend was complaining about after effects performing much worse on his 9070xt vs his older Nvidia card
00:50 rinlovesyou[d]: Although that could also just be adobe focusing way more on Nvidia
00:51 mohamexiety[d]: rinlovesyou[d]: it's not the Vulkan implementation per se. it's related to some of the fast paths on vkd3d relying on extensions that don't map very well to NV HW and thus perform poorly
00:51 mohamexiety[d]: it was discussed here a while back, EXT_descriptor_buffer
00:51 redsheep[d]: rinlovesyou[d]: That's almost certainly part of it. Adobe is... really something
00:52 rinlovesyou[d]: Lol yeah I'm very happy with davinci resolve
00:52 ristovski[d]: mohamexiety[d]: 77 instances are indeed documented in `ctrl2080*.h`
00:52 rinlovesyou[d]: I just wish they paid the codecs licenses so i didn't have to keep converting my mp4s
00:52 redsheep[d]: If rm is really as close to rm as it sounds then maybe windows support won't be too awful
00:53 redsheep[d]: Having to have locked versions of your nvidia driver might suck but it's not the worst
00:53 redsheep[d]: *close to openrm
00:53 mohamexiety[d]: ristovski[d]: yeah I was just curious if they were undocumented or they're just hidden. one time in the future I'd like to port over the NVIDIA App's power control stuff if it's possible since it's really nice, convenient, and quick
00:54 rinlovesyou[d]: mohamexiety[d]: I see, hopefully *something* can be done about it though, the losses at the moment are insane
00:55 ristovski[d]: Then I suppose "hidden" would indeed be a better term, they are simply not public
00:55 mohamexiety[d]: hopefully not too painful to unearth then :thonk:
00:57 ristovski[d]: mohamexiety[d]: heh, interestingly enough, I still can't get voltage readings no matter what I try
00:58 redsheep[d]: Does nvidia-smi or any nvml stuff read out the voltages?
00:59 mohamexiety[d]: on windows yeah, and I'd assume on linux too tho I havent tried
00:59 mohamexiety[d]: `nvidia-smi -q -d VOLTAGE`
00:59 rinlovesyou[d]: mohamexiety[d]: ```
00:59 rinlovesyou[d]: Timestamp : Fri Mar 28 01:59:32 2025
00:59 rinlovesyou[d]: Driver Version : 570.133.07
00:59 rinlovesyou[d]: CUDA Version : 12.8
00:59 rinlovesyou[d]: Attached GPUs : 1
00:59 rinlovesyou[d]: GPU 00000000:0B:00.0
00:59 rinlovesyou[d]: Voltage
00:59 rinlovesyou[d]: Graphics : N/A
00:59 ristovski[d]: nvidia-smi voltage reading got deprecated, and now returns N/A
01:00 rinlovesyou[d]: yerp
01:00 mohamexiety[d]: huh, TIL
01:00 mohamexiety[d]: it worked for me on.. 566 I think it was? so this was a very recent change 😮
01:00 ristovski[d]: 570 I think
01:00 redsheep[d]: Something I was thinking about, if there are windows tools interacting with the kmd that can do stuff like that then tracing them could yield interesting results for getting that kind of data on linux
01:00 redsheep[d]: If the driver is similar, why not?
01:01 ristovski[d]: The difference being that nvidia-smi on 570+ uses nvml iirc? not sure
01:01 ristovski[d]: perhaps I should grab the older version and diff it...
01:01 redsheep[d]: I know for a fact that my 572 driver can see that data through hwinfo64 and msi afterburner and so on
01:02 mohamexiety[d]: yeah the NV App also shows it, so not sure where they changed things (and how)
01:02 mohamexiety[d]: and also why
01:02 ristovski[d]: I wish Windows had bpftrace, it would make debugging so much easier
01:04 ristovski[d]: 570.86.16: ```strings /opt/bin/nvidia-smi|grep nvml|wc -l
01:04 ristovski[d]: 268```
01:04 ristovski[d]: Could be that it used nvml even before, not sure, I only recently got an nvidia card so I started off with 570
01:05 rinlovesyou[d]: why would they get rid of the voltage view on nvidia-smi though
01:05 redsheep[d]: ristovski[d]: You have blackwell?
01:06 ristovski[d]: Nope, AD103, so Ada Lovelace
01:07 redsheep[d]: Nothing like massive shortages to get everyone to buy AMD and last gen
01:07 mohamexiety[d]: I have wasted like 4 days this week trying to hunt down a blackwell card locally :KEKW:
01:07 ristovski[d]: Getting an older version of nvidia-smi is a major pain, its contained inside the full cuda toolkit
01:08 mohamexiety[d]: arguing with retailers, contacting distributors, hitting up importers and all kinds of shady stores
01:08 redsheep[d]: mohamexiety[d]: It sat as a mental background task for me pretty much every day from Jan 30th to a week or two ago, very annoying
01:08 redsheep[d]: Like maybe just don't launch a card you don't intend to divert dies to, pls
01:09 redsheep[d]: It wasn't even the price that stopped me buying a 5090, it was annoyance and exhaustion
01:10 mohamexiety[d]: what utterly devastated me was that it would have been somehow cheaper to book a ticket to the US last week, attend GTC, and camp outside that 5090 food truck that was selling MSRP 5090 FEs to get one and return back than somehow get one locally (which in itself is not really possible without massive concessions). _accounting for ticket and hotel prices_
01:11 redsheep[d]: That's beyond awful
01:12 mohamexiety[d]: will figure something out in the coming month though I guess :/
01:13 airlied[d]: ristovski[d]: maybe you went from the closed non-gsp kmod to the open gsp one?
01:13 ristovski[d]: ok nvm, even `v384.130` used nvml
01:13 ristovski[d]: airlied[d]: I never saw voltages working btw, I've been on the open gsp one from day 1
01:14 ristovski[d]: so unless the closed kmod handles the queries differently (reading registers etc), i dont really see what would be different
01:15 mohamexiety[d]: fwiw it doesn't work on windows anymore. but I did hear something about them moving to gsp on windows as well recently
01:16 redsheep[d]: airlied[d]: Does the closed kmd not use gsp on turing+? If not, might that mean the windows driver is potentially quite different?
01:17 mohamexiety[d]: on linux the closed kernel didn't use it by default until 560 or thereabouts
01:19 redsheep[d]: I thought it was just that the nvidia drivers are defaulted to being installed as the open one if all the gpus present are new enough
01:20 mohamexiety[d]: that's only for Blackwell
01:20 mohamexiety[d]: (as it's not supported on the closed kernel)
01:20 ristovski[d]: `The GSP firmware will be used by default for all Turing and later GPUs.` There's also `NVreg_EnableGpuFirmware`, and setting it to `0` only works on the closed binary driver afaik
01:21 redsheep[d]: Yeah that's what I thought, I had assumed the closed one had started having gsp a while back
01:22 redsheep[d]: Seems reasonable to read "firmware" as meaning "gsp", like you can't not have firmware and have it work
01:24 ristovski[d]: I should check where in the open driver the ioctl gets handled and forwarded to the GSP (I assume). Not yet sure, but I bet nvml et al issue a ioctl that then causes the kernel driver to do a NvRmApi call or w/e it was called
01:38 redsheep[d]: Another crazy and possibly bad idea just occurred to me, but if the uapi isn't different when closed rm is using gsp or not, and if similar versions of openrm and closed rm have similar uapi, might that mean that having turing+ on openrm with gsp working isn't super far off from having pre-turing non-gsp working with closed rm?
01:39 redsheep[d]: Doesn't help the people who want nouveau for the sake of not being on an old KMD but it's something
01:39 redsheep[d]: At the least being able to test the kepler and maxwell code with full performance would be cool.
01:42 redsheep[d]: I understand there are quite a few assumptions there but still it would be very useful
01:42 mhenning[d]: redsheep[d]: I have no idea how close they actually are
01:51 airlied[d]: the APIs are meant to be mostly identical
01:52 rinlovesyou[d]: 👀
03:12 x512[m]: Yes, in theory it should be possible to run NVK on proprietary Nvidia kernel driver on pre-Turing GPUs.
03:20 orowith2os[d]: Do they change between generations? You'd be doing more digging and REing if the uAPI for pre-Turing was different enough
03:21 karolherbst[d]: the biggest issue is just that the UAPI isn't stable
03:21 karolherbst[d]: so you might have to recompile after each driver update or something like that. Maybe even make code changes
03:22 karolherbst[d]: though not sure how much of an issue that is for basic interfaces
03:22 orowith2os[d]: Does the Nvidia-open driver have the same uAPI policy?
03:22 karolherbst[d]: why should it have any policy?
03:22 karolherbst[d]: it's not in-tree, they can do whatever they want
03:23 orowith2os[d]: That's fair, it just got my attention with the NVK-on-nvrm stuff
03:24 karolherbst[d]: the reason the nvidia userspace stops working after upgrading it is because they have a hard version lock in place, because they don't care whatsoever
03:25 gfxstrand[d]: Yeah, they use the windows model: Build both halves from that same perforce repo, ship them together, and don't worry about it.
03:27 gfxstrand[d]: Piles of breakage all the time isn't great. Being able to rebuild just part of the stack is good for driver engineers. But at the end of the day they don't care about the stability of internal interfaces at all.
03:27 gfxstrand[d]: And their UAPI is an internal interface
03:30 karolherbst[d]: yeah.. it's not a great thing for distributions who don't want to bother users with that nonsense 😄
03:31 redsheep[d]: I was thinking if any of this were to ever get packaged you'd want to just ship a matching version of openrm with the nvk package , do what Nvidia does
03:31 orowith2os[d]: So, I guess, either write for each differing kernel uAPI and version check it at runtime, recompile and maybe patch for each version change, or wait for Nvidia to stop dev on out of tree drivers (move to upstream Linux dev) and then assume latest version of that
03:31 karolherbst[d]: it makes automatic updates non viable or you bring back "your computer needs to restart.... now, you have 0.005 seconds to abort"
03:31 gfxstrand[d]: But also they have an obsession with treating everything like MMIO register with each 32-bit value having an "address" that's in a #define somewhere so that may provide some accidental stability.
03:31 karolherbst[d]: dialogs
03:31 redsheep[d]: But that falls apart for trying to provide it as a tool for pre-turing
03:31 x512[m]: orowith2os[d]: UAPI is defined by driver version, not GPU generations or open vs proprietary.
03:31 karolherbst[d]: redsheep[d]: nvidia does nothing
03:31 karolherbst[d]: it just breaks literally
03:32 karolherbst[d]: userspace just nopes out and you can't do anything anymore
03:32 karolherbst[d]: can only reboot
03:32 redsheep[d]: I mean taking their packaging approach
03:32 karolherbst[d]: nvidia doesn't do packaging
03:32 gfxstrand[d]: redsheep[d]: I don't think we want distros packaging it at all. We should probably hide it behind a build flag so you have to go out of your way to even compile the code.
03:33 gfxstrand[d]: karolherbst[d]: They make .run files. <a:shrug_anim:1096500513106841673>
03:33 karolherbst[d]: well.. they kinda do for rhel and fedora, but it's just installing the files and compiling the kenrel module
03:33 redsheep[d]: gfxstrand[d]: Right, this is what I meant
03:33 x512[m]: Haiku generally prefer the same policy as Windows: stable API provided by shared libraries and unstable protocols, syscalls and UAPI.
03:34 karolherbst[d]: yeah.. if you can just reload the kernel module on the fly it's great
03:34 x512[m]: So Nvidia KMD and NVK will be packaged as one set with hard version check.
03:34 karolherbst[d]: what are you doing while the system is running?
03:35 karolherbst[d]: like imagine automatic updates (which every distro should have these days anyway)
03:35 karolherbst[d]: will it just break? Will it force a reboot?
03:35 karolherbst[d]: will the module get reloaded?
03:35 karolherbst[d]: what are you doing with already running applications when it's reloaded?
03:37 x512[m]: KMD and UMD can be atomically updated. And Haiku can reload kernel modules.
03:37 x512[m]: So ideally it should be possible to update GPU drivers without reboot.
03:38 x512[m]: In worst case package manager can ask for reboot to apply changes on driver update.
03:39 x512[m]: Haiku already delay applying update until reboot when updating base system package that include kernel etc..
03:40 karolherbst[d]: x512[m]: what about already running applications though?
03:41 redsheep[d]: gfxstrand[d]: I get where that comes from for now with it's not even done, but later on if and when it's solid you'd still take issue with distros providing nvk on openrm as an option? The way I see it it doesn't actually compete with Nova, openrm remains something that won't be upstreamed. Assuming nvk similarly just nopes out when the kmd version isn't correct what would be the issue?
03:41 x512[m]: I suppose it should report device lost and reload ICD.
03:41 redsheep[d]: Bugs you don't want to deal with, or some other concern?
03:43 karolherbst[d]: x512[m]: yeah... I mean if all applications would handle that, I just think most will simply crash or do nothing
03:43 karolherbst[d]: redsheep[d]: linux isn't made for it and it's a giant pile of sadness with the blob driver already
03:44 x512[m]: Well, reload of KMD is impossible without telling device lost to every client.
03:44 redsheep[d]: karolherbst[d]: Wouldn't an nvk+zink session on top of openrm be able to lessen some of the pain?
03:44 karolherbst[d]: I'm sure that 2% of all applications deal with device losts in a way that doesn't involve crashing or outright aborting
03:44 x512[m]: At least critical services such as GUI server must survive device lost event and reload UMD and/or switch to software rendering mode.
03:44 karolherbst[d]: redsheep[d]: no
03:45 karolherbst[d]: applications need to handle it
03:45 karolherbst[d]: every application
03:45 karolherbst[d]: like literally every
03:45 karolherbst[d]: except CLI ones
03:45 redsheep[d]: I think we're talking about two different things
03:45 redsheep[d]: I was continuing my reply to faith
03:45 karolherbst[d]: ahh
03:45 karolherbst[d]: same reply tho
03:45 karolherbst[d]: linux ain't made for it
03:46 x512[m]: If some program can't handle device lost, its their problems 🤷
03:47 karolherbst[d]: I agree, and yet....
03:47 x512[m]: If user need to use such programs, driver update should be delayed until reboot.
03:47 dwfreed: so then we're back to the point where driver updates are delayed until reboot anyway
03:47 gfxstrand[d]: redsheep[d]: Support, mostly. Also, why? It's an interesting development tool but apart from people who want NVK and CUDA without rebooting, there's not much point. I doubt NVK will have capabilities on openrm that we don't on nouveau apart from maybe some developer stuff. Meanwhile it just provides another config for users to play with and file bugs about that we have to keep working.
03:47 karolherbst[d]: yeah.. that's the consequence
03:48 karolherbst[d]: it's a hard problem
03:48 karolherbst[d]: it's just that macos and windows forced every application to deal with it
03:48 karolherbst[d]: so they fixed it there
03:48 karolherbst[d]: that never happened on e.g. Linux or anything else
03:49 karolherbst[d]: macos started to migrate apps from discrete to integrated GPU on their laptops like 12 years agp or so
03:49 x512[m]: It is just an excuse of not fixing buggy software.
03:49 karolherbst[d]: so either your app was forced to run on the dGPU (lol battery life) or you supported GPU resets
03:49 x512[m]: MacOS and Windows have better quality control.
03:49 karolherbst[d]: and if you didn't care, you had your users hating you for it
03:50 karolherbst[d]: x512[m]: nah
03:50 karolherbst[d]: that has nothing to do with it
03:50 karolherbst[d]: apple just made it the application vendors problem
03:50 karolherbst[d]: and used their users as a pretty good reason to deal with it
03:51 karolherbst[d]: because if your application causes batter lifetime to get cut in half, you can bet that users will use a different application
03:51 gfxstrand[d]: Meanwhile, Android forces apps to deal with being killed arbitrarily. 😅
03:51 karolherbst[d]: yeah
03:51 karolherbst[d]: those things are partly done in a way to force app devs to deal with it
03:52 gfxstrand[d]: Rotate the device? Just kill the app! Running low on memory? Kill a few apps. Lock the device for a few second? Kill apps!
03:52 karolherbst[d]: though on mobile it does make sense to kill them and go push notifications anyway
03:53 x512[m]: NVRM+NVK will be pretty vital on Haiku.
03:53 karolherbst[d]: like IRC clients generally didn't do that, so they drain your batteries in a couple of hours 🙃
03:53 karolherbst[d]: hence I'm not using IRC on my phone, lol
03:53 orowith2os[d]: All this funny android stuff gets sad when apps also have to deal with nonconformant Vulkan drivers...
03:54 orowith2os[d]: Not even mentioning opengl
03:54 orowith2os[d]: I've seen a nonzero amount of devs swear android out because of it
03:54 gfxstrand[d]: x512[m]: That's fine. If Haiku wants to package it, that's fine. It's up to the Haiku maintainers to make sure the Mesa and openrm versions are compatible. I just don't want to suggest that all the Linux distros do that when there's a perfectly good kernel driver or two in upstream Linux.
03:55 gfxstrand[d]: orowith2os[d]: I think all Android Vulkan devs swear. 😂
03:56 x512[m]: Regular 2D applications don't even need to care about driver reload because rendering is on server side. Client will send drawing commands and server will render it with Skia+NVK.
03:56 x512[m]: Wayland fans will probably hate that.
03:57 karolherbst[d]: there is a reason why no modern OS works like that 😛
03:57 redsheep[d]: gfxstrand[d]: I mean, I think nvk already has a few advantages over nvidia's prop userspace. Friendlier to software that likes mesa, ideally in the long term more often able to demonstrate being faster, especially when cpu bound. Also, at the very least different bugs, if not fewer bugs. When you're banging your head against some wayland nvidia nonsense nvk is really nice, that's what got me
03:57 redsheep[d]: interested in it in the first place, and IIUC has not as much to do with the kernel being different as it is different userspace.
03:58 orowith2os[d]: x512[m]: I'd be curious to know how you keep performance up, unless you also don't care?
03:58 karolherbst[d]: orowith2os[d]: simple UI design
03:58 x512[m]: 2D commands are sent asynchronously in batches.
03:58 gfxstrand[d]: redsheep[d]: Well, if it's an on ramp for people to switch to NVK...
03:58 redsheep[d]: In the future when nova is feature complete and bulletproof that argument will evaporate, but I would rather be able to have nvk on a kmd that is more daily drivable for me right now, rather than just whining that nova isn't here yet
03:59 gfxstrand[d]: Yeah, you do have those crazy display issues... I keep forgetting about that.
04:01 orowith2os[d]: If you ever need help getting mesa going in a container, lmk :thumbsup:
04:01 karolherbst[d]: x512[m]: well that's still more expensive than just drawing 2D client side and notify the server that the shared display buffers were updated
04:01 gfxstrand[d]: orowith2os[d]: I spent two days this week working on that. 😫
04:02 karolherbst[d]: though the big issue is if you need any sort of readback from the rendered buffer
04:02 karolherbst[d]: but if you don't do shadows or anything else fancy, you probably also don't need it
04:03 karolherbst[d]: (or your 2D API gets those things added as APIs)
04:04 orowith2os[d]: gfxstrand[d]: https://GitHub.com/orowith2os/mesa-asahi-flatpak is a good reference example, and newer mesa versions can be based on what asahi ships themselves in the fedora copr
04:04 karolherbst[d]: anyway, I should sleep 🙃
04:04 karolherbst[d]: I can hear the birbs
04:04 orowith2os[d]: Set the network build-option if you don't want to deal with rust deps
04:04 redsheep[d]: karolherbst[d]: I assumed you just woke up early, yeah go to bed
04:04 gfxstrand[d]: orowith2os[d]: But also, it would be interesting to prototype getting the the virtio paravirt stuff with nouveau. IDK how much modification it would take.
04:05 gfxstrand[d]: karolherbst[d]: So should I, like 7 timezones later. 😂
04:05 orowith2os[d]: gfxstrand[d]: Whew, that, I can't help with that :blobcatnotlikethis:
04:05 karolherbst[d]: gfxstrand[d]: it's okay if you all go to bed at like 10 pm and consider this normal 😛
04:05 orowith2os[d]: I'm putting y'all to shame over here. I'm in the hospital, not allowed to sleep yet ;P
04:06 redsheep[d]: orowith2os[d]: Oh no! Hope you're okay
04:06 orowith2os[d]: Just asthma
04:07 orowith2os[d]: Well, I say just asthma, but there's a good chance I have pneumonia too
04:07 orowith2os[d]: And the asthma is making it worse
04:07 redsheep[d]: That sucks. Not being able to breathe right is not terribly enjoyable. I had a cold that took like a month to actually go away earlier this year, wouldn't wish that on anyone
04:07 orowith2os[d]: That's what a facefull of dirt from the bottom of a truck that's been sitting for 10 years will get you...
04:08 gfxstrand[d]: orowith2os[d]: I was definitely hanging out in the Nouveau channel from a hospital bed, hyped up on painkillers back in December. 😂
04:08 orowith2os[d]: Damn. Only difference is, I have steroids, not painkillers
04:08 karolherbst[d]: orowith2os[d]: oh no
04:08 karolherbst[d]: be a rebel and sleep anyway
04:09 orowith2os[d]: I could, but no use when I need to be up for half of what they're coming in here for anyways
04:09 redsheep[d]: orowith2os[d]: At least soon you'll be really buff /s
04:09 orowith2os[d]: I'm really putting these new earbuds to use, with their audio passthrough. I can hear everything around me perfectly, despite having both earbuds in
04:10 orowith2os[d]: I really could just go to sleep and I'll hear when they come in...
04:10 orowith2os[d]: Oh well
04:10 orowith2os[d]: redsheep[d]: I wish :slowpoke:
04:10 orowith2os[d]: It's just tearing up my lungs and heart
04:11 karolherbst[d]: oh no
04:11 orowith2os[d]: Four or five doses of Albuterol, magnesium, antibiotics, epi, and one other steroid I forgot the name of
04:11 karolherbst[d]: hope you won't end up having to use those breathing machines
04:12 orowith2os[d]: Oh, forgot to add. I'm on O2 :hammy:
04:12 karolherbst[d]: sure, but you still breath yourself, right?
04:12 orowith2os[d]: For now
04:12 karolherbst[d]: hope it stays that way
04:12 orowith2os[d]: Definitely
04:13 orowith2os[d]: But I have my laptop, toothbrush, chargers, and God knows what else in my bag. I'm set for the long haul 🔥
04:14 redsheep[d]: karolherbst[d]: Venthilator, yeah when you have to use one of those things aren't going well
04:14 karolherbst[d]: hopefully you'll be able to leave soon
04:14 orowith2os[d]: We'll see
04:15 orowith2os[d]: I'm still in the ER, if I get admitted fully, I probably won't shut up about it :p
04:15 karolherbst[d]: a few weeks ago I was sick enough that apparently my breathing was getting heavier, but luckily it was also over after a day, but yeah..... it was kinda close enough
04:16 karolherbst[d]: like also feeling light headed and all that
04:18 orowith2os[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1355033389299662949/IMG_20250327_180811.jpg?ex=67e774af&is=67e6232f&hm=9693a3970c54b8376b3ded60e1f43fa0e2f6f4acb9ffe704ab48f6503360031e&
04:18 orowith2os[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1355033392051388608/IMG_20250327_180810.jpg?ex=67e774af&is=67e6232f&hm=8969116a11bb43e2a2724b919b64c6485044a4863396dbb064eb054273763d2d&
04:18 orowith2os[d]: O2 in the 80s, heart rate just under 140 bpm :thumbsup:
04:19 karolherbst[d]: oof
04:19 orowith2os[d]: It's a miracle that all I felt was tired
04:19 orowith2os[d]: And hard of breathing. But that's another bag of worms
04:20 redsheep[d]: That's uh... not good. Isn't that blood oxygen low enough that they should be like... doing something more about it?
04:20 orowith2os[d]: That's what the O2 is for
04:20 orowith2os[d]: The pictures were before I went to the ER
04:21 orowith2os[d]: Now I'm sitting at 94-95 O2 and 120bpm
04:21 redsheep[d]: Oh, okay that makes more sense. 86 while on oxygen would be very concerning
04:22 orowith2os[d]: Without O2, I'd be around 90-92%
04:22 orowith2os[d]: :Uueuuue:
04:22 orowith2os[d]: After all their funny steroids and stuff
04:24 karolherbst[d]: anyway.. I should go sleeping 😄
04:24 karolherbst[d]: nini
04:29 orowith2os[d]: I shall, exist in spite of God and the cruel fate I've been dealt
05:13 pavlo_kozlenko[d]: Christian
05:36 x512[m]: karolherbst[d]: Is shadows and other effects will be needed, it will be added as new 2D protocol commands.
05:37 x512[m]: It is also maybe possible to synchronize it with Vulkan timeline semaphores.
05:44 orowith2os[d]: pavlo_kozlenko[d]: Just running off of the hatred of everything
05:44 orowith2os[d]: :wires:
07:03 tiredchiku[d]: changed the deviceName logic
07:03 tiredchiku[d]: now we get NVK NVIDIA GeForce RTX 3070 on openrm
08:35 bigsmarty[d]: orowith2os[d]: Bro is boutta get buff
08:48 asdqueerfromeu[d]: gfxstrand[d]: Especially when doing madnesses 🐸
10:13 tiredchiku[d]: avhe[d]: any idea why
10:13 tiredchiku[d]: NV0080_CTRL_GR_INFO grInfoList[3] = {
10:13 tiredchiku[d]: { NV0080_CTRL_GR_INFO_INDEX_SM_VERSION },
10:13 tiredchiku[d]: { NV0080_CTRL_GR_INFO_INDEX_LITTER_NUM_SM_PER_TPC },
10:13 tiredchiku[d]: { NV0080_CTRL_GR_INFO_INDEX_MAX_WARPS_PER_SM },
10:13 tiredchiku[d]: };
10:13 tiredchiku[d]: NV0080_CTRL_GR_GET_INFO_PARAMS grInfoParams = {
10:13 tiredchiku[d]: .grInfoListSize = 3,
10:13 tiredchiku[d]: .grInfoList = (NvP64)grInfoList
10:13 tiredchiku[d]: };
10:13 tiredchiku[d]: nvRmApiControl(&devRm, pdev->hDevice, NV0080_CTRL_CMD_GR_GET_INFO, &grInfoParams, sizeof(grInfoParams));``` would return data=0?
10:14 tiredchiku[d]: for all 3
10:20 x512[m]: tiredchiku[d]: Worked for me.
10:21 tiredchiku[d]: are you sending it to the device fd or the ctl fd
10:21 x512[m]: Always ctl fd.
10:21 x512[m]: I will probably push completed gather info code today.
10:24 x512[m]: create/delete/control operations work only with ctl fd.
10:26 x512[m]: It identifies GPU by hDevice.
10:26 tiredchiku[d]: right
11:39 asdqueerfromeu[d]: I pushed my attempt at querying device info with OGK here: https://gitlab.freedesktop.org/DodoGTA/mesa-nvk/-/tree/nvk/ogk-sid-base
11:47 tiredchiku[d]: :o rad
11:55 tiredchiku[d]: asdqueerfromeu[d]: XXX: Are the array positions actually stable?
11:55 tiredchiku[d]: they may not be
12:09 x512[m]: It is better to call it NVRM, not OGK.
12:13 esdrastarsis[d]: Let's call it NVOGKRM
12:13 x512[m]: Open or not do not matter, UAPI is the same.
12:14 x512[m]: Someone may want to run it on Pascal etc. with closed KMD.
12:15 asdqueerfromeu[d]: esdrastarsis[d]: And let's call Zink running under NVK with OGK "OGZiNVK" /s
12:22 tiredchiku[d]: asdqueerfromeu[d]: pulled your changes into my tree :)
12:22 tiredchiku[d]: vram_info is broken though, at least on ampere
12:22 tiredchiku[d]: returns 0
12:25 asdqueerfromeu[d]: tiredchiku[d]: I see they definitely aren't dstable (because they're different for Blackwell)
12:25 tiredchiku[d]: pain
12:26 avhe[d]: karolherbst[d]: they have broken essential parts of the ABI in the past
12:26 avhe[d]: like, added fields to NVOS64_PARAMETERS, that's used to allocate kernel objects
12:27 avhe[d]: that was in the early days of ogkm and things are more stable today, but yeah there is no guarantee
12:33 asdqueerfromeu[d]: I'm considering copying the `kgrmgrGetGrObjectType_IMPL()` code (because there doesn't seem a way to access the function to get its `GR_OBJECT_TYPE_*` return value)
12:45 gfxstrand[d]: tiredchiku[d]: I think I prefer having NVK in parentheses at the end. The device name is *Nvidia blah blah blah". That it's running on NVK is more of a side note.
12:45 tiredchiku[d]: yeah, dodo sorted that out 😅
12:56 tiredchiku[d]: okay, MR drafted
12:56 tiredchiku[d]: now unfortunately I'll be away until the 6th :Sad:
12:56 tiredchiku[d]: so called "vacation"
12:57 orowith2os[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34260
12:57 orowith2os[d]: Posting the link here
12:58 orowith2os[d]: :EmmaValCoolCat:
13:00 tiredchiku[d]: :coolroo:
13:09 x512[m]: https://github.com/X547/mesa/commit/0608306449e3e6abcab48dc4e57c8ba4698d0beb
13:09 x512[m]: My version.
13:14 x512[m]: Class detection is how Nvidia KMD does it.
13:38 avhe[d]: tiredchiku[d]: nice work
13:38 avhe[d]: are fences working now?
14:19 tiredchiku[d]: the command buffer semaphore thing? does work yus
14:20 avhe[d]: nice
14:22 tiredchiku[d]: hmm I'm gonna drop dodo's pdev creation code for my own, hers broke vkcube :p
14:36 x512[m]: > nvk/nvrm: Auto-detect hMaxSubmittedMem value based on GPU class
14:37 x512[m]: This is wrong. It is identified by is64bit of NV2080_CTRL_CMD_FB_GET_SEMAPHORE_SURFACE_LAYOUT struct.
14:47 tiredchiku[d]: :birdnotes:
14:47 tiredchiku[d]: got you
14:50 tiredchiku[d]: well
14:50 tiredchiku[d]: does anything below ampere support it being unset?
15:02 tiredchiku[d]: or rather, does anything below ampere support 64bit semsurf
15:25 x512[m]: No need to know, just check flag.
15:26 x512[m]: In practice it seems Ampere+ for 64 bit semaphores.
15:26 x512[m]: But I don't know why 64 bit flag is not set for Turing.
16:04 tiredchiku[d]: how do you check that flag without making a semaphore surface though :doomthink:
16:06 x512[m]: Getting struct with flag is a method of subdevice. No need to create sem-surf to get flag.
16:06 x512[m]: `nvRmApiControl(&rm, pdev->hSubdevice, NV2080_CTRL_CMD_FB_GET_SEMAPHORE_SURFACE_LAYOUT, &pdev->semSurfLayout, sizeof(pdev->semSurfLayout));`
16:06 tiredchiku[d]: I see
16:13 asdqueerfromeu[d]: There were conflict markers left here: <https://gitlab.freedesktop.org/Sid127/mesa/-/commit/804090752756ea4a68c38019e04190c74a0facf6#059d99b2edae5a4b51e79eb38f6f299f37f26831_1145_1145>
16:14 tiredchiku[d]: bah
16:14 tiredchiku[d]: fuck you vscode
16:15 tiredchiku[d]: thanks, fixed
20:39 snowycoder[d]: That's weird: how can `dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp16.input_args.rounding_rte_conv_from_fp64_down` and `dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp16.input_args.rounding_rte_conv_from_fp64_up` produce different results if all its code is identical (even the reported SPIRV?), there's something stupid I'm missing right?.
20:40 mhenning[d]: Different input data, maybe?
20:48 snowycoder[d]: Shouldn't it use different rounding modes in the float conversions?
20:50 mhenning[d]: My guess (just from the name) is that both tests use rte for the rounding mode. The "up" vs "down" at the end might be whether the test data is expected to round up or down
21:25 gfxstrand[d]: Yeah, it's that
21:25 gfxstrand[d]: Also, you need my MR.
21:25 gfxstrand[d]: Let me Marge it quick.
21:25 gfxstrand[d]: They're broken on Maxwell, too, currently.
21:26 snowycoder[d]: Ok so I'm not crazy
21:26 snowycoder[d]: Strange, nvcc is emitting the same instructions for fp64 -> fp16 conversions
21:29 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34126
21:32 gfxstrand[d]: I pulled the Intel patch into its own MR and marged that one. Some of the Collabora folks need it for PanVK.
21:33 gfxstrand[d]: We can also use it for F2I with 8-bit destinations if we want to delete a little code from `nak::from_nir`.
21:33 gfxstrand[d]: I just haven't yet because I didn't feel like plugging in a Maxwell again this week.
21:34 snowycoder[d]: Whenever you do, test my patch too
21:35 gfxstrand[d]: Which patch was that?
21:35 snowycoder[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34137
21:37 gfxstrand[d]: I'm not really working this afternoon so sure, I can CTS that quick. Just gotta pick which card I want to use.
21:37 snowycoder[d]: Don't worry, whenever you have time
21:46 mhenning[d]: gfxstrand[d]: If you do plug one in, please also run hw_tests on that MR
21:47 snowycoder[d]: Yes it should be much faster, I only edited shl64
22:05 gfxstrand[d]: Of course I also need my QMD patches...
22:05 gfxstrand[d]: Sooo many things that need merging... 😂
22:14 gfxstrand[d]: mhenning[d]: Done. 64-bit shift tests still pass
22:21 gfxstrand[d]: Okay, it's running. Maxwell runs take forever, though.
22:42 redsheep[d]: While you have Maxwell plugged in it might be kind of interesting to throw the nvrm branch at the closed kmd and see what happens
22:43 redsheep[d]: Not hugely important but if it just magically works that would be cool
22:43 redsheep[d]: Full speed Maxwell B 🏎️
22:44 redsheep[d]: Though if it's going to work with anything pre-turing it's probably most likely to be volta
22:52 gfxstrand[d]: I have Maxwell A plugged in and the proprietary driver doesn't recognize it.
22:53 redsheep[d]: I thought the latest driver still supports Maxwell A
22:53 gfxstrand[d]: And that system is already in a wonky enough state without trying to also install Nvidia tract drivers. 😂
22:54 gfxstrand[d]: redsheep[d]: IDK. <a:shrug_anim:1096500513106841673> All I know is that I booted and got zero Nvidia devices.
22:54 redsheep[d]: You're sure it's not openrm?
22:54 gfxstrand[d]: Not that I was trying to test the proprietary driver. I've just been mucking about with it this week and that's what booted when I pushed the power button.
22:55 gfxstrand[d]: redsheep[d]: Maybe? I don't remember which one I installed.
22:56 redsheep[d]: It looks like the Nvidia site points you to the latest closed .run for the Maxwell A 750ti https://www.nvidia.com/en-in/drivers/details/242273/
22:56 redsheep[d]: So either their site is wrong or that's openrm which won't work pre-turing
22:58 gfxstrand[d]: In any case, I don't think I'm mucking about with that tonight.
23:00 redsheep[d]: Gonna try to get some Maxwell and Pascal users to try it just to satisfy my curiosity