01:44phomes_[d]: gfxstrand[d]: after many many experiments without success I finally got it. They do just go by the vendor id. I am so sad right now. Learned a bit about buffer allocation though...
01:57gfxstrand[d]: Ugh... That sucks.
01:57gfxstrand[d]: I wonder if there's a reason for that and why they're allocating wrong. 🤔
02:04phomes_[d]: I could reach out and ask them it has been a few years since the last update of the game so I doubt I will get anyone to look at it
04:01orowith2os[d]: gfxstrand[d]: question, did you happen to know where kernel devs get their hands on the DP spec to use it in kernel drivers?
04:05airlied[d]: the original DP spec was public afair
04:06airlied[d]: otherwise usually ends up being developed by companies with vesa membership
04:08orowith2os[d]: I'm seeing some copies of it on the internet for 1.0 and 1.2, but nothing other than those
04:08orowith2os[d]: it's hard to find
04:08orowith2os[d]: I just emailed VESA about it on a whim
04:09airlied[d]: I think X.org looked at vesa membership once, but something happened to it
04:10airlied[d]: there was a time x.org members could also apply, but I think that didn't get sustained
04:11airlied[d]: is there something specific you want to know? it's not like the core of the DP code isn't all there
04:15orowith2os[d]: it's just a matter of me being curious about the spec itself
04:15orowith2os[d]: and not the code used to implement it
04:16airlied[d]: well the 1.0 spec is the core of it still
04:24gfxstrand[d]: phomes_[d]: No need. We can throw a vendor ID hack in driconf and move on.
04:26gfxstrand[d]: We did hook that up, didn't we? I'm pretty sure I reviewed that driconf patch. If not, it should be easy enough.
07:26asdqueerfromeu[d]: mhenning[d]: The GTX 1650/TU117 has an older Volta video block for example
08:38phomes_[d]: gfxstrand[d]: I created a MR for it https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32764
12:44phomes_[d]: on to the next game crashing...
12:44phomes_[d]: how do we interpret the errors in gsp like this one?
12:44phomes_[d]: gsp: rc engn:00000001 chid:112 type:31 scope:1 part:233
14:59gfxstrand[d]: phomes_[d]: Thanks! Add tags and I'll merge.
15:01gfxstrand[d]: phomes_[d]: Those are hard. You can grab the GSP logs and hand them off to Ben and see if he can look codes up for you. Also, the kernel branch for the next GSP version has some better logging which may help. But I can't tell you anything from that message, sadly.
15:13phomes_[d]: Thank you. I have added the tags now
15:26dwlsalmeida[d]: Yeah, the log parser is your best bet, helped me a ton actually
15:58karolherbst[d]: interesting... https://sourceware.org/pipermail/gdb-patches/2024-December/214029.html
15:59karolherbst[d]: I wonder if we can convince nvidia to upstream theirs 🙃
16:00karolherbst[d]: and figure out if it could be done in a way for nouveau to plug into it
16:12gfxstrand[d]: dwlsalmeida[d]: Paste in the latest and say where you got it (including git SHA) in the commit message.
16:14notthatclippy[d]: karolherbst[d]: 83de is the class you want, but it is probably the single biggest cause of hacks and abstraction leaks in our stack. Would not recommend.
16:16notthatclippy[d]: Just getting it to deal with process isolation probably took multiple engineering years. Dozens even, in aggregate.
16:34mhenning[d]: Oh, interesting. Looks like we have that header in openrm.
16:34mhenning[d]: NV83DE_CTRL_DEBUG_READ_MMU_FAULT_INFO could be pretty useful
16:38dwlsalmeida[d]: avhe[d]: where did you get this?
16:38dwlsalmeida[d]: typedef struct _nvdec_hevc_scaling_list_s {
16:38dwlsalmeida[d]: unsigned char ScalingListDCCoeff16x16[6];
16:38dwlsalmeida[d]: unsigned char ScalingListDCCoeff32x32[2];
16:38dwlsalmeida[d]: unsigned char reserved0[8];
16:38dwlsalmeida[d]: unsigned char ScalingList4x4[6][16];
16:38dwlsalmeida[d]: unsigned char ScalingList8x8[6][64];
16:38dwlsalmeida[d]: unsigned char ScalingList16x16[6][64];
16:38dwlsalmeida[d]: unsigned char ScalingList32x32[2][64];
16:38dwlsalmeida[d]: } nvdec_hevc_scaling_list_s;
16:38notthatclippy[d]: mhenning[d]: mmu fault info is available in Ben's tree that runs on 565 gsp
16:39mhenning[d]: Oh, I hadn't seen that. Is that published anywhere?
16:42notthatclippy[d]: mhenning[d]: https://discord.com/channels/1033216351990456371/1034184951790305330/1307923889040654360
17:02tiredchiku[d]: oh while you're here, I wanted to know what the 4 nvidia modules were/did
17:03tiredchiku[d]: there's nvidia, nvidia-drm, nvidia-uvm, nvidia-peermem, and nvidia-modeset
17:15notthatclippy[d]: tiredchiku[d]: nvidia manages the HW. UVM is shared virtual address space between CPU and GPU, stuff like HMM. DRM is an adapter for DRM/DRI APIs on linux. modeset is, well, (kernel) modesetting. peermem is for cross-device communication .
17:15notthatclippy[d]: There's more I think, for stuff like vfio
17:16tiredchiku[d]: so if I wanted to attempt to get NVK running on openrm, I'd need to interact with `nvidia` and `nvidia-drm`?
17:16notthatclippy[d]: nvidia.ko is by far the largest one, and is a shared codebase with windows/etc. Others are all more linux specific
17:16tiredchiku[d]: well
17:17tiredchiku[d]: I guess I'd only need to interact with nvidia-drm
17:17notthatclippy[d]: tiredchiku[d]: You need nvidia.ko for channel allocation and stuff.
17:17tiredchiku[d]: right
17:17tiredchiku[d]: makes sense, I suppose
17:18notthatclippy[d]: Basically anything where nvk talks to nouveau instead of generic drm will go through nvidia.ko
17:19tiredchiku[d]: and I'm guessing all the headers published with openrm have everything I'd need to make that happen?
17:20notthatclippy[d]: I think so. Can't think of anything missing
17:21mhenning[d]: tiredchiku[d]: There's a rather old branch where someone was working on for nvk on openrm, btw: https://gitlab.freedesktop.org/YusufKhan-gamedev/mesa/-/commits/nvk/ogk
17:21mhenning[d]: I'm not sure how much of it was working and I'm sure it won't rebase cleanly at this point, but there might be some useful stuff in there
17:22notthatclippy[d]: Oh, yusuf was pretty active and asking a bunch of questions a while back and then just stopped for whatever reason
17:24tiredchiku[d]: mhenning[d]: yeah, I've already looked at that
17:25tiredchiku[d]: but it doesn't make much use of the nv headers and instead does stuff w/ pciaccess/rmapi?
17:25notthatclippy[d]: Published nv headers *are* rmapi in openrm
17:26tiredchiku[d]: yeah, but that branch barely used any ioctls
17:26tiredchiku[d]: and instead did some funny stuff with the nvidiactl fd
17:26tiredchiku[d]: whereas I was thinking using the headers and recreating the logic in nouveau's winsys but for openrm would be a better approach
17:28notthatclippy[d]: Are you planning on changing the usermode or kernelmode to match? Or both?
17:28tiredchiku[d]: planning on plumbing support for openrm in the nvkmd abstraction layer that exists in mesa
17:30notthatclippy[d]: That's pretty constraining but should be doable. I would suggest embracing rmapi for it though.
17:30tiredchiku[d]: yeah, I'm not against using rmapi
17:30tiredchiku[d]: in fact, that's what I want to do
17:31tiredchiku[d]: but yusuf's branch only included nvidia-drm-ioctl.h and opened /dev/nvidiactl "manually"
17:31tiredchiku[d]: https://gitlab.freedesktop.org/YusufKhan-gamedev/mesa/-/commit/8e898864e56483a2fdd119e7340be7ce7793c9ab#9cf48b8b6d2a65abb6b737c1baf4d0eb4658eee4_49_48
17:31tiredchiku[d]: which, I don't think is the right way to do things
17:31notthatclippy[d]: (Sorry, on vacation with phone only so not reading that)
17:31tiredchiku[d]: it's one line I linked 😅
17:32tiredchiku[d]: `fd_ctl = open("/dev/nvidiactl", O_RDWR | O_CREAT);`
17:32tiredchiku[d]: they did pull in nv-ioctl.h and nvstatus in their most recent commit but as far as I can tell, don't actually use those headers
17:33tiredchiku[d]: tiredchiku[d]: which is why I was asking
17:33notthatclippy[d]: tiredchiku[d]: I mean, that's what you have to do anyway. Did you see my two toy rmapi examples?
17:33tiredchiku[d]: I did not
17:34notthatclippy[d]: https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/530#discussioncomment-10771832
17:34tiredchiku[d]: notthatclippy[d]: this confuses me a bit. Is the fd howw one would interact with rmapi?
17:35notthatclippy[d]: Yes. Read the two tiny programs
17:36notthatclippy[d]: They're much smaller than what you actually need with eg enumerating all devices, attaching if in compute mode, etc.. But it is a very minimal working example
17:36tiredchiku[d]: interesting
17:37tiredchiku[d]: so the headers contain, uh, data, for the lack of a better word, that I pass to the fd with ioctl()
17:37notthatclippy[d]: Exactly. Structs are all in+out (unfortunately)
17:38tiredchiku[d]: I'm rather new to everything please bear with me :D
17:38tiredchiku[d]: notthatclippy[d]: I see
17:39tiredchiku[d]: so even stuff like context creation would go through nvidiactl?
17:39notthatclippy[d]: tiredchiku[d]: Absolutely fine, my apologies if the answers are too concise or impolite, I'm just on a phone with a toddler occasionally jumping on me.
17:39tiredchiku[d]: oh, no problem at all, this is already much further than I'd have gotten scratching at it myself 😅
17:39notthatclippy[d]: tiredchiku[d]: Well, some things go through nvidiactl, others nvidia0, for most either works.
17:40notthatclippy[d]: I'm not sure if this is at all on topic for this channel but until someone complains about spam, just ask away and I'll answer async when I can.
17:41tiredchiku[d]: thank you! I can't think of anything else I'd want to ask right now, but I'll ping you with questions when I come across them :)
18:02avhe[d]: dwlsalmeida[d]: it was a custom addition for convenience
18:36notthatclippy[d]: tiredchiku[d]: this tool could also be very useful to trace what rmapi calls the proprietary stack makes so it should cut down on the search space when looking at all the sdk headers: https://github.com/mtijanic/nvtrace
18:39notthatclippy[d]: And a couple of visual primers:
18:39notthatclippy[d]: https://tinyurl.com/rm-object-tree-glxgears
18:39notthatclippy[d]: https://tinyurl.com/rm-object-tree-vkcube
18:41tiredchiku[d]: thank you!
18:41tiredchiku[d]: it'll take me a bit to learn how to parse the output but I'm hoping it helps a fair bit 😅
19:16airlied[d]: notthatclippy[d]: nice!
19:37dwlsalmeida[d]: anyone here on AM5?
19:38dwlsalmeida[d]: this takes ages to boot x_x
19:44tiredchiku[d]: dwlsalmeida[d]: me
19:45tiredchiku[d]: my PC's up in 12-15 seconds
19:45dwlsalmeida[d]: did you update the bios?
19:45tiredchiku[d]: latest bios, yeah
19:45tiredchiku[d]: asrock board
19:46dwlsalmeida[d]: how did you update yours? my mobo is from MSI
19:46dwlsalmeida[d]: I think..they only have a windows utility
19:47tiredchiku[d]: asrock provides firmware images and the flash utility is baked into the firmware
19:47tiredchiku[d]: so I can load up the image on a USB and flash it from within the bios
19:47orowith2os[d]: dwlsalmeida[d]: my old msi mobo just let me flash firmware in the bios, not sure if it's the same on newer mobos
19:48dwlsalmeida[d]: how much ram do you guys have? I don't think it matters though
19:49dwlsalmeida[d]: there's no amount of ram in the world to make a computer boot in 2+ minutes
19:49tiredchiku[d]: 32 gigs
19:49dwlsalmeida[d]: yeah same
19:50dwlsalmeida[d]: huh, there's a `Flash BIOS` button
19:50dwlsalmeida[d]: my laziness stopped me from figuring this out two years ago
19:51orowith2os[d]: If you can find a firmware file, toss it onto the root of a fat32 USB, plug it in, and start while hitting that button
19:51orowith2os[d]: Should do it
19:51tiredchiku[d]: works even without a cpu installed on the higher end boards
19:52tiredchiku[d]: refer to manual :D
21:24redsheep[d]: dwlsalmeida[d]: Did that solve your boot time? It wouldn't be surprising if it's still bad. My Asus board is terribly slow, and it's due to it having to train memory on every boot when the memory overclock is applied
21:25redsheep[d]: If I'm going to reboot a lot for something I shut off my memory overclock and speed up my boot by like 5x. It's really dumb.
21:25dwlsalmeida[d]: I do have mem overclock going on
21:26dwlsalmeida[d]: didn't think about that
21:26dwlsalmeida[d]: (didn't try the bios update yet)
21:27dwlsalmeida[d]: skeggsb9778[d]: btw how do I use this?
21:28dwlsalmeida[d]: got some misterious mmu faults to debug :/
21:31airlied[d]: install the kernel and the fw, get that to work, then it sohuld show faults
21:31airlied[d]: but for video at least there really shouldn't be a lot of mystery
21:32airlied[d]: you allocate a bunch of buffers, if you get a fault some of the buffers are too small,
21:37dwlsalmeida[d]: all buffers are sized for 8K
21:38dwlsalmeida[d]: so this has to be some mistake on my end somewhere
21:44airlied[d]: it's not like video has pointer math in shaders that can go wrong, it's nearly always a undersized allocation, or maybe at the outisde a missing buffer you haven't configured
22:54dwlsalmeida[d]: Averne, would you know anything about this TILE_SIZE buffer?
22:54dwlsalmeida[d]: I hacked the tracer to dump what's in there:
22:54dwlsalmeida[d]: 0 HEVC Tile Sizes: ca7ac67d1c1adbf0
22:54dwlsalmeida[d]: 1 0x000000: 00030003 00000000 00000000 00000000
22:54dwlsalmeida[d]: 2 0x000010: 00000000 00000000 00000000 00000000
22:54dwlsalmeida[d]: 3 0x000020: 00000000 00000000 00000000 00000000
22:54dwlsalmeida[d]: 4 0x000030: 00000000 00000000 00000000 00000000
22:55dwlsalmeida[d]: I assume it's an array of `u16`, right? so that would give `[0] = 0x3, [1] =0x3`?
23:39airlied[d]: skeggsb9778[d]: I know you can map system memory into the main VRAM BAR for to get linear access, I'm trying to do it with something that has a 0 kind and getting "bad" results, do you know if there has to be a kind supplied?