00:33alyssa: oh. I just figured I didn't have to bother setting labels anymore thanks to the new robot future
00:42jenatali: I still like doing it manually in case it affects components indirectly, or to avoid things like unrelated meson tags, and to be able to label drafts, and so notification emails get sent about creation instead of adding the label
00:43jenatali: But I also like doing a lot of other things manually that a lot of people automate...
00:44zmike: I'll never automate shitposting on irc
00:46ccr: but what about ChatGPT supergoodcode blogposts?
00:47zmike: maybe once it can make memes
00:58ccr: :)
01:11psykose: zmike: how did you see that in like 1 minute lmao
01:11zmike: I did it manually
02:53lina: mairacanal: I haven't figured out yet whether I need that one right off the bat or not
04:15lina: mairacanal: But we did talk about what that abstraction should look like in the meeting the other day with Rust folks and danvet ^^
10:39airlied: anyone seen a moore threads mtt s60 or s80?
15:26neobrain: Is Mesa's vkQueuePresentKHR implementation supposed to block on Wayland if vsync is enabled (present_mode==FIFO)? I'm observing this behavior in a multithreaded Vulkan app, where I can't reliably protect VkQueue accesses by a mutex because vkQueuePresentKHR blocks for 15ms each frame.
15:26neobrain: The behavior I would expect is for vkAcquireNextImageKHR to block instead (or waiting for its signal VkFence to do the job). Some notes I found online also seem to indicate that well-behaving drivers shouldn't block in vkQueuePresentKHR (e.g. point 7 in https://github.com/KhronosGroup/Vulkan-Docs/issues/1137#issuecomment-574780949)
17:00daniels: neobrain: it’s not ‘supposed’ to but it does. we’ll have that solved in the next couple of months
17:19neobrain: daniels: Ah, that's great to know. Is there by any chance an issue ticket that I can subscribe to?
17:35robclark: hmm, vivante GPUs in intel? This is something new :-P
17:35robclark: https://usercontent.irccloud-cdn.com/file/L9yxyoHr/image.png
19:21alyssa: I'm waffling about adding "texel address" image intrinsics to NIR, and a common pass to lower image atomics to image_texel_address + global_atomic
19:21alyssa: Mali would use that lowering
19:21alyssa: robclark: It looks like at least older ir3 would want that?
20:22alyssa: looks like both Mali compilers would use it, actually
21:14alyssa: (well, not lima)
21:14alyssa: (I guess we actually have 4 mali compilers in tree, lol)