00:09 mhenning[d]: gfxstrand[d]: I'd also appreciate a review on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31498 before you vanish
00:42 gfxstrand[d]: Yeah, I was planning on it. But thanks for the reminder.
01:10 gfxstrand[d]: Tomorrow I'll be working from a Chromebook so perfect time for code review. 😅
08:34 tanriol: Hi. When Nouveau/GSP becomes stuck in active state (cat .../power/runtime_status returns error, laptop power is +20W or so to normal) is there some reasonable way to reset it to an operational state less disrupting than a full reboot? That happens like once a couple days to me :-(
08:35 tanriol: Looks like in kernel 6.11 that happens more often than it used to on 6.10
08:35 tiredchiku[d]: echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
08:35 tiredchiku[d]: and
08:35 tiredchiku[d]: echo 1 > /sys/bus/pci/rescan
08:36 tiredchiku[d]: tanriol, of course, replace the pci id with that of your GPU
08:45 tanriol: The remove command has caused like 30 WARNINGs in nouveau_gem_object_close+0x283/0x2f0 and nouveau_gem_object_del+0x6f/0x330 followed by a few other in different places of nouveau and finally an OOPS for NULL pointer deref at nouveau_bo_unpin+0x4a/0x80. Looks like at least for this boot I'm out of luck :-D
09:07 tiredchiku[d]: oof :(
14:01 gfxstrand[d]: My TU117 card should be showing up today.
14:21 asdqueerfromeu[d]: gfxstrand[d]: Will you attach it to the Chromebook (Bringus Studios-style)?
15:11 tiredchiku[d]: gfxstrand[d]: :wahoo:
15:54 gfxstrand[d]: hehe
16:35 valentineburley[d]: gfxstrand[d]: the reworked `vk_format_get_bpc` doesn't work padded formats as is if we just call it for channel 0
16:36 valentineburley[d]: what I pushed is also wrong
16:42 gfxstrand[d]: 😢
16:44 valentineburley[d]: The way we could make this new `vk_format_get_bpc` work is if we also returned 0 if the channel is VOID, and we kept the loop you commented on. For what it's worth, I preferred the simpler `vk_format_get_bpc` variant, which just returned the size of the first non-void channel, even if it had a more limited usecase. Do you prefer this new version?
16:50 gfxstrand[d]: My real problem with the first version is that it doesn't work if there are channels with different bpps. If you make a version that asserts all non-void channels are the same, that would work.
17:19 valentineburley[d]: gfxstrand[d]: I did that in the latest push
17:23 Lyude: tanriol: I actually think I know the bug that you're hitting
17:23 gfxstrand[d]: Okay, I'll look again
17:29 gfxstrand[d]: valentineburley[d]: Gave you a little rework to simplify it. Otherwise, I'm fine with those semantics.
17:29 gfxstrand[d]: Go ahead and pick one and squash it in
17:30 Lyude: I've been running into it as well and have been working on trying to come up with a fix, the root cause is that due to a race we're disabling interrupts when we shouldn't be - but unfortunately it's a bit of a painful problem to fix
17:31 Lyude: Honestly I think it is a good motivation for us to go through and review the work that skeggsb has done w/r/t removing the nvif/nvkm split, since as far as I can tell that is where most of the complications around fixing this problem are coming from.
17:37 gfxstrand[d]: I'm pretty sure some of the erronious stuff I've seen has to do with missing interrupts, too. It's way better than it once was but there are still odd issues.
17:40 Lyude: yeah - it seems to have caused a number of different issues, I think it's where the frozen screen junk I've been seeing on this other laptop is coming from as well
18:36 gfxstrand[d]: valentineburley[d]: Should be good to go now. Do you need me to Marge?
18:36 gfxstrand[d]: (I don't think so but I don't remember)
18:36 tiredchiku[d]: <a:bongocatwave:968620126800846899>
18:42 valentineburley[d]: Thanks for the help and review! I can merge it, but I pinged hakzsam earlier and he said he'll take a look at the RADV commit tomorrow so I'll probably wait for that
18:42 gfxstrand[d]: Okay
18:42 gfxstrand[d]: I double-checked that you didn't leave any vk_format_to_pipe lying around in RADV so it should be good but if he wants to give his stamp, may as well wait another 24 hours.
18:42 valentineburley[d]: yeah I'm not in a rush
19:05 gfxstrand[d]: karolherbst[d]: if I delete codegen support from NVK, should we put codegen back in src/gallium/drivers/nouveau?
19:06 karolherbst[d]: uhh.. I don't mind either way
19:06 karolherbst[d]: but I also don't have any preference here I think
19:07 karolherbst[d]: I'm sure it makes the build system part a little easier to move it back into the gallium driver?
19:08 gfxstrand[d]: Yeah a bit
19:08 gfxstrand[d]: Because the extraction was never clean. nvk_codegen.c is including gallium TGSI headers.
19:09 gfxstrand[d]: And it means src/gallium/drivers/nouveau doesn't have to stretch across directories as bad
19:12 karolherbst[d]: yeah.. if it makes the build system stuff significantly cleaner then I think it's reasonable to do it
19:49 tiredchiku[d]: I suppose an app enabling the extension but not using the feature makes sense, but am more confused about what the BITSET_TEST checks are
19:50 tiredchiku[d]: or rather
19:50 tiredchiku[d]: what exactly the BITSET_SET does in `nvk_cmd_buffer_dirty_render_pass)`
20:34 gfxstrand[d]: We don't have a bit for "the render pass changed" so we're smashing dynamic state bits for things that need to be re-emitted.
20:34 gfxstrand[d]: It's terrible. I really should add an `nvk_render_pass::dirty` bit and use that everywhere instead.
20:35 gfxstrand[d]: I don't remember why I didn't do that before
20:41 tiredchiku[d]: I see
20:41 tiredchiku[d]: (I don't really, am gonna have to read up on how render passes work to understand that)
20:41 tiredchiku[d]: anyway, pushed another revision incorporating all your suggestions :)
20:41 gfxstrand[d]: This extension continues to scare me
20:42 gfxstrand[d]: I doubt we have nearly enough tests for all the weird little interactions
20:42 tiredchiku[d]: yeah
20:43 tiredchiku[d]: perfect extension for october!
20:44 gfxstrand[d]: Let's see what the CTS thinks of the latest version. Then we can think about the `depth_clamp_zero_one` enable.
20:44 gfxstrand[d]: I'm still unconvinced but it's also plausible that I'm missing something
20:46 tiredchiku[d]: want me to run CTS for it? will take me only ~20 mins
20:46 gfxstrand[d]: yeah
20:46 gfxstrand[d]: My machines are all busy
20:47 tiredchiku[d]: on it o7
20:48 tiredchiku[d]: as far as I know, we're currently following the spec perfectly
20:48 tiredchiku[d]: as you explained in that suggested change with the comment a few days ago
20:50 tiredchiku[d]: now to keep myself engaged until the CTS ends
20:50 tiredchiku[d]: and not fall asleep at my desk
20:50 tiredchiku[d]: oh, perfect https://www.youtube.com/watch?v=-1-ldW4kpLM
21:02 tiredchiku[d]: Test run totals:
21:02 tiredchiku[d]: Passed: 106821/183229 (58.3%)
21:02 tiredchiku[d]: Failed: 0/183229 (0.0%)
21:02 tiredchiku[d]: Not supported: 76408/183229 (41.7%)
21:02 tiredchiku[d]: Warnings: 0/183229 (0.0%)
21:02 tiredchiku[d]: Waived: 0/183229 (0.0%)
21:03 tiredchiku[d]: for `./deqp-vk --deqp-case=*depth*`
21:09 tiredchiku[d]: redacted messages, hang on, double checking CTS
21:15 gfxstrand[d]: I'm gonna go cook for a bit while I wait for CTS things. I'll be back.
21:16 tiredchiku[d]: am gonna finish double checking this CTS run, post results in the MR comment thread, and head to bed
21:16 tiredchiku[d]: 0246 here
21:18 tiredchiku[d]: I accidentally did the run on a branch that didn't have the commit before e-e
21:20 tiredchiku[d]: I am not smart in the evening!
21:28 tiredchiku[d]: oh we're back to the 2 failures
21:35 tiredchiku[d]: ahh, minor logic error I introduced in the ternaries
21:46 tiredchiku[d]: ok, fixed:
21:46 tiredchiku[d]: Test run totals:
21:46 tiredchiku[d]: Passed: 108932/183229 (59.5%)
21:46 tiredchiku[d]: Failed: 0/183229 (0.0%)
21:46 tiredchiku[d]: Not supported: 74297/183229 (40.5%)
21:46 tiredchiku[d]: Warnings: 0/183229 (0.0%)
21:46 tiredchiku[d]: Waived: 0/183229 (0.0%)
21:48 tiredchiku[d]: goob night
22:25 redsheep[d]: gfxstrand[d]: Did it arrive? Also I thought you were getting a TU116
22:26 gfxstrand[d]: yup
22:26 gfxstrand[d]: I haven't put it in yet
22:33 redsheep[d]: WSL is weird. It took way too long and reading too many misleading Google search results to wipe my wsl and start over.
22:35 redsheep[d]: I haven't yet managed to get radv functioning, and I'm kinda tempted to swap my 4090 for the 7800xt from my htpc to hopefully start out with matching device info. Or I could just start off my testing there I suppose