00:59fdobridge: <airlied> @gfxstrand does 24916 make sense?
01:01fdobridge: <gfxstrand> IDK. Is that what other drivers do?
01:02fdobridge: <airlied> seems to be
01:04fdobridge: <gfxstrand> Okay then
01:08airlied: dakr: didn't make it through a full cts run
01:09airlied: one of my cpu's got stuck
01:09airlied: https://paste.centos.org/view/raw/520f3aef
08:59dakr: airlied: updated the branch, should be fixed.
15:17sravn: gfxstrand: Thanks for the nice mini-blog on mastodon - https://mastodon.social/@gfxstrand@mastodon.gamedev.place/110982162976578240
15:59fdobridge: <gfxstrand> 😄
15:59fdobridge: <gfxstrand> FYI all: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998
16:01fdobridge: <gfxstrand> Now to pull out the NIR bits into their own MR.
16:02fdobridge: <gfxstrand> There's not many. Just a few intrinsics and texops
16:03fdobridge: <karolherbst🐧🦀> I wonder if at this point it makes sense to move some abstractions into core mesa bits, but might also not make much sense at this point
16:05fdobridge: <gfxstrand> What abstractions?
16:07fdobridge: <karolherbst🐧🦀> no idea, you seem to use some nir functions, but maybe you just call into them directly and doesn't have any wrappers
16:07fdobridge: <karolherbst🐧🦀> uhm.. meant nir wrappers, not abstractions
16:11fdobridge: <gfxstrand> Some of the wrappers can probably be eliminated at this point. There was a bunch of stuff for dealing with `is_ssa` but that's gone now.
16:12fdobridge: <gfxstrand> Some of it is just making NIR more rust friendly for things like iteration. Oh, and turing src arrays into slices safely.
16:12fdobridge: <karolherbst🐧🦀> yeah...
16:12fdobridge: <gfxstrand> Mostly, I didn't want any unsafe code in my NIR -> NAK pass.
16:12fdobridge: <karolherbst🐧🦀> I have some wrapper class around `nir_shader` to generate iterators over variables and stuff
16:12fdobridge: <gfxstrand> Yeah, I stole your wrapper. 😛
16:12fdobridge: <karolherbst🐧🦀> and call passes
16:12fdobridge: <karolherbst🐧🦀> 😄
16:12fdobridge: <karolherbst🐧🦀> you could upstream your changes
16:12fdobridge: <karolherbst🐧🦀> and we could move it around
16:12fdobridge: <gfxstrand> Thing is.... the way NAK is using NIR and the way Rusticl is using NIR are very different.
16:13fdobridge: <gfxstrand> The wrappers I have in NAK assume everything is immutable.
16:13fdobridge: <karolherbst🐧🦀> yeah... fair enough
16:13fdobridge: <karolherbst🐧🦀> but that shouldn't be a problem in theory
16:13fdobridge: <karolherbst🐧🦀> but I also haven't looked
16:13fdobridge: <karolherbst🐧🦀> so don't know
16:15fdobridge: <gfxstrand> I think you could even make some of it mutable-safe if you assume that the user will never poke at pointers.
16:15fdobridge: <karolherbst🐧🦀> yeah... I mean most of the methods touching the pointers are already `&mut` like the passes
16:16fdobridge: <gfxstrand> The other big problem is that things like `NirSrc::is_const()` require chasing SSA values and that totally blows up Rust's reference tracking.
16:16fdobridge: <karolherbst🐧🦀> mhhh
16:16fdobridge: <karolherbst🐧🦀> if you could pull out all the nir wrapper code into its own series/patches/whatever I could probably take a look and see if anything could be improved here
16:17fdobridge: <gfxstrand> It's all in one patch
16:17fdobridge: <karolherbst🐧🦀> ahh okay
16:17fdobridge: <gfxstrand> I just keep squashing stuff into the one patch
16:19fdobridge: <gfxstrand> But, yeah, making NIR Rust-accessible is something we probably want to do. It's just going to take some time and thought. I may also need to do a little digging into bindgen to see if we can control it a bit more.
16:20fdobridge: <karolherbst🐧🦀> yeah...
16:20fdobridge: <gfxstrand> Like, if there were some way that we could decorate exec lists to make it generate a different type or something.
16:20fdobridge: <karolherbst🐧🦀> I was using a pretty old version of bindgen and there might be some new features worth using
16:20fdobridge: <karolherbst🐧🦀> mhhh
16:20fdobridge: <karolherbst🐧🦀> maybe?
16:20fdobridge: <karolherbst🐧🦀> but maybe that will also need C23 🙃
16:21fdobridge: <gfxstrand> C23?
16:21fdobridge: <karolherbst🐧🦀> yeah.. it added interesting features for those things
16:22fdobridge: <karolherbst🐧🦀> it also fixes the entire enum mess
16:22fdobridge: <karolherbst🐧🦀> adds typed enums
16:22fdobridge: <karolherbst🐧🦀> C23 is actually quite huge
16:24fdobridge: <karolherbst🐧🦀> but probably will take 10 years until we can use it inside mesa 😄
16:24fdobridge: <gfxstrand> So, bindgen has a type replace thing: https://rust-lang.github.io/rust-bindgen/replacing-types.html
16:24fdobridge: <gfxstrand> But it doesn't look like that will work for what we want because it just replaces one type with another. It can't re-type a single variable.
16:24fdobridge: <karolherbst🐧🦀> ohh.. interesting
16:26fdobridge: <karolherbst🐧🦀> but yeah...
16:26fdobridge: <karolherbst🐧🦀> I don't think it's a major problem to just type it in the rust wrapper
16:26fdobridge: <karolherbst🐧🦀> but yeah...
16:27fdobridge: <gfxstrand> What I'd like to do is be able to replace `struct exec_list` with `ExecList<nir_instr, 8>` where 8 is the offset to the node or something like that.
16:27fdobridge: <karolherbst🐧🦀> maybe @lingm knows something
16:28fdobridge: <gfxstrand> The other problem is that, thanks to the Meson mess with bindgen, we can't ever make a field private.
16:28fdobridge: <gfxstrand> If I could make the bindgen stuff and the wrappers be in the same crate, we could make things private and hide a lot of dangerous details.
16:29fdobridge: <gfxstrand> Here's a crazy thought.... Have bindgen generate nir_h.rs and then have a nir_impl.rs file and then use `cat` to paste them together and compile that.
16:29fdobridge: <gfxstrand> It's horrible but it'd work.
16:29fdobridge: <karolherbst🐧🦀> yeah there was an idea like that
16:30fdobridge: <karolherbst🐧🦀> you can also just copy the source files into the generated directory and have it as one crate
16:30fdobridge: <karolherbst🐧🦀> I think that's even supported?
16:31fdobridge: <karolherbst🐧🦀> maybe not...
16:31fdobridge: <karolherbst🐧🦀> but I think there were patches for it
16:31fdobridge: <karolherbst🐧🦀> that's kinda the official way of doing it btw 🙃
16:31fdobridge: <karolherbst🐧🦀> using `includue!` to just include the generated file
16:31fdobridge: <karolherbst🐧🦀> *include
16:32fdobridge: <karolherbst🐧🦀> but you have to give it a path
16:32fdobridge: <karolherbst🐧🦀> and that's non trivial if your build directory is wherever
16:32fdobridge: <karolherbst🐧🦀> and meson upstream decided they don't want to have a wrapper around bindgen to inject arbitrary env variables
16:33fdobridge: <gfxstrand> Honestly, `cat` isn't horrible.
16:33fdobridge: <gfxstrand> I mean, it's horrible, but it's not that horrible.
16:33fdobridge: <karolherbst🐧🦀> developing that stuff is just annoying
16:34fdobridge: <karolherbst🐧🦀> because... your IDE/tool/whatever can't really help you with auto completion and stuff
16:35fdobridge: <karolherbst🐧🦀> I don't think we have to expose the raw C types everywhere and it's fine to have our own wrappers. If performance is critical we just use `repr(transparent)`
16:35fdobridge: <karolherbst🐧🦀> and then you can just `mem::transmute` or whatever
16:37fdobridge: <karolherbst🐧🦀> I think I kinda came to terms not being able to have it all in one crate
16:44fdobridge: <gfxstrand> I think for NIR wrappers, doing a cat trick is probably good enough.
16:45fdobridge: <gfxstrand> That would let us make dangerous fields private and then expose them through helper functions.
16:45fdobridge: <gfxstrand> I think that would go a long ways towards making me feel more comfortable with having something in src/compiler/nir.
16:45fdobridge: <karolherbst🐧🦀> yeah.. maybe
16:46fdobridge: <gfxstrand> Making NIR so it's safe to mutate from Rust is a much bigger challenge.
16:46fdobridge: <gfxstrand> Calling passes isn't so bad but IDK how I feel about it.
16:47fdobridge: <karolherbst🐧🦀> the bigger problem is just that static inline mess
16:47fdobridge: <gfxstrand> With NAK, I kept all the NIR passes in C and once it hits Rust, it's all immutable.
16:47fdobridge: <gfxstrand> Yes and no. There's not much that's static inline and most of it we want to rustify anyway.
16:47fdobridge: <karolherbst🐧🦀> but yeah.. poking a bit deeper into the nir is kinda... hard
16:47fdobridge: <gfxstrand> Like returning option instead of NULL or assert.
16:48fdobridge: <karolherbst🐧🦀> ohh.. I was more thinking about e.g. sharing the `NIR_PASS` stuff
16:48fdobridge: <karolherbst🐧🦀> ended up just reimplementing it
16:48fdobridge: <gfxstrand> Yeah... that's a macro. Translating macros probably isn't something bindgen will ever be able to do.
16:49fdobridge: <karolherbst🐧🦀> but there are some annoying static inlines I also have to use
16:49fdobridge: <gfxstrand> And, again, ther's reasons why nak_nir.c exists and isn't written in Rust. 🙂
16:49fdobridge: <karolherbst🐧🦀> nothing terrible to port
16:49fdobridge: <karolherbst🐧🦀> but I like to keep things consistent on both sides 😄
16:50fdobridge: <karolherbst🐧🦀> yeah.. all I do is to run passes and iterate over variables, but the rusticl custom pass is also written in C
16:53fdobridge: <karolherbst🐧🦀> I do however wonder if my way of code review of NAK will be to port it over to pre turing 🙃
17:28fdobridge: <gfxstrand> @marysaka is already working on SM50
17:40fdobridge: <karolherbst🐧🦀> cool!
18:47fdobridge: <gfxstrand> The state of rust documentation and sphinx is making me sad. 😭
19:44fdobridge: <karolherbst🐧🦀> just use rustdoc 😄
19:53fdobridge: <gfxstrand> Yeah, that's my plan.