01:37 mareko: maybe I overreacted
04:59 karolherbst: it's fine. I underatand that sometimes CI is being annoying, but maybe we can figure out how to make certain jobs be less so. Maybe we can move the rustfmt one to its own small
05:00 karolherbst: container that almost always finishes within the first minutes, or where the manual steps are less annoying, though we do have the ci
05:00 karolherbst: script to run CI pipelines
05:00 karolherbst: and that one handles dependencies automatically
09:45 ccr: l
11:00 daniels: mareko: it was back in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23774 - that was a time when we had far more contention on hardware jobs (and they ran longer / were more unreliable / etc) than we did today, so perhaps now it makes less sense
13:12 zmike: couldn't that just be merged into one of the build-only jobs?
13:13 karolherbst: yeah.. probably
13:14 karolherbst: but I think it might also make sense to detach it a little and instead of failing the pipeline, just leave a "patch" as a comment on the MR
13:14 karolherbst: and then devs can just apply that directly
13:14 karolherbst: though when marging it does make sense to stop the pipeline...
13:15 karolherbst: or maybe we should just eat it up and run it automatically on each push
13:15 karolherbst: and make it part of sanity?
14:05 alyssa: cmarcelo: ea9deafff4a ("spirv: Add more restrictions around Blocks") has made vulkan CTS *really* noisy
14:05 alyssa: massive amounts of `A pointer to a structure decorated with *Block* or *BufferBlock* must not have an *ArrayStride* decoration`
14:05 alyssa: Is there a CTS patch I can apply? or is the Mesa warning overly pedantic?
14:06 alyssa: (quiet cts-runner output is important for some developer workflows, and we were silent before)
14:44 zmike: mareko: I'm back on removing refcounts and I really hate vbuf
15:09 zmike: I'm also deeply wishing that gallium had some kind of api divide between frontend and driver
15:14 cmarcelo: alyssa: I'll see if I can fix up CTS, otherwise we can quiet down the warning for a while.
15:16 alyssa: cmarcelo: thanks
15:37 zmike: mareko (or maybe daniels?) does anything actually use gallium's u_tests ?
15:37 zmike: like are we running that in ci
15:37 zmike: or ?
15:37 zmike: cuz deleting that would let us delete a lot of otherwise dead api
15:40 jenatali: karolherbst: For creating samplers and views during CL object creation, that only works when you have a single device as part of your CL context. Unless you're allocating mem objects across all devices when one is created? I chose to be lazy for that
15:41 karolherbst: yeah.. I was considering doing it lazily
15:41 karolherbst: but..
15:41 jenatali: But I also only have one gallium-equivalent context per device in a context, rather than per queue
15:41 karolherbst: on a gallium level they are context specific
15:41 karolherbst: sooo.. not much I can do there
15:41 jenatali: I'm not sure I follow why that's a problem
15:41 karolherbst: for samplers I have this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36243/diffs?commit_id=9b9e3e08c966cfdfe7d3cb7fb662e21421dc4695
15:41 jenatali: Do you have a gallium context per queue?
15:41 karolherbst: yes
15:42 karolherbst: there is another issue
15:42 karolherbst: and it's that drivers may reference the pipe_resource in their pipe_sampler_view
15:42 karolherbst: and given memory objects can be a bit huge, I also need to tidy up the cached sampler views at some point
15:42 karolherbst: so if a cl_mem object gets freed, I also need to remove the per context pipe_sampler_views somehow
15:43 karolherbst: and given how the code is structured atm, it's just a bit of pain
15:43 karolherbst: for samplers it doesn't matter, so I just go for the low hanging fruits first
15:44 jenatali: Yeah I've got CL resources (which are part of a CL context) owning a map of (device -> object) for the gallium-equivalent resource + sampler view + image view sets
15:44 jenatali: https://github.com/microsoft/OpenCLOn12/blob/master/src/openclon12/resources.hpp#L73
15:44 karolherbst: right.. but pipe_resource is refcounted
15:45 jenatali: And that map is populated lazily unless the context has one device
15:45 karolherbst: and I can just remove the resource if there are still active sampler_views
15:45 jenatali: Why is the refcounting a problem?
15:45 karolherbst: so even if I remove the cl_mems reference to the pipe_resource, it doesn't mean that the pipe_resource gets actually destroyed
15:45 karolherbst: because I might still have cached pipe_sampler_views on the context side
15:46 zmike: I hope you aren't investing too much in resource refcount management
15:46 karolherbst: I haven't really
15:46 karolherbst: what are you up to :P
15:46 zmike: https://media.giphy.com/media/R5FMaiKJjKd0I/giphy.gif
15:47 karolherbst: jenatali: anyway.. the core issue is, that on the application thread, I don't have access to the context at all, or any caching I'm doing there... it's just uhm... rust reasons so I won't have to do pointless locking and using mutex for shared data
15:47 jenatali: Got it, rust reasons
15:48 karolherbst: I can model it with Weak references and such, I just didn't come up with a plan I really like
15:55 alyssa: mareko: I'm looking into opt_varyings, hit an iffy corner case
15:56 alyssa: the "add XFB to I/O intrinsics, regather xfb_info from intrinsics" dance is lossy
15:56 alyssa: (even without opt_varyings running in the middle)
15:56 alyssa: the specific issue is, what happens if there's an XFB output declared but never written. we can just ignore it, right?
15:57 alyssa: nope - it affects how many primitives can fit before overflowing, which is visible in the associated XFB queries even though you don't even write anything explicitly
15:57 alyssa: and without a store, gathering it can't rediscover that there was an output there
15:58 alyssa: I am unsure how to resolve this, since I'm not volunteering to reengineer the entirety of XFB representations, lol
15:58 alyssa: dEQP-VK.transform_feedback.simple.multiquery_omit_write_* hits this
16:32 alyssa: I'm also wondering how this works on other hw
16:33 alyssa: in particular how RADV passes those tests
16:33 alyssa: ooh there's even a comment about that test
16:34 alyssa: so maybe my XFB impl is just doing something silly
16:36 alyssa:has a hack patch
16:40 alyssa: actually this patch is plausible. we go with it
17:23 alyssa: gfxstrand: I'm like 43% sure this patch is correct https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36265/diffs?commit_id=9976e74dede1e017e5abc02e8bf71ec78a35eacb
17:24 alyssa: (and 100% sure the existing code is wrong)
19:16 arthurjunior: Now it's getting scary, exactly two years ago july 16 2023 a cryptograph sent to me and one brazilian e-mail destination a set of numbers , i did not dig deeper at first sight, but just remember it was long time ago in my e-mail box. Until 16 july exactly on the same date 2 years after without looking into those numbers i started to type in exactly same numbers in an experiment to find
19:16 arthurjunior: the final solution. They have some memo on the e-mail perhaps claiming that those numbers were presented in 2020 episode tenth of a fear SCENE TENTH Faustine and Don Fregose Faustine Your free e-book project gutenberg. Those numbers lead into such solution (i know every number of those e-mail added since i am a cryptograph), but unfortunately the solution was not presented there, but i
19:16 arthurjunior: am dead certain that the solution is what they have, but the thing is i think i am compromised with a chip in my neck and they managed to reprogram my brain. Cause i can feel a neuralink type f chip ever since the mysterious knockdown in 2021 in cambodia. So the solution for this proof system comes as 193+6+192-256-354 or 199+192-256-354=219 in a three power system 219 can be eliminated
19:16 arthurjunior: as 81+61+77 being one of the subtract in the sequence formulas. where as 37 as answer from the ideal distribtuion is gotten with 199+192-354=37, so i was certain that bitcoin was another scam since hashes never collide hence the perfect rng, similar to other illuminati scams like jews and noble prizes and other all types of result fixings against races like arians like me who are used to
19:17 arthurjunior: get substances in medicine from. But it's scary cause they told what is going to happen to me, in time travel jabbering fashion on every channel, so it's other humans who control me with their technology likely, so the cryptic e-mail for your eyes, sodiac sign killer one was solved maybe alike but i solved it without looking the numbers which is entirely freaky, so this tends to be a
19:17 arthurjunior: chip with 100percent likeliness that controls me. neuralink is true, brain amniotic fluid spot is where it goes, i have mild amniotic band syndrome i.e the curved frontal cortex. Now the e-mail for the btc crypto result fixings that i talked about. Does anyone know those recepients? or the the sender? Those numbers are very intelligent , they must know as much as me btw.
19:17 arthurjunior: Fran Camero<f.camero@outlook.com>
19:17 arthurjunior: ​You;​mahmut@hotmail.com.br;​dupontchevy@hotmail.com​
19:17 arthurjunior: 63 7 166 286 6 4 2 3 2420 156 361 03153 1734 30780176
19:17 arthurjunior: 6 2 2 4 4 1840 7 61115 23322 604824 1685743 47525 181073808 0457866360044
20:20 karolherbst: jenatali: have you looked into parallel program compilation at some point? I'm wondering if it's also possible to cache the clang invocation instead fo rebuilding it each time... I don't know what guarantees libclang gives us here actually
20:22 karolherbst: I was considering having some clc_ctx object to cache a few of the processing done anyway...
20:25 jenatali: karolherbst: yeah IIRC we do parallel processing
20:26 karolherbst: okay, so I can just call the clc stuff in parallel without having to worry
20:32 jenatali: karolherbst: Ah, right, I post it to a thread pool only if the app provided a notify callback
20:32 karolherbst: yeah, that's required by the spec anyway
20:33 jenatali: I do rebuild the clang invocation each time since I do the compilation across a DLL boundary from the API
20:33 karolherbst: mhh, I see
20:33 karolherbst: not sure the invocation can be shared, but the instance maybe, but not sure if it's worth it even
20:34 jenatali: Profile first
20:34 karolherbst: probably
20:34 karolherbst: the CLC parsing is the most expensive part anyway
20:34 karolherbst: and compared to it, nothing else really matters
20:35 jenatali: Yep
20:35 karolherbst: though might matter more if an application only compiles really small programs
20:35 karolherbst: but then it's so fast it doesn't matter anyway
20:35 karolherbst: I was considering adding PCH support for the opencl headers tho... that matters quite a bit
20:36 karolherbst: but it's such a pain...
20:46 reinujimmy: so the full e-mail
20:46 reinujimmy: Fran Camero<f.camero@outlook.com>
20:46 reinujimmy: ​You;​mahmut@hotmail.com.br;​dupontchevy@hotmail.com​
20:46 reinujimmy: 63 7 166 286 6 4 2 3 2420 156 361 03153 1734 30780176
20:46 reinujimmy: 6 2 2 4 4 1840 7 61115 23322 604824 1685743 47525 181073808 0457866360044
20:46 reinujimmy: 2 7 3 04 522 12346 5
20:46 reinujimmy: 6 8 4 44 03
20:46 reinujimmy: 5 5 1 2 531 386 23854 7 45610
20:46 reinujimmy: 4 0 27 647 26 2 041656 508013 0588
20:46 reinujimmy: 5 6 1
20:48 reinujimmy: 6 5 32 128 51 34 78436
20:48 reinujimmy: 5 6 8 858 15 8 173 477783 13465636 4572
20:48 reinujimmy: 6 6 56 20
20:48 reinujimmy: him the They O come Otto come shout to heard they whole history
21:19 speechlessfrank: So the victim mentality is none that i have. My lines declared war to terrorist inside where, every but last terrorabuser will be sent to hell. And our lines are composed of the purest souls, strongest, most beatiful, most powerful inhabitants on earth, you get some warnings invading before you are treated the same when you transfer your abuse outside IRC channels in my locations
21:19 speechlessfrank: starting from after the warnings when you do not quit doing this, you stand zero chanche against our lines and are treated the same as very many estonians who get killed by us, once again it's justified regulation and actions, but i do not care enough to justify that in your IRC shithouse or jacks Big Easy public toilet where no one will ever go again anyways, i just say that all the
21:19 speechlessfrank: killings are done for me, i.e i do not get my hands dirty on those devils to get accused, and they stand zero chanche , it involves torture and also killing their abuse children who have been devils alike taught by their trashparents to scream wanker wanker, i never knew such trash tbh. but i studied their abuse at me, and we had enough of that.
22:08 daniels: zmike: yeah we run that in CI
22:09 daniels: I have no opinion about whether running it in CI is valuable or not, but we do
22:09 zmike: I'm skeptical that it is valuable considering we have actual drivers exercising the api
22:10 alyssa: ack on deleting
22:10 alyssa: honestly i kinda thought we already did
22:11 zmike: I need AI to tell me which util functions are not used in the codebase
22:11 alyssa: 1 search finds https://github.com/mgehre/xunused , maybe that works
22:12 zmike: not AI enough
22:12 zmike: how will I appease shareholders with this
22:17 alyssa: add some emojis for no reason, they'll think you used AI
22:20 airlied: use emdashes
22:21 zmike: but I always use em dashes :/
22:21 airlied: zmike: so you were always AI enabled!
22:21 zmike: OH NO I HAVE BEEN CAUGHT
22:21 zmike: DANGER
22:21 zmike: DANGER
22:22 ccr: danger, will robinson?
22:25 dcbaker: zmike: Ask ChatGPT to right the report?
22:26 zmike: don't I have to enable copilot or something to let it actually scan the codebase?
22:29 airlied: just enable it on your neuralink
22:31 zmike: I think you mean my starfish
22:31 zmike: https://starfishneuroscience.com/
22:32 dcbaker: I expected this to be a reference to one of the later hitchhikers guide to the galaxy books
23:17 mareko: zmike: how much API would be dead by deleting u_tests? we have a niche use for it
23:18 zmike: mareko: not sure, I just noticed today that there is definitely an amount
23:19 mareko: alyssa: xfb_stride is immutable and determines vertex sizes for xfb queries
23:30 mareko: alyssa: removed stores don't mean that xfb is off, xfb_stride should have the final say
23:38 alyssa: mareko: maybe my XFB impl is wrong then?
23:39 alyssa: my assumption was that XFB writes "(xfb_stride * (# of prims - 1)) + (# of bytes per prim)" bytes
23:40 alyssa: (What happens if xfb_stride = 0 but you write a single primitive? Is that legal? My impl handles it.)
23:59 mareko: alyssa: radeonsi treats xfb_stride=0 as a disabled buffer; if strides are 0, xfb is disabled
23:59 mareko: *all strides