01:50 airlied[d]: uggh a Begin/End command buffer with nothing between causes a pbdma error
02:07 airlied[d]: oh no it's the INVALIDATE_MME_DATA flush
02:29 airlied[d]: okay spirv_assembly now only has early depth and compute deriv issues left
02:38 butterflies[d]: HdkR: Not even that because a reminder that TME transactions aren't guaranteed to succeed so you'll still need a non-TME path no matter what
02:48 HdkR: butterflies[d]: nah nah nah, loop until it succeeds and then exclaim broken hardware if it never does.
02:48 butterflies[d]: oh no, that's not compliant
02:49 rinlovesyou[d]: tiredchiku[d]: glad to hear that, very invested in your nvk on nvidia's kernel module work to avoid rebooting !
05:55 tiredchiku[d]: faith!
05:55 tiredchiku[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31518
06:12 tiredchiku[d]: rinlovesyou[d]: I might take a bit longer to get back to that, I kinda wanna look at some extensions and/or fixing bugs
06:45 airlied[d]: closed a few more depth/stencil gaps, but still getting GR errors in a few places
11:19 tiredchiku[d]: can someone give me a quick run-down on how to decode GSP logs? I've got gsp 570 running
11:19 tiredchiku[d]: [Tue Jun 10 16:48:12 2025] nouveau 0000:01:00.0: gsp: mmu fault queued
11:19 tiredchiku[d]: [Tue Jun 10 16:48:12 2025] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:22 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000003e159b7000 fault_type:00000000
11:19 tiredchiku[d]: [Tue Jun 10 16:48:12 2025] nouveau 0000:01:00.0: fifo:c00000:0016:0016:[Zion[6657]] errored - disabling channel
11:19 tiredchiku[d]: [Tue Jun 10 16:48:12 2025] nouveau 0000:01:00.0: Zion[6652]: channel 22 killed!
11:21 karolherbst[d]: tiredchiku[d]: https://nouveau.freedesktop.org/Bugs.html#gettinggsp-rmlogs
11:22 karolherbst[d]: but I don't think it's a GSP type of error... though dunno if those type of faults show up there
11:24 tiredchiku[d]: oh I meant the logs spit out by the GSP, like the example I attached 😅
11:24 tiredchiku[d]: thanks though, good resource
11:24 tiredchiku[d]: specifically, how woulf I decode `rc engn:00000001 chid:22 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000003e159b7000 fault_type:00000000`
11:34 mohamexiety[d]: The fault address is well, the fault address. The fault type is here https://discord.com/channels/1033216351990456371/1034184951790305330/1337136421928177751
11:36 asdqueerfromeu[d]: mohamexiety[d]: fault_type 0 is ` NV_PFAULT_FAULT_TYPE_PDE` here
12:14 phomes_[d]: tiredchiku[d]: Hi Sid. I am working on VK_EXT_device_fault and I am testing your MR with that
12:14 tiredchiku[d]: awesome :D
12:14 tiredchiku[d]: let me know if there's anything to be done with it
12:25 karolherbst[d]: was thinking more of the vec phi issue, and I think I understand the code enough to have an idea now how to integrate the code I've written into `PhiWebs`
12:25 karolherbst[d]: parts of it at least
12:49 karolherbst[d]: mhh.. I think the code I came up with only works if the phi is part of a loop, but it would break for anything else
12:50 karolherbst[d]: probably
12:50 karolherbst[d]: I wonder if allocating an entire phi node on first hit _would_ work without violating tree-scan
12:51 karolherbst[d]: though I suspect that `RegAllocator::reg_is_used` can return a wrong result then
14:28 phomes_[d]: tiredchiku[d]: it actually needs a rebase with the MR that just got merged
14:43 rinlovesyou[d]: tiredchiku[d]: gotcha, yeah i've been trying to get it to run with my 2070 super but no luck so far haha
14:46 tiredchiku[d]: phomes_[d]: I'll take a look at that by tomorrow
14:46 tiredchiku[d]: will have to see what this whole new memory arena thing is
14:47 tiredchiku[d]: gonna be disappointed if there's no fights in there, gladiator style
14:47 tiredchiku[d]: https://tenor.com/view/are-you-not-entertained-maximus-gladiator-aren%27t-you-amused-am-i-not-funny-gif-2396413337976800815
14:50 mohamexiety[d]: karolherbst[d]: could you please retest the mutable sparse stuff?
14:50 mohamexiety[d]: just run `dEQP-VK.sparse_resources.image_sparse_residency.mutable.2d.r16_sint_r16_unorm_r8g8_unorm`, no need for anything else
14:51 karolherbst[d]: on mesa main?
14:51 mohamexiety[d]: yeah
14:51 mohamexiety[d]: it's working now on my end but I am not sure if I messed up. the only things I changed is I updated mesa 🐸
14:52 karolherbst[d]: fails
14:52 mohamexiety[d]: (as in, did a big pull and should be in sync with mesa main now)
14:52 mohamexiety[d]: hmmmm
14:52 karolherbst[d]: uhm..
14:52 karolherbst[d]: maybe I need to pull
14:52 karolherbst[d]: when did the fixes land?
14:53 mohamexiety[d]: there shouldnt be any fixes, that's why I am confused
14:53 mohamexiety[d]: it was broken yesterday and today isnt
14:53 karolherbst[d]: ahh...
14:53 karolherbst[d]: still fails
14:54 mohamexiety[d]: are you still on 1.4.2.1? for the CTS
14:54 karolherbst[d]: I'm on 73a2c954fb070603c57d91b1cd50d792e65a55d5
14:54 karolherbst[d]: which is a bit newer than 1.4.2.1
14:54 mohamexiety[d]: hm. could you try the 1.4.3.0 release just in case? sorry
14:56 tiredchiku[d]: oh spooky
14:56 tiredchiku[d]: a growable memory area
14:56 tiredchiku[d]: is what does `nvk_mem_arena->max_mem_count` store :doomthink:
14:56 tiredchiku[d]: oh I see
14:57 mohamexiety[d]: I guess the apps fight for the remaining space
14:57 tiredchiku[d]: literally the max vram size
14:57 tiredchiku[d]: uh
14:57 tiredchiku[d]: how would I get the current size for it :doomthink:
14:58 tiredchiku[d]: ah
14:58 tiredchiku[d]: got it
14:59 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1382011289026564188/image.png?ex=684999cf&is=6848484f&hm=99903308eb02ba67b50078a311f5452ed22b94ac5803023e13528700a0d8b9e1&
14:59 tiredchiku[d]: ah yes, meme_size_B
15:02 tiredchiku[d]: phomes_[d]: rebased, but I didn't test it yet
15:02 tiredchiku[d]: it _should_ pass every test matching `*address_binding_report*`
15:08 karolherbst[d]: mohamexiety[d]: it's passing on 1.4.3.0 indeed
15:08 mohamexiety[d]: welp I guess that's why then. interesting
15:08 mohamexiety[d]: so I guess mystery solved, CTS bug? :thonk:
15:08 karolherbst[d]: sounds good
15:10 karolherbst[d]: mohamexiety[d]: https://github.com/KhronosGroup/VK-GL-CTS/commit/864ae33ded64052ce751bb375c3cbf6f134e4aea maybe?
15:10 blisto[d]: Fix only for singles? :BlobhajShock:
15:11 karolherbst[d]: ah yeah.. Alyssa reported that bug
15:11 karolherbst[d]: thanks alyssa
15:11 mohamexiety[d]: thank you alyssa
15:11 mohamexiety[d]: this bug was driving me mad
15:11 mohamexiety[d]: I single stepped through the entire test in gdb, and at one point the data would just get yeeted
15:11 mohamexiety[d]: I had no idea how and nothing in nvk looked off
15:11 karolherbst[d]: pain
15:12 mohamexiety[d]: but I didnt think that it could be a CTS bug
15:12 karolherbst[d]: heh
15:12 karolherbst[d]: always blame everything else first
15:12 tiredchiku[d]: speaking of the CTS, how would I check if tests exist for an extension?
15:12 mohamexiety[d]: there's a way to output a 0.5 GB text file with all tests and then you grep that
15:12 mohamexiety[d]: let me check how to output that file tho, 1 sec
15:13 tiredchiku[d]: pain
15:15 karolherbst[d]: normally the ext name is somewhat part of the test
15:15 mohamexiety[d]: tiredchiku[d]: `deqp-vk --deqp-run-mode=txt-caselist`
15:16 karolherbst[d]: just do `-n '*$random_word_from_ext*'` or something 😛
15:16 mohamexiety[d]: and yeah just search for something from the ext name
15:16 tiredchiku[d]: I was looking at `VK_NV_representative_fragment_test`
15:17 tiredchiku[d]: want something to do that'll force me into compiler land
15:17 tiredchiku[d]: wanna get familiar with it
15:17 mohamexiety[d]: gfxstrand[d]: with this fixed, what should I move on to?
15:33 tiredchiku[d]: mohamexiety[d]: can I DM you rq? wanna bounce some ideas off of you
15:34 mohamexiety[d]: sure
15:36 gfxstrand[d]: Okay, so I think we need go figure out root descriptors in HW...
15:40 pavlo_kozlenko[d]: karolherbst[d]: https://tenor.com/view/%D0%BF%D0%B5%D0%BF%D0%B5-%D0%BB%D1%8F%D0%B3%D1%83%D1%88%D0%BA%D0%B0%D0%BF%D0%B5%D0%BF%D0%B5-gif-24160957
15:59 tiredchiku[d]: tiredchiku[d]: rip, it doesn't
15:59 tiredchiku[d]: in fact it fails most of them :lul:
16:02 tiredchiku[d]: yeah I'll look at this tomorrow
16:29 tiredchiku[d]: ok there we go, that's sorted, was easier than I thought it'd be
16:29 tiredchiku[d]: now I go game
17:12 gfxstrand[d]: mohamexiety[d]: Good question. I think there's another maintenance extension or two that have been released. Want to take a look at those? If you have questions about any parts, feel free to ask.
17:13 mohamexiety[d]: what about Blackwell?
18:09 gfxstrand[d]: You can keep looking at that, too, if you want.
18:10 gfxstrand[d]: Like maybe try to come up with a way to do image formats on blackwell that doesn't suck. They changed stuff a lot there and I'm not convinced I like just adding extra columns to the table but maybe that's the best we can do.
18:12 mohamexiety[d]: gfxstrand[d]: havent been keeping up with the blackwell stuff, sorry. what's the latest on that?
18:12 mohamexiety[d]: not sure what the currently missing things are
18:13 gfxstrand[d]: It's all in Dave's branch at the moment
18:13 gfxstrand[d]: We landed QMDs (with real NVIDIA headers!) and some cbuf fixes this week.
18:14 gfxstrand[d]: But for textures, they changed the way formats are specified in the header and it's pretty different from Fermi-Ada.
18:18 mohamexiety[d]: gfxstrand[d]: is it known how the formats are changed? (also I guess we're talking about the table in nvk_format.c right?)
18:20 gfxstrand[d]: It's probably better to go read Dave's patch than me try to explain it
18:21 mohamexiety[d]: ohh didn’t know there was already something sorry
18:28 mohamexiety[d]: gfxstrand[d]: Sorry where was Dave’s branch again?
18:31 mhenning[d]: I think it's https://gitlab.freedesktop.org/airlied/mesa/-/commits/nvk/blackwell?ref_type=heads
18:33 mohamexiety[d]: mhenning[d]: Yep! Thanks!
19:48 calico: On my PC, which is running Gentoo, that has the GTX 760, the video decoding is very slow, the videos are playing at like 2-3 fps. Could it be because I'm missing something like vdpau?
19:56 karolherbst: calico: what's the codec?
19:58 calico: karolherbst: x264 or x265
19:58 calico: I mean, AVC or HEVC.
19:58 karolherbst: calico: in that case the problem might be that it's indeed hw decoding and it's just slow, for reasons (tm). CPUs are plenty fast to decode those if the resolution isn't massive
20:00 calico: the CPU is a Phenom 2 X6 1100T
20:00 calico: how can I find out if it's hw decoding or not?
20:09 averne: if you're on mpv you can hit I and check the video section
20:11 averne: vlc has something like this in the messages window (check input->decoder)
20:34 calico: k
20:34 calico: mpv yes
23:21 anarsoul: looks like nouveau is broken on hybrid GTX1650 in 6.15.1
23:21 anarsoul: https://gist.github.com/anarsoul/48a18f8926f05dcac8ff743163136042
23:22 anarsoul: (and nvk is not in vulkaninfo anymore)
23:27 airlied: does nouveau.runpm=0 fix it?
23:27 anarsoul: 6.14.10 works fine
23:28 anarsoul: airlied: you don't want me to use a laptop with discrete GPU always enabled, do you? :)
23:28 anarsoul: let me try
23:32 anarsoul: airlied: yeah with .runpm=0 it works
23:38 anarsoul: but idle power consumption jumps to 12-15W vs 7-10W with runtime pm enabled on 6.14
23:49 airlied: must be the rpc changes :(
23:57 anarsoul: That's unfortunate. And it looks like the blob doesn't do runtime pm either. Feature parity! :)