05:46 asdqueerfromeu[d]: skeggsb9778[d]: Are these different from the Protobuf fault logs?
08:27 phomes_[d]: gfxstrand[d]: I have dropped the radv changes from !29892. The MR should be ready for review/merge for nvk
11:34 eric_engestrom: gfxstrand[d]: I'll reply on the issue :)
11:38 eric_engestrom: gfxstrand[d]: btw on that topic, it looks like nvk was completely broken yesterday, all the nvk(+zink) jobs are failing 100% of the tests
11:38 eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65193704/viewer (vkcts)
11:38 eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65193764/viewer (glcts on zink)
11:38 eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65202724 (vkd3d)
14:16 gfxstrand[d]: eric_engestrom: Oh no!
14:16 gfxstrand[d]: phomes_[d]: Okay, I'll try to review today.
16:06 eric_engestrom: gfxstrand[d]: I'm assuming you're looking into the nvk regression, right? otherwise I'll create an issue so that it gets someone's attention
16:06 eric_engestrom: fyi the range that contains the regression is bd6f3e30f2e8bde00542..948f94b8c514a2730fbc (71 commits)
16:07 eric_engestrom: 1 nvk commit, 1 nak commit, and 5 vulkan commits in that range
16:07 eric_engestrom: valentineburley[d], cwabbott, and daniel almeida are the authors of these commits
16:24 gfxstrand[d]: eric_engestrom: Yup. Fixed: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31718
16:24 gfxstrand[d]: And I added unit tests to ensure we get some sanity testing of the Rust version of `MemStream`
16:25 gfxstrand[d]: Okay, my desktop is finally not tied up so I can play with this "new" card I got from eBay.
16:40 gfxstrand[d]: Okay, TU116 confirmed
16:49 gfxstrand[d]: `Pass: 131719, Skip: 128281, Duration: 7:23, Remaining: 1:09:52`
16:49 gfxstrand[d]: So far so good but I'll let it run to completion.
16:53 tiredchiku[d]: wait is that the CTS?
16:53 tiredchiku[d]: how do you get the stats like that :o
16:56 jfalempe: Hi Lyude, can you take a look at this series: https://patchwork.freedesktop.org/patch/614249/?series=133963&rev=3 ?
17:05 gfxstrand[d]: tiredchiku[d]: deqp-runner
17:05 gfxstrand[d]: https://crates.io/crates/deqp-runner
17:05 tiredchiku[d]: :o
17:05 tiredchiku[d]: thanks
17:06 gfxstrand[d]: That's also how I run with 36 threads sharded across 2 GPUs.
17:06 tiredchiku[d]: oooh
17:07 tiredchiku[d]: fancy 😅
17:07 tiredchiku[d]: btw, I pushed a new rev to the depthClampZeroOne MR
17:07 tiredchiku[d]: I'm not entirely confident it's right, but it's a step in the right direction I think
17:07 gfxstrand[d]: Cool. I'm making a quick lunch and then I'll look at it
17:07 tiredchiku[d]: no worries, take your time c:
17:08 tiredchiku[d]: am around for a few hours more, so I can make quick changes if needed
17:25 gfxstrand[d]: `Pass: 943335, Warn: 1, Skip: 921661, Timeout: 2, Flake: 1, Duration: 43:22, Remaining: 19:53`
17:26 gfxstrand[d]: I'll let it finish but I think TU116 is fine.
17:52 gfxstrand[d]: Yeah, TU116 is golden
17:53 gfxstrand[d]: Time to swap back to my dual-ampere and see if I can torch it for skeggsb9778[d]
17:53 gfxstrand[d]: I guess that means I need to pull kernel patches
18:12 gfxstrand[d]: skeggsb9778[d]: Applied on 6.11.4 and building now.
18:18 gfxstrand[d]: tiredchiku[d]: I'm going to use your branch as the first test for my attempt to take down the GSP. If the GSP is still alive, it'll mean it's tested. If not, well, that's another bug found. 😅
18:21 tiredchiku[d]: :wahoo:
18:33 tiredchiku[d]: so about the current version of the clamp_zero_one bool
18:33 tiredchiku[d]: I looked at all the requirements the spec defined and put them in the check one by one
18:33 tiredchiku[d]: then tried to remove redundant checks
18:33 gfxstrand[d]: I really like the new version. 😄
18:34 tiredchiku[d]: but initially, this is what I had
18:34 tiredchiku[d]: ```c
18:34 tiredchiku[d]: const bool clamp_zero_one =
18:34 tiredchiku[d]: vk_format_depth_only(render->depth_att.vk_format) != VK_FORMAT_D32_SFLOAT) ||
18:34 tiredchiku[d]: (dev->vk.enabled_features.depthClampZeroOne &&
18:34 gfxstrand[d]: My only tweak was to add a vk_format.h helper (see the MR comment)
18:34 tiredchiku[d]: !dev->vk.enabled_extensions.EXT_depth_range_unrestricted) ||
18:34 tiredchiku[d]: (!(dev->vk.enabled_features.depthClampZeroOne &&
18:34 tiredchiku[d]: dev->vk.enabled_extensions.EXT_depth_range_unrestricted &&
18:34 tiredchiku[d]: vk_format_depth_only(render->depth_att.vk_format) == VK_FORMAT_D32_SFLOAT));
18:34 tiredchiku[d]: which...
18:34 tiredchiku[d]: :notlikethishisui:
18:35 tiredchiku[d]: gfxstrand[d]: yeah, I'm following you through my e-mail notifications like it's a live tweet xD
18:35 tiredchiku[d]: I'll do it in a bit
18:35 gfxstrand[d]: cool
18:35 gfxstrand[d]: I'll run it soon. My new kernel is built and installing
18:36 tiredchiku[d]: so you want me to move clamp_zero_one to vk_format.h, right?
18:36 gfxstrand[d]: No. Just add a `vk_format_has_float_depth()`
18:36 tiredchiku[d]: ahhh
18:36 tiredchiku[d]: got you
18:36 gfxstrand[d]: But that means it'll be `!vk_format_has_float_depth()` instead of the more complicated thing.
18:37 tiredchiku[d]: yup
18:37 gfxstrand[d]: Which is nice and easy to read
18:37 tiredchiku[d]: instead of vk_format_depth_only(render->blablabl)
18:37 tiredchiku[d]: got you
18:37 tiredchiku[d]: sorry, been studying spectroscopy all day, brain fried 😅
18:37 gfxstrand[d]: No worrie
18:48 gfxstrand[d]: tiredchiku[d]: dEQP-VK.api.copy_and_blit.dedicated_allocation.blit_image.all_formats.color.1d.r32g32_uint.r32g32_uint.optimal_optimal_nearest is crashing with
18:48 gfxstrand[d]: ../src/vulkan/util/vk_format.h:83: vk_format_depth_only: Assertion `vk_format_has_depth(format)' failed
18:48 gfxstrand[d]: So you'll want to fix that in your helper.
18:48 gfxstrand[d]: I think that trips for stencil-only formats
18:50 gfxstrand[d]: IDK if we should do a `vk_format_has_depth()` check or if we should just check for the two formats. Because there are only two depth formats which have float depth `VK_FORMAT_D32_SFLOAT_S8_UINT` and `VK_FORMAT_D32_SFLOAT`. Maybe we should just check if it's one of those two?
18:50 gfxstrand[d]: That's probably more efficient
18:50 tiredchiku[d]: probably is more efficient, yeah
18:51 tiredchiku[d]: could just be
18:51 tiredchiku[d]: ```c
18:51 tiredchiku[d]: static inline bool
18:51 tiredchiku[d]: vk_format_has_float_depth(VkFormat format)
18:51 tiredchiku[d]: {
18:51 tiredchiku[d]: switch (format) {
18:51 tiredchiku[d]: case VK_FORMAT_D32_SFLOAT:
18:52 tiredchiku[d]: case VK_FORMAT_D32_SFLOAT_S8_UINT:
18:52 tiredchiku[d]: return true;
18:52 gfxstrand[d]: Sure
18:52 tiredchiku[d]: default:
18:52 tiredchiku[d]: return false;
18:52 tiredchiku[d]: }
18:52 tiredchiku[d]: }```
18:52 gfxstrand[d]: Or just `format == || format ==`
18:52 gfxstrand[d]: I don't really care which
18:52 tiredchiku[d]: mhm
18:53 tiredchiku[d]: I'll go for switch/case, looks cleaner and I don't have to worry about indentation 😅
18:54 gfxstrand[d]: Okay
18:54 gfxstrand[d]: But you do need to worry about indentation. 😛 In mesa we put the `case` at the same indent level as the `switch`.
18:58 tiredchiku[d]: :vanpalm:
18:58 tiredchiku[d]: hey, wait
18:58 tiredchiku[d]: nvm
18:59 tiredchiku[d]: I dunno what you mean, I only force pushed once :D
19:00 tiredchiku[d]: fd.o gitlab is a bully
19:00 tiredchiku[d]: I enable `remember me` and log in with github
19:00 tiredchiku[d]: but it does not, in fact, remember me
19:04 tiredchiku[d]: unfortunately I'm only going to be able to work on device_address_binding_report after... the 7th of november
19:04 tiredchiku[d]: gonna be busy with irl stuff starting saturday until then
19:06 tiredchiku[d]: man I really need a better way to tell which window is focused
19:06 tiredchiku[d]: I was on tiling wms before, but now I run KDE plasma
19:07 tiredchiku[d]: tiredchiku[d]: and not having this has led to... multiple mishaps
19:07 tiredchiku[d]: wonder if plasma has a desktop effect for it
19:08 gfxstrand[d]: The MR still doesn't build
19:08 tiredchiku[d]: :thonk:
19:09 tiredchiku[d]: :vanpalm:
19:10 tiredchiku[d]: did a dumb, sorry
19:10 gfxstrand[d]: No worries
19:10 tiredchiku[d]: pushed another revision, confirmed building on my end
19:11 gfxstrand[d]: You wouldn't be the first one
19:11 gfxstrand[d]: Nope. Still doesn't build
19:11 tiredchiku[d]: huh
19:11 tiredchiku[d]: are you applying the MR on main?
19:11 tiredchiku[d]: oh
19:11 tiredchiku[d]: OH
19:12 tiredchiku[d]: extra dumb :D
19:13 tiredchiku[d]: there we go
19:15 gfxstrand[d]: There we go!
19:15 tiredchiku[d]: :wahoo:
19:16 tiredchiku[d]: I forgot to stage the edits after I realized I only changed clamp_zero_one to z_clamp_zero_one in the bool definition
19:16 tiredchiku[d]: e-e
19:16 gfxstrand[d]: It happens
19:23 anarsoul: gfxstrand: any updates on CTS results on your 1650?
19:30 gfxstrand[d]: tiredchiku[d]: So far so good: `Pass: 290936, Skip: 279063, Flake: 1, Duration: 13:43, Remaining: 51:46`
19:31 tiredchiku[d]: :wahoo:
19:31 gfxstrand[d]: anarsoul: My 1660 Ti (TU116) had a totally clean CTS run. I think the issues are in the kernel.
19:41 gfxstrand[d]: Let's play the "What EGL config do I use to make the GL CTS build?" game...
20:13 tiredchiku[d]: :wahoo:
20:37 gfxstrand[d]: Ugh... I knew changing MSAA layouts was going to break storage images.
20:40 anarsoul: gfxstrand[d]: out of curiosity, are you able to launch steam or it's also crashes for you?
21:34 gfxstrand[d]: I haven't tried steam
21:54 gfxstrand[d]: I hate MSAA...
21:54 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31727
21:55 gfxstrand[d]: Gave me an excuse to figure out what's actually different about the _D3D MSAA layouts so I guess that's a plus.
22:00 gfxstrand[d]: Also, apparently there are serious testing holes in host_image_copy
22:05 zmike[d]: luckily you have me to fill in the gaps for you
22:07 cwabbott: I ran into a bug in turnip w/ zink for array copies just today and filed a CTS issue
22:35 djdeath3483[d]: gfxstrand[d]: Like no MSAA testing
22:35 djdeath3483[d]: I went and reread the discussion on the issue
22:35 djdeath3483[d]: several people said it was useless
22:37 djdeath3483[d]: and I think Piers wrote he wanted a way to avoid supporting that on sparse images or something
22:37 djdeath3483[d]: maybe we should have a feature bit for this...
22:54 gfxstrand[d]: MSAA copies actually aren't that hard on NVIDIA
22:54 gfxstrand[d]: That MR fixes two bugs. One with MSAA storage images and one with host copy
22:54 djdeath3483[d]: I just saw
22:57 gfxstrand[d]: Yay! My CTS run blew up a GPU. Now let's go see what cookies the kernel left for me in debugfs
23:01 gfxstrand[d]: skeggsb9778[d]: ```
23:01 gfxstrand[d]: [13150.046074] nouveau 0000:17:00.0: gsp:msg fn:103 len:0x78/0x58 res:0x62 resp:0x62
23:01 gfxstrand[d]: [13150.046079] msg: 00000000: 08 00 d0 c1 08 00 d0 c1 00 00 1d de 80 00 00 00 ................
23:01 gfxstrand[d]: [13150.046080] msg: 00000010: 62 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 b...8...........
23:01 gfxstrand[d]: [13150.046081] msg: 00000020: 00 00 00 00 08 00 d0 c1 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13150.046082] msg: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13150.046082] msg: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13150.046083] msg: 00000050: 00 00 00 00 00 00 00 00 ........
23:01 gfxstrand[d]: [13150.046558] nouveau 0000:17:00.0: deqp-vk[104194]: VMM allocation failed: -22
23:01 gfxstrand[d]: [13150.364340] nouveau 0000:17:00.0: gsp:msg fn:103 len:0x78/0x58 res:0x62 resp:0x62
23:01 gfxstrand[d]: [13150.364345] msg: 00000000: 08 00 d0 c1 08 00 d0 c1 00 00 1d de 80 00 00 00 ................
23:01 gfxstrand[d]: [13150.364347] msg: 00000010: 62 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 b...8...........
23:01 gfxstrand[d]: [13150.364348] msg: 00000020: 00 00 00 00 08 00 d0 c1 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13150.364348] msg: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13150.364349] msg: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13150.364350] msg: 00000050: 00 00 00 00 00 00 00 00 ........
23:01 gfxstrand[d]: [13150.364830] nouveau 0000:17:00.0: deqp-vk[104194]: VMM allocation failed: -22
23:01 gfxstrand[d]: [13152.852357] nouveau 0000:17:00.0: gsp:msg fn:103 len:0x78/0x58 res:0x62 resp:0x62
23:01 gfxstrand[d]: [13152.852362] msg: 00000000: 08 00 d0 c1 08 00 d0 c1 00 00 1d de 80 00 00 00 ................
23:01 gfxstrand[d]: [13152.852363] msg: 00000010: 62 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 b...8...........
23:01 gfxstrand[d]: [13152.852364] msg: 00000020: 00 00 00 00 08 00 d0 c1 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13152.852365] msg: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13152.852366] msg: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
23:01 gfxstrand[d]: [13152.852367] msg: 00000050: 00 00 00 00 00 00 00 00 ........
23:01 gfxstrand[d]: [13152.852850] nouveau 0000:17:00.0: deqp-vk[104198]: VMM allocation failed: -22
23:04 gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1296609716029624330/nvlogs.tgz?ex=6712e966&is=671197e6&hm=fbdf7ebe766ebe112d9c9b840a4bc07f3aef0e0e3f32f18ea180b614f4b8181f&
23:04 gfxstrand[d]: And here's the contents of `/sys/kernel/debug/nouveau/0000:17:00.0`
23:10 gfxstrand[d]: I filed an issue with all the same information: https://gitlab.freedesktop.org/drm/nouveau/-/issues/392
23:11 gfxstrand[d]: The nvlogs.tgz in the issue contains a full dmesg as well
23:11 gfxstrand[d]: The downside is that I need to restart my CTS run for !31727 😅
23:31 redsheep[d]: gfxstrand[d]: I think your description was supposed to say "shard"
23:38 redsheep[d]: I suppose the current word isn't terribly inaccurate given the crashing, but still
23:39 gfxstrand[d]: fixed
23:47 skeggsb9778[d]: gfxstrand[d]: Excellent! Thank you
23:49 skeggsb9778[d]: gfxstrand[d]: would you be able to change the assignee to @bskeggs please 🙂
23:49 gfxstrand[d]: sure
23:49 skeggsb9778[d]: i'll have to figure out how to log into the other one and delete it somehow
23:50 gfxstrand[d]: bskeggs isn't part of the project. I'll add you
23:50 skeggsb9778[d]: thank you!
23:50 gfxstrand[d]: Ugh... IDK that I can
23:50 gfxstrand[d]: That's drm/nouveau and I'm not a maintainer there
23:50 gfxstrand[d]: airlied[d]: ^^
23:50 skeggsb9778[d]: it's ok, don't worry about it for now. i can still reply on the issue regardless