00:02orowith2os[d]: Voltas are Vulkan-compliant now? :Uueuuue:
00:17mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1352798405939953757/IMG_0240.jpg?ex=67df5331&is=67de01b1&hm=13f54fd5b439772ec237d9bc6bcce1ebd8c013307ebc5f2f603e5732bbb27856&
00:17mohamexiety[d]: Ok that is indeed much better
00:20mohamexiety[d]: > 000000802001000
00:20mohamexiety[d]: > 000000802001000
00:20mohamexiety[d]: > 000000802004000
00:20mohamexiety[d]: > 000000802001000
00:20mohamexiety[d]: Just since the addresses are hard to read
00:24mohamexiety[d]: assuming fault_type maps to this: https://github.com/NVIDIA/open-gpu-doc/blob/master/manuals/turing/tu104/dev_mmu_fault.ref.txt
00:24mohamexiety[d]: then this should be `#define NV_MMU_FAULT_BUF_ENTRY_INST_APERTURE_SYS_MEM_COHERENT 0x00000002 /* RW--V */`
00:26mohamexiety[d]: alternatively if it maps to this: https://github.com/NVIDIA/open-gpu-doc/blob/master/manuals/turing/tu104/dev_fault.ref.txt
00:26mohamexiety[d]: then it would be `#define NV_PFAULT_FAULT_TYPE_PTE 0x00000002 /* */` which means "couldnt find PTE"
00:26mohamexiety[d]: mohamexiety[d]: but what does this mean :thonk:
00:29eric_engestrom[d]: gfxstrand[d]: sharding, using both gpus to (hopefulyl close to) double the number of tests that can be run within the merge job 10min
00:29eric_engestrom[d]:goes to bed
00:33gfxstrand[d]: orowith2os[d]: Yup. Just waiting on the mandatory 30-day review period.
00:34gfxstrand[d]: eric_engestrom[d]: Okay, that's basically what I'm doing on my system. You'll definitely want 570 then.
00:41mohamexiety[d]: mhenning[d]: yeah in that case it's "cant find PTE" then
00:41mohamexiety[d]: wonder what's missing for it that makes it unable to find it..
01:32airlied[d]: Large page tables and small page tables have a double page table system
01:32airlied[d]: So if there was some confusion maybe it could get lost
01:37mohamexiety[d]: airlied[d]: not sure I understand; you mean it's going to the small page table while it should have been going to the large? (or the opposite)
01:37mohamexiety[d]: where's the PT handling code?
01:43mohamexiety[d]: or.. well, how/where do I check?
03:10airlied[d]: down in the depths of nvkm, there stuff in vmmgp100.c, but I've no idea if the problem is down that far or something more surface level
12:31phomes_[d]: I am looking into why Tiny Glade is fine on gamescope but fails to launch on wayland. I put the details of what happens in https://gitlab.freedesktop.org/mesa/mesa/-/issues/12860. I am not sure what the right way to fix would be
12:35karolherbst[d]: mhhh, is that with HDR enabled or something?
12:35karolherbst[d]: not sure why a compositor would choose a 10 bit color format otherwise
12:47phomes_[d]: it is on gnome 48 but I have not enabled HDR specifically
13:57mohamexiety[d]: airlied[d]: yeah thinking more about it, it doesnt make sense for it to be that low level. that code should be used in the older, non vm_bind path and well, it also worked fine when you removed the flag from the nvk side rather than the kernel side. so it's something more surface level but need to look into it more
14:20gfxstrand[d]: phomes_[d]: Looks like we just need to turn on some more formats. The 1010102 stuff in NIL looks wrong.
14:27gfxstrand[d]: Is GitLab back for real? I don't see the banner anymore.
14:42gfxstrand[d]: Well, I just pushed some of this week's MRs
14:53gfxstrand[d]: snowycoder[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34129
15:02gfxstrand[d]: gfxstrand[d]: Hrm... It looks like it's maybe not as simple as just flipping them on. 😕
15:10phomes_[d]: gfxstrand[d]: It fixed the game at least
15:14gfxstrand[d]: Yeah but it blows up the CTS tests
15:17phomes_[d]: yes
15:17gfxstrand[d]: So the game doesn't have any color distortion?
15:17gfxstrand[d]: Could be a CTS bug, I suppose.
15:19gfxstrand[d]: NVIDIA doesn't support storage on them either.
15:22gfxstrand[d]: Okay, maybe gitlab isn't quite back. :frog_sweat:
15:22gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34127#note_2829524
15:24gfxstrand[d]: Storage on BGRA8 works fine. What gives?!?
15:34gfxstrand[d]: Okay, I'm not going to debug the CTS on a Saturday. Not after the week I've had. This is going to have to wait until next week.
15:47gfxstrand[d]: phomes_[d]: Okay, so I asked Piers about it. We'll see what he says. I suspect 1010102 just isn't storage swizzleable. It can be fixed in GameScope but it's a little annoying.
15:48gfxstrand[d]: In theory, we could fix it in NVK, too, but I don't really like what we'd have to do.
15:50gfxstrand[d]: We've got extra descriptor bits but ugh...
16:05gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1353036950604484660/rn_image_picker_lib_temp_14e7be1c-6a24-4110-810e-33ecdbf22070.jpg?ex=67e0315b&is=67dedfdb&hm=02f7fe64ef718569123e94d64005a219fb1cf45f470db86889623555645e6f98&
16:05gfxstrand[d]: Lookie what just showed up in the mail!
16:13marysaka[d]: niiice
16:24gfxstrand[d]: Annoyingly, it didn't come with a power adapter so I'm gonna have to get one
16:28marysaka[d]: uuurgh right I had to buy one too
16:30tiredchiku[d]: that's a tegra, isn't it?
16:32gfxstrand[d]: Yeah. Maxwell Tegra.
16:33gfxstrand[d]: Annoyingly, I can't seem to find anyone who will tell me the polarity of the power plug. 🫤
16:34orowith2os[d]: plug a 120v AC line directly to your NVIDIA Jetson TX1. You will surely not regret plugging a 120v AC line directly to your NVIDIA Jetson TX1.
16:38asdqueerfromeu[d]: Install SteamOS directly to the device :bringus_studios:
16:39gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1353045516098998272/signal-2025-03-21-12-58-31-503.jpg?ex=67e03955&is=67dee7d5&hm=804e3efebae9844e371d341e88b5931e602f23709f20c4c838cb82f7337ef4f3&
16:39gfxstrand[d]: asdqueerfromeu[d]: Oh, no. I just got device for that:
16:42Jasper[m]: <gfxstrand[d]> "https://cdn.discordapp.com/..." <- YEOWZA
16:43Jasper[m]: I wish they were quicker with adopting USB-C and saner voltages
16:46Jasper[m]: If I checked Matrix earlier I'd have told you, I think the carrier boards between the tx1 and tx2 are the same
17:16djdeath3483[d]: gfxstrand[d]: You so bored you care about Hasvk? 😂
17:19pavlo_kozlenko[d]: djdeath3483[d]: Hopefully we will see Vulkan 1.3 gfxstrand[d]
17:19pavlo_kozlenko[d]: 😁
17:22djdeath3483[d]: Good luck with descripot_indexing
17:25gfxstrand[d]: djdeath3483[d]: Bored might not be the right term. I am curious how much of it I can delete if I switch to some of the new stuff.
17:26gfxstrand[d]: ESO on Haswell!
17:27djdeath3483[d]: You might have to do some compiler surgery
17:27djdeath3483[d]: Lucky you you don't have to care about mesh...
17:28gfxstrand[d]: Yeah, IDK that ESO is really practical.
17:28gfxstrand[d]: Haswell has more shader key nonsense than later platforms.
17:28djdeath3483[d]: Just gfx libs is going to be fun
17:28djdeath3483[d]: But you could copy most of BRW
17:29gfxstrand[d]: I thought most of the MSAA stuff was sorted
17:29djdeath3483[d]: I dont remember if itmade the compiler split
17:30djdeath3483[d]: Probably some bugs leff
17:30gfxstrand[d]: I did it long before the split. So unless someone deleted it...
17:30gfxstrand[d]: But yeah, there are probably bugs
17:31gfxstrand[d]: And IDK that I'm motivated enough to hack on Intel compilers again.
17:31djdeath3483[d]: Brw improved the madness
17:32djdeath3483[d]: But simd lowering is such a pain...
17:32djdeath3483[d]: We must be the only hw out there with this nonsense
17:32gfxstrand[d]: Yup
17:32pavlo_kozlenko[d]: gfxstrand[d]: steamos based of debian?
17:33gfxstrand[d]: pavlo_kozlenko[d]: Yeah, I think so. It's the OG SteamOS.
17:33pavlo_kozlenko[d]: In your opinion, has the driver Hasvk reached its peak
17:34pavlo_kozlenko[d]: ?
17:34gfxstrand[d]: gfxstrand[d]: Though fooishbar tried to convince me on Friday to start hacking on Mali400 so, ya'know, it could always be worse. 😂
17:34gfxstrand[d]: pavlo_kozlenko[d]: Yeah. If I hack on it, it'll be to simplify it and make it more maintainable, not really to add features.
17:39Jasper[m]: gfxstrand[d]: molten... beans?
17:39Jasper[m]: As opposed to lima
17:39gfxstrand[d]: Maybe pick up a few trivial features of they're just sitting there in the runtime.
17:40gfxstrand[d]: Jasper[m]: No. Not Vulkan. It would have been GLES. He should know by now that I don't know shit about GLES anymore.
17:41Jasper[m]: It's old enough to probably not be able to do the stuff you need for vk anyway hahahaha
17:41gfxstrand[d]: He should know by now that I don't know shit about GLES anymore. (That's just as true as me not knowing anything about Wayland anymore.)
17:41Jasper[m]: But yeah, I haven't heard too much new stuff since the renaissance of lima
17:41Jasper[m]: (Somewhere around the original pinephone release)
17:42gfxstrand[d]: Yeah, Mali400 is a GLES2 part. It was designed in parallel with GLES2.
17:43Jasper[m]: Kinda crazy how long that part survived
17:43gfxstrand[d]: pavlo_kozlenko[d]: One could even claim that hasvk has already been pushed beyond its peak. 😂
17:44gfxstrand[d]: Jasper[m]: That's the power of free silicone IP.
17:45Jasper[m]: As in, a combo deal with an ARM license?
17:45gfxstrand[d]: As in most of the SOC manufactures who own it can now print infinite Mali400 parts without paying Arm a dime.
17:47gfxstrand[d]: I don't know exactly how the licenses work but there's a lot of companies with a paid-off infinite license. So if they need a GPU for something, just stick a Mali400 in it.
17:48marysaka[d]: We don't even support GLES 3.1 on T6XX I cannot imagine on Utgard :blobcatnotlikethis:
17:49gfxstrand[d]: Yeah, Mali400 even has fun things like a 128 instruction max shader size and still l stuff like that.
17:49gfxstrand[d]: Vulkan ain't running on that. 😂
17:53djdeath3483[d]: gfxstrand[d]: Don't know that hw... Could be faster though 😭
17:53gfxstrand[d]: Unrelated... I wonder if we can reduce the Rust NVK compile times by de-duplicating method types. Make newer types typedefs for older ones as long as all the fields are the same. That would massively reduce the number of trait implementations.
17:54gfxstrand[d]: djdeath3483[d]: Oh, no. Very much not faster. That's the truly ancient Mali from the days of yore.
17:55djdeath3483[d]: What's panvk for?
17:55djdeath3483[d]: What hw?
17:55gfxstrand[d]: More recent Mali
17:55gfxstrand[d]: I don't know the Mali naming
17:56djdeath3483[d]: Looked snappy on the new MNT laptop
17:56gfxstrand[d]: But the 400 was the GLES2 part.
17:56gfxstrand[d]: djdeath3483[d]: Yeah, the latest Mali is actually pretty nice.
17:57Jasper[m]: That's G620 iirc?
17:57Jasper[m]: rk3588
17:57djdeath3483[d]: Yeah that one
17:57Jasper[m]: ah G610
18:09marysaka[d]: djdeath3483[d]: Bifrost (v7 tho not fully done and VK1.0), Valhall (v10, VK1.1 close to 1.2) and "5th Gen" (that's the marketing name... but v12, v13) with the MR I opened around
18:40tiredchiku[d]: gfxstrand[d]: so I guess I'm being screwed over by `#include <xf86drm.h>`
18:58tiredchiku[d]:oh
18:58tiredchiku[d]: :vanpalm:
18:58tiredchiku[d]: it was because the header was being included twice in the project
18:59tiredchiku[d]: indirectly
19:41tiredchiku[d]: me: "I think I'll stop for today, I'm happy with my progress"
19:41tiredchiku[d]: what I got done: *just cleaned up commit history and fixed compile-time errors*
19:41tiredchiku[d]: <a:kekwut:1166451602236915753>
19:44tiredchiku[d]: but the good news is that I am finally inching closer
19:45bigsmarty[d]: Its great to learn that even driver developers get Compile time errors
19:47tiredchiku[d]: well
19:47tiredchiku[d]: I'm kinda out of my depth here
19:48tiredchiku[d]: less a driver developer and more of a nerd trying to learn through doing
20:10gfxstrand[d]: bigsmarty[d]: Oh, yeah. Fighting with compilers is part of the job. If you get too good and comfy with C, just switch to rust and then you'll fight with the compiler even more!
20:11orowith2os[d]: at least fighting with the Rust compiler is in good faith
20:11orowith2os[d]: so that's okay
20:11orowith2os[d]: with C.....
20:12tiredchiku[d]: <a:myy_TinyFight:643302090445291560>
20:15redsheep[d]: I dunno, sometimes the rust compiler seems like it's out to get me
20:17orowith2os[d]: ever thought about the possibility that you just shouldn't be touching the Rust compiler?
20:17orowith2os[d]: who said the Rust compiler was the problem?
20:17orowith2os[d]: what if it's you :staregrab:
20:31gfxstrand[d]: tiredchiku[d]: Ugh... Doesn't it have include guards? 😫
20:31tiredchiku[d]: it does
20:31tiredchiku[d]: but
20:31tiredchiku[d]: only one of them does
20:32tiredchiku[d]: and I was including two different headers in two different places, where one of them in-turn included the other
20:33tiredchiku[d]: had to import I think 4 headers total
20:33tiredchiku[d]: maybe a couple more as I flesh things out