00:09 Lyude: it almost worked but then complains it's an unsafe fn and it expected a safe one :(
00:09 Lyude: I think I've probably just got to wrap it
00:10 uhaabergen: I see you from abortion leftover terrorist type of birth ill aids carriers have turned into full scale stand up comedians , very entertaining i especially liked that part where karolherbst the fair to say artist of rusticl bugwork is using akick on both of his braincells. It's as funny as 50line java traces i assume. Sid s newcomer to this comedy show , nice abortion leftover , me i like but i bet your comedians have no functional audience,
00:10 uhaabergen: just like in cambodia where functional parasites despised all the tourists away.
00:10 Lyude: buddy we're busy
00:10 karolherbst: Lyude: huh? that shouldn't really change much...
00:10 karolherbst: Lyude: https://godbolt.org/z/zzh6n3TfM
00:10 Lyude: sigh making me have to remember how to ban people
00:10 karolherbst: just add unsafe to the cast
00:11 karolherbst: msg ChanServ akick #nouveau add $user $reason
00:11 Lyude: well he was polite this time
00:12 Lyude: LMAO
00:12 Lyude: karolherbst: anyway that worked!! thank you
00:24 fdobridge_: <r​hed0x> is there an established workflow + tool for dumping and disassembling shaders from the proprietary driver?
00:32 fdobridge_: <b​enjaminl> ime https://gitlab.freedesktop.org/gfxstrand/nvdump is the easiest
00:32 fdobridge_: <r​hed0x> rust :happy_gears:
00:33 fdobridge_: <b​enjaminl> doesn't work on pre-SM70 without some modifications, and also doesn't work on the newest proprietary driver
00:33 fdobridge_: <r​hed0x> what's SM70? tiring?
00:33 fdobridge_: <r​hed0x> what's SM70? turing? (edited)
00:34 fdobridge_: <b​enjaminl> for disassembly, nvdisasm from the cuda ptx tools _usually_ works, although it doesn't support all instructions and sometimes fails if you have sched it doesn't like
00:34 fdobridge_: <b​enjaminl> volta+
00:35 fdobridge_: <r​hed0x> that's fine, I have an ampere gpu
00:35 fdobridge_: <b​enjaminl> for stuff that nvdisasm doesn't work with, envydis from https://github.com/envytools/envytools sometimes works
02:10 karolherbst: Lyude: does the linux rust kernel stuff allow you to write rust like unit tests?
13:27 fdobridge_: <d​wlsalmeida> not that I remember
13:28 fdobridge_: <d​wlsalmeida> @karolherbst coming back to yesterday's question about drf macros, do you know what this is ? `MW(98:96)`
13:28 fdobridge_: <k​arolherbst🐧🦀> it's simply the bits
13:28 fdobridge_: <d​wlsalmeida> `#define MW(x) x` doesn't really help
13:28 fdobridge_: <k​arolherbst🐧🦀> like the QMD thing is a huge buffer
13:29 fdobridge_: <k​arolherbst🐧🦀> and `MW(98:96)` simply means that the field has 3 bits starting at 96
13:29 fdobridge_: <d​wlsalmeida> yeah, but also a lot of fields are defined without this MW macro, e.g.: `#define NV9097_TEXHEADV2_0_COMPONENT_SIZES 5:0`
13:30 fdobridge_: <k​arolherbst🐧🦀> yeah.. depends on the header
13:30 fdobridge_: <k​arolherbst🐧🦀> nvidia isn't very consistent here
13:30 fdobridge_: <k​arolherbst🐧🦀> don't think too much about it, there is no reason behind it really
13:30 fdobridge_: <k​arolherbst🐧🦀> all those headers do is to define where specific values live and what potential values are
13:30 fdobridge_: <d​wlsalmeida> I see
13:30 fdobridge_: <d​wlsalmeida> ty!
13:32 fdobridge_: <k​arolherbst🐧🦀> I _think_ nvidia also has some header to parse those things and they might have put some more docs there, but... in the end it doesn't really matter. Most of the `dnf.h` file is just to deal with that madness of how they define those things
13:32 fdobridge_: <k​arolherbst🐧🦀> sadly they don't really have anything XML based, but some prop internal format, so they can't give us that
13:38 fdobridge_: <r​inlovesyou> Sorry to bother, what's the verdict? Would love for this to get reported
13:40 fdobridge_: <r​inlovesyou> Sorry to bother, what's the verdict? Would love for this to get reported & fixed (edited)
14:52 fdobridge_: <a​verne> they use it when the bitfield crosses word boundary (MW: multi word)
14:52 fdobridge_: <a​verne> it's explained here <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/bb2dac1f20a06f78e028c4acdc4df1c7908dd91c/kernel-open/common/inc/nvmisc.h#L366-L374>
16:00 Lyude: karolherbst: I would certainly hope so but I haven't tried yet
16:01 Lyude: I don't see why not though
16:09 karolherbst: Lyude: because $build_system_foo
17:22 fdobridge_: <!​DodoNVK (she) 🇱🇹> I haven't even rebooted yet
17:22 fdobridge_: <r​inlovesyou> haha all good
17:23 fdobridge_: <r​inlovesyou> just excited to get it working with GSP, would make nouveau already more viable for VR than proprietary, that explodes with monado currently
17:24 fdobridge_: <r​inlovesyou> just excited to get it working with GSP, would make nouveau already more viable for VR than proprietary, that explodes with monado currently (I've only been able to run xrgears on it) (edited)
18:01 fdobridge_: <p​avlo_it_115> Hello! What are your current plans for nvk? Will it be enabled by default in mesa and will zink be used by default instead of the gallium driver?
18:20 fdobridge_: <r​inlovesyou> i think it just weirdly worked with gsp
19:10 fdobridge_: <g​fxstrand> I'm traveling this week but hope to drop the -experimental in the next couple of weeks. It should be shipped in Fedora 40. IDK about other distros. There are already Arch packages but I suspect it won't take the official ones long to enable it.
19:11 fdobridge_: <g​fxstrand> As for Zink, that's the current plan but there are bugs we still need to figure out. We also have no experience shipping it as the default GL driver so there may be hidden issues with compositors or whatever.
19:16 fdobridge_: <r​inlovesyou> yeah it just works™️ after unplugging and replugging my headset
19:16 fdobridge_: <r​inlovesyou> go figure
19:19 fdobridge_: <b​abblebones> Same issue the binary has 🤔
19:20 fdobridge_: <r​inlovesyou> now we just need working displayport audio
19:20 fdobridge_: <r​inlovesyou> :Hehe:
19:33 Lyude: karolherbst: any idea how I would take the *mut bindings:drm_plane_state and cast it back to a Pin<Box<PlaneState<T>>? should I just transmute or something?
19:33 Lyude: oh oops forgot to link the code
19:33 Lyude: https://gitlab.freedesktop.org/lyudess/linux/-/blob/rvkms/rust/kernel/drm/kms/plane.rs?ref_type=heads#L164
19:47 karolherbst: Lyude: you can't
19:48 karolherbst: if you need the Pin<Box<T>> thing you should rather just pass that around instead of the raw pointer
19:49 karolherbst: on some structs there are pairs to convert to/from a pointer, but that's mainly to "leak"/"reclaim" the pointer and is its own thing
19:49 karolherbst: like Box::into_raw + Box::from_raw
19:50 karolherbst: but you can't really create a Box from a pointer which hasn't revoked ownership (through e.g. Box::into_raw)
19:54 karolherbst: Lyude: though _if_ the passed in pointer was created via Box::into_raw, you could do `pin!(Box::from_raw(...))` probably
19:56 Lyude: karolherbst: so am I right in assuming then what I've got for duplicate_state is probably wrong?
19:58 uhaabergen: 500-256 is 244 and addend is 256-12 is 244, so if one adds index sum is 500+244 is 744, if not 244*2 is 488 so incidentally one can push to eliminator 256 once and 1024 by 128-1 times on 128 wide banks. where indexes are from 128 to 256 that would add 280 128-1 times and 12 one time or times one. in other words now you can 244+12 is 256 280+244 is 524, and that is the very shortest, so the filter pass is where no indexes are pushed as final
19:58 uhaabergen: step, where first only one index was pushed. I would advise to do this way, its the very shortest and very fastest, full hierarchy of banks also is done exactly so. But it smells after ban now, and i gotta go anyways.
20:02 karolherbst: Lyude: well.. at least atomic_duplicate_state_callback does leak memory
20:03 karolherbst: normally if you want to transfer ownership of a heap allocation via Box you hand over the object via Box::into_raw from the rust side (which only works if you also are responsible of freeing it later)
20:04 karolherbst: but here you aren't even transfering `new` to anything, so you just leak memory becuse Box::drop is never called
20:05 Lyude: even though we transfer out the pointer inside of new? (which, should be at 0 offset)
20:06 karolherbst: I mean.. if you reconstruct the original pointer late, that should be fine, though I'd add explicit interfaces for that
20:06 karolherbst: but the normal way of transfering a Box to the C side is via Box::into_raw()
20:06 karolherbst: however.....
20:07 karolherbst: the way C does subclassing I could see this getting annoying
20:07 Lyude: tbh I think into_raw/from_raw() should be fine? someone else is pointing out I might not need this pinned anyway, I sort of assume I would have in case any sort of list is getting initialized in the state
20:08 karolherbst: I'd just add into_raw/from_raw methods to `PlaneState` which translate to/from *mut bindings::drm_plane_state
20:09 karolherbst: and with from_raw you'll get your Box back
20:09 karolherbst: does the kernel rust stuff have offset_of helpers?
20:09 karolherbst: or uhm.. container_of?
20:09 karolherbst: would be better to use that instead of requiring the base to be at 0
20:10 Lyude: gotcha
20:11 karolherbst: mhhh
20:12 karolherbst: I bet you'll have to fight a lot of C-ism here to make it all nice :'(
20:12 Lyude: i'm ok with that!
20:12 Lyude: honestly this is still way less painful then I thought it was going to be
20:12 karolherbst: :D
20:12 karolherbst: fair
21:00 Lyude: karolherbst: maybe https://doc.rust-lang.org/std/boxed/struct.Box.html#method.into_pin would have been what I wanted?
21:01 karolherbst: Lyude: that's just constructing a Pin, which really doesn't do much here
21:01 karolherbst: the problem is creating that Box
21:02 Lyude: gotcha
21:26 fdobridge_: <!​DodoNVK (she) 🇱🇹> What queue priorities does nouveau support? :nouveau:
21:33 foxbat: is there any low power nvidia card that has good support from noevau? I mean generally vaapi and wayland ?
21:39 fdobridge_: <a​irlied> no queue priorities yet, feel free to figure it out and submit patches
21:58 Lyude: karolherbst: iirc you said one of the big reasons so many structs in the kernel are pinned is because of trying to avoid stack overflows right?
21:59 karolherbst: Lyude: no. Pin basically just prevents the value being moved elsewhere
21:59 karolherbst: emphasize on _value_
22:00 karolherbst: e.g. swapping two values. Each location remains valid, but the _values_ got moved. Pin prevents that
22:00 karolherbst: it's to ensure that the pointer keeps pointing to the same _value_
22:00 Lyude: gotcha, which is also to say we only really need Pin then if we're dealing with a type that has pointers that point to it?
22:01 Lyude: e.g. from the C side of things
22:01 karolherbst: it can also be a reference. But it's more of a "prevent programming mistakes" thing than anything else
22:01 karolherbst: like.. in C you could also just swap values of two structs
22:01 karolherbst: but anything pointing to them might become inconsistent after that
22:02 karolherbst: like.. imagine you have something pointing into the 2nd element of an array, but something else just reorders that array
22:02 karolherbst: you _might_ want to have the 2nd element regardless, or you rather saves "ahh, the value I was interested in, was at the 2nd index"
22:03 karolherbst: pin prevents bugs messing up with the latter
22:03 i509vcb: Although it's Rust Pin, this does explain some of the workings around why you'd want pinning in general as well: https://doc.rust-lang.org/std/pin/index.html
22:05 karolherbst: I'm convinced that Pin is overused in the kernel...
22:05 Lyude: karolherbst: gotcha, so I was understanding it correctly before at least-Yes!!
22:05 Lyude: ok
22:05 Lyude: i think it is because i've been trying to figure out why half these structs are pinned that don't seem to need it
22:06 karolherbst: yeah...
22:06 Lyude: which is why I keep getting confused :(
22:06 karolherbst: Pin makes less sense in an environment where the memory location is already the identity of an object, which is generally the case in C
22:07 karolherbst: so "moving" a value is already a bug on its own
22:07 Lyude: so then I think I understand - I would want the drm_plane abstraction (Plane) to be Pin<> since it does get referred to via pointer in the drm device's struct, but drm_plane_state (PlaneState<T>) can probably avoid being pinned since there's really only two locations I can find where we'd have ownership of the data
22:07 Lyude: which is creation and destruction
22:08 karolherbst: yeah... if nothing never actually stores a pointer to it it's kinda pointless to pin
22:09 Lyude: mhm. we have pointers to atomic states, but those are only really made once we hand the state off - and then we'll see pointers to it again during atomic_check and such, but those will still be owned by the kernel
22:10 karolherbst: I think my biggest problem I have with Pin in ffi use cases is, that in practise everything has to be Pin, because some C code stores a pointer to it
22:10 karolherbst: *store
22:12 karolherbst: but anyway.. then there is Pin::set and you can do whatever anyway
22:12 karolherbst: dunno.. Pin feels entirely pointless to me
22:13 Lyude: fwiw, I know that it's a thing partially because having types be movable by default allows for a lot of fun optimizations
22:13 karolherbst: yeah sure, but Pin doesn't prevent any of that
22:15 karolherbst: in ultimate technical terms, Pin prevents you from getting a &mut reference to the object
22:15 karolherbst: you can still call &mut self methods tho
22:15 karolherbst: you just can't do mem::swap on it
22:15 karolherbst: so if you want to swap pinned values, you just implement a swap method on the Type and can do it anyway
22:25 Lyude: karolherbst: for &mut self methods with Pin it's Pin<&mut T> right?
22:27 karolherbst: mhh indeed
22:27 karolherbst: guess it does prevent getting a &mut self ref
22:29 karolherbst: Lyude: https://godbolt.org/z/GeKsYxfTT 🤷
22:32 karolherbst: but anyway.. I think enforcing interior mutability by preventing random code to mess things up is a good idea anyway
22:34 karolherbst: though Pin is kinda pointless for structs which are Copy or Clone
22:34 karolherbst: so yeah..