00:04 mangodev[d]: i'm wondering
00:04 mangodev[d]: is there a table for what mesa shader models correspond to which nvidia architectures?
00:05 mangodev[d]: since most of the instructions related commits are relative to or specific to the shader model
00:05 mangodev[d]: but these definitely don't match up with direct3d shader models
00:05 mangodev[d]: so idk what kind of shader model they could be referring to
00:19 airlied[d]: They refer to NVIDIA shader models, I think there is a table in openrm
00:32 karolherbst[d]: mangodev[d]: I think the easiest to check out is the on wikipedia: https://en.wikipedia.org/wiki/CUDA#GPUs_supported
00:32 karolherbst[d]: (the one after that one
00:33 karolherbst[d]: the "Compute capability" one
00:34 mangodev[d]: karolherbst[d]: oh
00:34 mangodev[d]: didn't know cuda had shader models
00:34 mangodev[d]: good to know
00:34 mangodev[d]: ty
00:36 mangodev[d]: so mine is 7.5 because apparently nvidia wasn't proud enough of turing to make it a whole number 🫠
00:54 mhenning[d]: mangodev[d]: It's typically more about backwards compatibility more than how proud they are
00:54 mhenning[d]: which is to say 7.0 binaries can run on 7.5
01:35 gfxstrand[d]: mangodev[d]: Look at `ShaderModel::is_foo()`
01:40 gfxstrand[d]: That's derived from various bits of information scattered around. Unfortunately, available docs are often incomplete. 😢
01:43 gfxstrand[d]: Like 7.3, which doesn't exist in the above table but which definitely exists because we've found some.
01:43 mangodev[d]: gfxstrand[d]: interesting
01:43 mangodev[d]: i'd think there's a function for fetching shader model, although i haven't done a real dig in the codebase
01:45 mangodev[d]: on that subject
01:45 mangodev[d]: why is NAK (referring to the compiler parts) in rust, but NVK (the part that interacts with the gpu itself) in c?
01:54 orowith2os[d]: I don't think there's very much inside of NVK that would benefit from the whole memory safety thing of Rust, is there?
02:12 mangodev[d]: fair
02:12 mangodev[d]: i was just wondering why the dual language thing
02:12 mangodev[d]: it feels like it makes the code base more cumbersome to use
02:13 tiredchiku[d]: fwiw it made it a bit more welcoming to me, since I'm familiar with C but don't know any rust
02:13 airlied[d]: there is enough common infra in mesa that writing a vulkan driver in rust wasn't worth it at the time,
02:14 airlied[d]: the backend compiler is usually quite self contained, and a lot of the fun stuff is NIR passes written in C
02:17 orowith2os[d]: you might actually get more benefit from C++, since you can use things like generics and std::variant and whatnot with that, and keep all the C API you have in Mesa
02:23 airlied[d]: no nobody benefits from C++
02:23 airlied[d]: except the one place in mesa where we use it for a templated dispatch
02:24 orowith2os[d]: if I need a C-y API, but want some niceties I get from Rust (see: std::variant), I'll run to C++
02:24 orowith2os[d]: but holy shit, it's rough
02:30 HdkR: C unions calling out to be used.
02:31 orowith2os[d]: C unions make me want to commit arson
02:33 HdkR: Slap a union and a type enum in a struct, bam, got yourself a variant.
02:33 orowith2os[d]: I was passing around `void *` everywhere, and had to bring it back to a concrete type. And that type had two different potential types, which also had two different potential types.
02:34 orowith2os[d]: so I had to check that void * for null, then go to a concrete type and hope I didn't mess something up where the types were off enough for it to make the cast wrong. And then hope that I accessed them properly, and didn't cause an exception.
02:35 orowith2os[d]: but if, and only if, the C API I was using supported generics, it would've worked :GA_catgirlheart:
02:35 HdkR: Tagged pointers calling out to be used then :P
02:37 gfxstrand[d]: mangodev[d]: Because I haven't rewritten it yet
02:38 orowith2os[d]: (threatening tone?)
02:38 airlied[d]: I haven't looked but how are we for writing NIR passes in rust these days?
02:38 gfxstrand[d]: We aren't. That really isn't tractable, sadly.
02:39 gfxstrand[d]: NIR is too unsafe.
02:39 airlied[d]: time for SNIR
02:39 airlied[d]: Safer Newer IR
02:40 airlied[d]: wrt NIR not being safe, the IR itself or just the code supporting it?
02:41 airlied[d]: thinking C-NIR, C-NIR, C-serialise, rust-deserialize, rust-nir, rust-nir, rust-serialize, C-deserialize type workflow
02:42 gfxstrand[d]: gfxstrand[d]: It's not that there are no benefits to rust in driver code. I actually wish NVK were in rust basically every time I do anything involving buffer allocation. But there's also a lot of unsolved problems between where we are today and a Rust driver and I didn't want those problems to stand in the way of bringing up and shipping NVK.
02:43 orowith2os[d]: does it even need to be full-on Rust?
02:45 mangodev[d]: orowith2os[d]: ~~blazingly fast 🔥~~
02:45 gfxstrand[d]: airlied[d]: The way NIR implements SSA defs is really hard to make Rust safe since it's all pointers everywhere. Also, linked lists are hell. (That one might be manageable.) In NAK, SSA defs are just numbers. This has the advantage of being Rust-friendly because there's no actual pointers between instructions but it has the disadvantage of making it harder to chase things because you have no
02:45 gfxstrand[d]: pointers between instructions. A lot of NIR's power comes from its ability to chase things.
02:47 gfxstrand[d]: orowith2os[d]: It won't ever be. Not if we want to use the Mesa Vulkan runtime. And one of the big open questions with a Rust driver is how to use the runtime without making a mess. The runtime is full of weird layering violations that make having a unified Rust way of dealing with it really hard, actually.
02:48 gfxstrand[d]: But we can maybe write a shim that isn't too bad to maintain which gets rid of a lot of that. It's just not clear what exactly it should look like.
02:51 orowith2os[d]: that reminds me, I need to figure out openvg stuff too
02:51 orowith2os[d]: I was going to write a gallium driver for it
02:51 orowith2os[d]: and now here I am. writing wayland protocols
02:53 orowith2os[d]: the joys of playing with a khronos api that hasn't been updated since, like, 2008
03:06 airlied[d]: gfxstrand[d]: I was using the kernel rust linked list and it is certainly an exciting journey that makes you yearn for just using a vector
07:47 karolherbst[d]: I ran into an interesting bug today: if I load nouveau on my eGPU where I forgot to plug in aux power, nouveau breaks in very interesting ways... Like the entire system crashes
08:19 magic_rb[d]: Maybe missing a check? Iirc if you dont plug in aux power on a normally installed gpu, itll display a nice message on screen and not work even in the bios
08:50 airlied[d]: karolherbst[d]: try loading nvidia 🙂
08:51 karolherbst[d]: 🙂
08:51 karolherbst[d]: well...
08:51 karolherbst[d]: that was fixed on pre GSP nouveau tho
08:51 karolherbst[d]: GSP fails to load, but I've also seen DMA related errors or something.. though not sure how much can be done about it...
08:52 karolherbst[d]: maybe the detection should be ran before GSP is up and running
08:53 karolherbst[d]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c?h=v6.15-rc4#n175
08:54 airlied[d]: I think that is in the leave it to GSP territory
08:55 airlied[d]: at least I don't see any code in openrm doing it, unless it's hardcoded somewhere
08:55 airlied[d]: NV_ERR_INSUFFICIENT_POWER
08:56 airlied[d]: we should test for gsp init failing with that
09:01 karolherbst[d]: yeah probably
20:04 gfxstrand[d]: Okay, assuming NewEgg doesn't royally screw up, I should have a Blackwell by Wednesday
20:08 HdkR: Newegg royally screwed up with me a couple months ago. I got return scammed, "new" product but was a different thing in the box :
20:10 HdkR: I've decided to try and stay away from both Newegg and Amazon for electronics now. If possible I'm playing it safe with B&H.
20:11 gfxstrand[d]: Sadly, I don't have a lot of options when it comes to 5090s. I'm hoping my NewEgg thing is legit and it looks like it is.
20:12 mohamexiety[d]: HdkR: sadly insanely common. they really don't check for return scams and instead just relist stuff as is
20:13 HdkR: Yea, it's a nightmare when it's a $10k part
20:13 mohamexiety[d]: yeeeah... .-.
20:13 mohamexiety[d]: they're my only option and while thankfully havent had any of that, it's always a concern when I order something
20:14 mohamexiety[d]: (local market is either super messed up with greedy upsells or just outright doesn't have stuff)
20:15 mohamexiety[d]: gfxstrand[d]: but yeah, hope it arrives safe and sound and on time! <a:vibrate:1066802555981672650> ❤️
20:15 mohamexiety[d]: I'll look into the remaining QMD stuff next week and hopefully try to have something ready before you get yours
20:20 airlied[d]: I'll see if I can get to the qmd thing today, but I took yesterday off so got a few other things on the list
20:27 mohamexiety[d]: it's OK, sorry for the trouble 😦