07:54 dj-death: is there anybody knowledgable with the load_barycentric_* intrinsics?
07:59 dj-death: can a shader request all 3 at_centroid/at_sample/at_offset ?
08:27 Lucretia: is it still possible to build mesa for single threaded? AmigaOS is multitasking but has no full pthread lib, not sure if it's possible.
11:35 Lucretia: Well, I've replied to the ml about amigaos, if anyone's got any thoughts.
14:57 mareko: I have a NIR compute shader that implements clears/blits/resolves, it can clear/blit/resolve multiple pixels per invocation, only non-scaled blits, it can use 16-bit types for everything (even resolve MSAA in FP16) and do X/Y coordinate flipping and clamp to edge with images, and aligns coordinates of workgroups to copy full tiles per workgroup, shader key: https://paste.debian.net/plain/1314457 ; I can
14:57 mareko: put it in core NIR if more drivers want it
14:59 zmike: gfxstrand: this could be useful for vk meta? ^
15:40 gfxstrand: zmike, mareko: It would likely need some modification for vk_meta given that Vulkan has a totally different binding model but could be useful. IDK If pulling it into core NIR now is helpful or not.
15:57 Lucretia: What is dep_threads? dep_thread = dependency('threads')
15:58 Lucretia: I need to remove the arg '-pthread' from the list the compiler gets, until this compiler is patched to correct this, I need to do this.
16:06 MrCooper: zamundaaa[m]: "multiple (atomic) commits may end up targeting the same refresh cycle" can't actually work (for non-ASYNC commits) with current KMS API, can it?
16:07 zamundaaa[m]: The commits don't reach the kernel until right before vblank
16:08 zamundaaa[m]: A thread in KWin waits with committing until that time, ensures that it doesn't commit anything that isn't done rendering yet, and can merge and even reorder commits
16:27 Lucretia: Where is -fPIC set for the build I cannot find it.
16:30 MrCooper: meson itself might set it
16:31 Lucretia: I've searched the entire tree
16:31 Lucretia: it's set in libclc (not building it)
16:31 Lucretia: and it sets -fpic (lower) in the tls section (not build it)
16:32 MrCooper: zamundaaa[m]: I see, is there any benefit in having multiple pending commits instead of amending a single one?
16:38 zamundaaa[m]: Yes. Unless you have a queue, triple buffering won't work properly
16:39 zamundaaa[m]: If you amend the last commit every time you're done rendering on the CPU side, you also swap out the buffer that's almost done compositing on the GPU side with one that still takes a longer time
16:40 zamundaaa[m]: The other one is the mentioned reordering. KWin can replace the cursor (and whenever we finally support that, overlay) image and position with a newer one even if the composited result for the primary plane would miss vblank
16:47 MrCooper: don't see why any of that actually requires multiple commits, just wait for whatever conditions before amending
16:49 MrCooper: hmm, I guess preparing a separate commit can be done ahead of time, so the decision to make use of it takes less time
16:49 zamundaaa[m]: It's needed because of atomic tests
16:50 MrCooper: makes sense
16:54 Lucretia: ok, got it, it's set by meson. Now how about getting rid of the -pthread option?
17:02 Lucretia: nm
17:21 Lucretia: ok, so turning off osmesa allows me to build 4 libs.
17:21 Lucretia: so, is osmesa the only way to get a gl lib I can link against?
17:21 Lucretia: if I add in a static_library for amiga?
17:28 Lucretia: so, I have these built so far: ./src/compiler/isaspec/libisaspec.a ./src/util/libmesa_util_sse41.a ./src/util/blake3/libblake3.a ./src/gallium/frontends/osmesa/libosmesa_st.a ./src/gallium/drivers/softpipe/libsoftpipe.a
22:05 sgm: Hi. One of applications that I use is generating this kind of error(s): https://bpa.st/raw/4XFA - causing entire window go black when using Mesa 24.0.5. I tried to search around for similar problems, but didn't find any solution. Is this really an application bug (Wine or Steam/Proton), or should I [somehow] debug further to confirm this?
22:12 sgm: Of course I can always try to downgrade to the latest working version; I'm just curious is it worth the effort trying to figure out what causes the problem when using v24.0.5 specifically.
23:11 FLHerne: sgm: What was the last working version? 24.0.4?
23:13 FLHerne: it probably is an app bug
23:20 sgm: Yes, unfortunately I'm unable to verify what update caused this breakage. Going back as far as to Mesa 23.x did not solve the problem. Error is not showing up anymore, but I'm still experiencing black windows within the application itself.
23:29 jenatali: That error comes from the Vulkan loader I'm pretty sure
23:40 sgm: jenatali: that was also my guess; I was seeing libvulkan package being updated on this system (Debian Sid) like ~3 days ago. Tried to downgrade to 1.3.275.0 from 1.3.280.0 and restarting Wayland session, unfortunately problem persists.