00:07 karolherbst: jStefan: the vbios file will probably be important to track down that bug, but you can find it under "/sys/kernel/debug/dri/0/vbios.rom" on linux
00:08 jStefan: when i got it from there it didn't match the one i extracted on windows, nor the download. is that normal?
00:09 karolherbst: I wonder...
00:13 karolherbst: jStefan: I think the official nvidia tools are packing the vbios in some container format
00:14 jStefan: will i guess i can add both files
00:14 karolherbst: but I don't know if it's compressed or not
00:14 karolherbst: the file extracted on windows is bigger, no?
00:15 karolherbst: but one thing is odd: "bios: 000001a0: NPDE signature (24425948) unknown" and not quite sure if that's causing any issues
00:16 karolherbst: Anyway.. the vbios file you get from that patch is what nouveau is using
00:16 karolherbst: so maybe it's best to attach both
00:18 jStefan: i'll do both, i'll also try nvflash from freedos, to see what it returns.
00:51 mhenning[d]: chikuwad[d]: I don't have a strong preference. Since Faith originally wrote it as modifying the swap variants maybe we should stick with that and defer to her judgement here.
01:51 jStefan: karolherbst, the folder exists, but it is empty (/sys/kernel/debug/dri). the file i got with a mismatch was from: /sys/bus/pci/devices...
01:51 karolherbst: jStefan: it only exists when nouveau was loaded
01:51 karolherbst: or rather there should only be stuff in it when nouveau properly loaded
01:51 jStefan: it should be don't know the state after the crash, maybe if i load it modeset 2?
01:54 jStefan: that sentence, needed a comma (s/be /be, /)
02:01 jStefan: it's populated when i use modeset=2
02:11 jStefan: the file is the same size but the sha256sum is different
02:57 karolherbst: jStefan: that's.... odd
02:58 karolherbst: I wonder if we just pick the wrong method of fetching the vbios, because there are always multiple or something
03:00 karolherbst: jStefan: your GPU has two DVI and one HDMI connector, right?
03:00 jStefan: yes, two DVI-I and a mini-hdmi
03:01 jStefan: it seems to be getting the same signature from pramin and prom
03:01 karolherbst: anyway, I'd be curious to see the vbios file you fetched from windows
03:08 jStefan: i added it the original ticket, it now has both files
06:03 chikuwad[d]: mhenning[d]: alrighty, pushed that
09:49 phomes_[d]: karolherbst[d]: +1 fps in lego builders journey
10:56 marysaka[d]: airlied[d]: _lyude[d] Would it be okay to upstream some unstable ioctls hidden behind a module parameter to allow requesting GSP handles and sending control requests? Asking because I'm typing something like that to poke at some control methods in a quicker way and I know that panfrost kernel module also have some unstable ioctls hidden behind "unstable_ioctls" parameter
10:58 airlied[d]: My first reaction is ick and I don't like it
10:59 marysaka[d]: (I would be honest I hate that too tbh... worst case I keep the patch some tree if people want to poke at that anyway)
10:59 airlied[d]: Since it's just open for abuse and forums with people doing stupid shit and then complaining when a new fw messes it up
11:00 chikuwad[d]: are we enabling nouveau.atomic by default already btw?
11:02 airlied[d]: Not sure, @lyude was going to look at atomic by default
11:02 marysaka[d]: airlied[d]: yeah now that I think about it let's not... I will just keep the patches somewhere if people are doing dev around 🫠
11:03 airlied[d]: Having the patches would be good, then someone will provide a nouveau cuda compat ioctl which is just openrm api
11:12 mohamexiety[d]: airlied[d]: what does this mean?
11:14 chikuwad[d]: patches would enable someone to implement a CUDA compatibility interface in nouveau
11:14 chikuwad[d]: by wrapping around openrm API
11:16 airlied[d]: Nouveau providing /dev/nvidia :-p
11:16 chikuwad[d]: yeh
11:34 mohamexiety[d]: ah yeah
11:43 notthatclippy[d]: marysaka[d]: Wouldn't debugfs be a better match here?
11:57 karolherbst[d]: phomes_[d]: mhhh.. yeah that's not really worth it 🙃
12:16 marysaka[d]: notthatclippy[d]: that could also work yeah just would need to provide the drm fd to get specific client / device / subdev handles I guess
12:16 marysaka[d]: trying to type something that work first will see how it goes 😅
13:09 karolherbst[d]: marysaka[d]: maybe it makes more sense to have the common infra in place on the kernel side to make them proper IOCTLs for useful things? I suspect wiring it all up generally is most of the code here?
13:22 marysaka[d]: karolherbst[d]: not quite sure tbh... the actual control call is easy to wire up but the real issue is finding the handles you want to use as they are a bit everywhere
13:23 karolherbst[d]: marysaka[d]: yeah, I mean all the ioctl to GSP RPC call code would be common among all of those, no?
15:37 notthatclippy[d]: IMO, admin-only, module param gated fwctl that just sends the raw RPC payload and gets it back. Failing that, same thing through debugfs
15:38 notthatclippy[d]: You really want to be able to do arbitrary RPCs from userspace when testing stuff and not needing to patch nouveau for each thing. You also definitely do not want anyone who's not actually developing stuff to ever touch these
20:30 mangodev[d]: most of my issues are just minor ones that stack up and cause breakage
20:30 mangodev[d]: such as emojis refusing to render in the desktop
20:30 mangodev[d]: (except the purple splat emoji?)
20:30 airlied[d]: _lyude[d]: libdrm_nouveau or libdrm ?
20:32 _lyude[d]: airlied[d]: I'm not sure! I didn't realize they were two separate things, I'm mostly just trying to figure out what mutter would be using for gem allocations
20:32 airlied[d]: pretty sure we stopped using libdrm_nouveau in mesa
20:32 _lyude[d]: cool
20:32 airlied[d]: it would all go via gbm
20:33 _lyude[d]: yeah - I'm suspicious there might be some funny uninit memory usage in userspace, because so far at least I haven't been able to find any suspicious looking bits in the kernel that would explain why we randomly get cursor allocations with linearblock info
20:40 mhenning[d]: nvk doesn't use libdrm_nouveau and never has
20:40 mhenning[d]: the old gl driver still uses a copy of libdrm_nouveau that's in the mesa tree
20:41 mhenning[d]: the non-mesa libdrm_nouveau copy can still be used by the nouveau ddx on older gpus
20:41 mhenning[d]: but the short version is that on turing+, libdrm_nouveau is basically gone
20:46 karolherbst[d]: we should probably sunset the nouveau ddx on anything that has a GL driver 🙃
20:53 airlied[d]: _lyude[d]: I'm not across the atomic state flowchart, but could the nv50_wndw_atomic_check_acquire and nv50_wndw_prepare_fb have some race?
20:53 airlied[d]: since one is where we setup a bunch of info about object, but the other is where it picks up the object offset
20:57 karolherbst[d]: okay.. phomes_[d] showed me some blob shaders and they are doing something "interesting" there: because they use the bindless UGPR form of tex, they can use `.scr` more often...
20:58 karolherbst[d]: but it's a pain, because the UGPR handle is a vec2
20:58 karolherbst[d]: and has a different format than the GPR bindless handle
20:59 karolherbst[d]: and I'm wondering how to fit that properly into NAK 🙃
21:10 karolherbst[d]: more strangely.. they seem to keep .lb around with a bias of 0?
23:53 _lyude[d]: airlied[d]: aaaaaaaaaaaaaaaaa i think you're possibly on to something here
23:54 _lyude[d]: ...maybe. actually I'm not so sure now, though, I'm not sure this would really explain how we're seeing framebuffer creations from userspace that seem to specify tiling info for what is clearly intended to be a cursor buffer
23:55 airlied[d]: it was just something I noticed while reading that code for other stuff