00:32 mareko: why was VK_PRIMITIVE_TOPOLOGY_META_RECT_LIST_MESA added?
00:38 mareko: was there a plan to use it outside RADV?
00:56 BlueMatt: airlied: does your comment at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42723#note_3579748 imply that you want, eg, calls to the nir_lower_cooperative_matrix_flexible_dimensions pass to use a square breakdown (i.e. the anv pass needs to learn how to lower partial M+N-gran) or just that you want there to not be different granularity based on type?
04:49 airlied: BlueMatt: I think in order for things like reductions and transpositions to work, they are best being square
04:49 airlied: different squares on types is fine
04:50 airlied: but if you only support 16x8 matricies and someone transposes into 8x16 then things fall apart a bit
05:35 airlied: glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43686 at least has the vk import and renames in it
06:51 MoeIcenowy: Strange, is imagination@lists.freedesktop.org a real thing? I didn't see imagination on https://lists.freedesktop.org/mailman/listinfo/
06:51 MoeIcenowy: but I saw mails sent to this address
07:04 phasta: When will drm-misc-fixes be merged vor v7.2?
08:01 mlankhorst: phasta: ?
08:02 mripard: phasta: drm-misc-fixes is sent every week, so it happened a handful of times already. What are you concerned about?
08:02 mlankhorst: I didn't make plans for the one this week yet, but likely later today or tomorrow
08:03 phasta: mripard: we had to do a last minute revert. https://lore.kernel.org/dri-devel/20260811163139.99746-1-tvrtko.ursulin@igalia.com/
08:03 phasta: tursulin already pushed it onto misc-fixes, so we should be fine
08:04 MrCooper: phasta: adding the fair scheduling policy, making it the default and removing the other policies, all in the same cycle, was quite optimistic, to put it diplomatically :)
08:05 phasta: MrCooper: certainly, it is a lesson learned. It was, however, on-list for over a year, reviewed by many parties, and tested intensively on several platforms.
08:05 MrCooper: nothing can replace real-world testing
08:05 phasta: True.
08:07 phasta: Moving fair scheduling forward would be down far more slow-paced next time.
08:07 phasta: *done
08:09 MrCooper: the reverts bring us back to a state that could have landed a long time ago
08:14 phasta: I never saw much of an "us" on-list :] Constructive ideas like on merge strategies, on-time, without hindsight-bias will certainly always be welcome
08:16 MrCooper: yeah it's too bad I didn't realize this earlier, when it seems so obvious now
08:34 tursulin: It's okay, series was structured to land in multi-release drops from the start so the revert is not too bad. Better in late RC than post release.
13:24 MrCooper: phasta: your cheap shots at the discussion above in 932892b196f7bbba7f5e9bff22f9b484854aaccc.camel@mailbox.org aren't appreciated. What I raised is that this transition was attempted way too quickly (no similar non-trivial transition is realistic in a single cycle), it should have been done at the very least over 3 cycles, one for each step I listed. Why exactly something broke or how it could be fixed is irrelevant for this.
13:25 phasta: MrCooper: Who are you, actually?
13:26 MrCooper: not sure what you're asking, you know who I am
13:32 phasta: I do not. Matt?
13:34 MrCooper: /whois MrCooper
13:37 phasta: Certainly a plot twist ;p
13:37 phasta: I did agree with you, and still do. It should have been done differently
17:36 rodrigovivi: mripard: mlankhorst: ack on https://lore.kernel.org/all/20260805071152.1225416-7-mallesh.koujalagi@intel.com/ and https://lore.kernel.org/all/20260805071152.1225416-8-mallesh.koujalagi@intel.com/ to go through drm-xe-next? we have xe-ras stuff that depends on that and development around that is pretty active... but I can merge through misc and deal later with conflicts if you prefer
19:01 karolherbst: Soo.. I'm confused about get_query_result_resource today. I thought the purpose of that was to be able to submit a timestamp read to the driver/gpu and then read out the context or do something with the resource later. But a bunch of driver require PIPE_QUERY_WAIT with it to contain proper values and I'm wondering why waiting is required? Like the
19:01 karolherbst: GPU should write to it once it gets to it, no?
19:02 karolherbst: "``get_query_result_resource`` is used to store the result of a query into a resource without synchronizing with the CPU. "
19:04 zmike: it's to implement GL qbos
19:05 zmike: but nothing in GL actually uses QBOs in a perf path so at least some drivers just do it through the CPU path instead of doing the whole compute shader aggregate dance
19:05 karolherbst: I mean I see also fails with radeonsi and it's doing the compute shader thing
19:05 zmike: like I said
19:05 karolherbst: but maybe PIPE_QUERY_WAIT means something different?
19:05 zmike: nothing uses this mechanism
19:06 zmike: cts/piglit tests are the only thing
19:06 karolherbst: I want to instead of fetching timestamps on the CPU side...
19:06 karolherbst: in theory it would be useful for CL event profiling because you can do profiling without stalling the GPU
19:07 karolherbst: but if I need to pass in PIPE_QUERY_WAIT along, then I guess that's what I have to do?
19:07 karolherbst: drivers can always ignore it when it doesn't matter I guess
19:09 zmike: I don't really understand the interaction with PIPE_QUERY_WAIT
19:10 zmike: maybe an implementation detail
19:20 alyssa: i have no idea how qbo's work on asahi
19:20 alyssa: but i'm sure they're terribly broken
19:21 zmike: as long as you can pass like 5 CTS cases and 1 piglit test You Have Implemented
19:22 alyssa: update: it's terribly broken
19:22 alyssa: and also there's this https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/asahi/libagx/query.cl#L80-110
19:23 zmike: that's a beaut
19:26 karolherbst: right.. I really only want the driver to tell the GPU to write a timestamp to some GPU memory so I can read it out in the future so I can 1. take a timestamp before a bunch of GPU commands and 2. take a timestamp after a bunch of GPU commands and then 3. tell the application when something began and stopped executing
19:28 karolherbst: and letting the GPU write the timestamp as part of its commands feels like the natural fit that's kinda close to reality
19:29 karolherbst: what I do want to avoid is that "application turns on profiling" leads to constant CPU side stalls, because now the driver has to flush and wait for the GPU to become idle constantly which might impact perf characteristics
19:29 karolherbst: but maybe none of this matters
19:49 jannau: I had fixing the GL timestamping on my todo list. I think there is mostly just one huge bug. If all work is already submitted the driver just queries the current timestamp instead of timestamp query which depends on the previous (still ongoing) work
20:09 karolherbst: maybe I should just dispatch shaders reading out the timestamp 🙃
20:09 karolherbst: but that might cause weird ordering issues
20:10 airlied: jani: I think the suggestion we feed next a post merged -fixes into -next is a reasonable ask, but not sure if we have to then do that across drm, misc and intel
20:11 jannau: isn't that what the asahi gallium driver already does when there is non-submitted
20:12 airlied: jani, rodrigovivi : if any remembers the various iterations of cherry-pick vs cherry-pick -x that would be good, I've blocked it all
20:16 rodrigovivi: airlied: I believe we could get that with a simple change in dim... to generate a drm-for-next between the last next and the first topic branch... then we stop all of the individual -next feeding linux-next...
20:17 rodrigovivi: but what's the doubt on the cherry-pick -x?
20:18 rodrigovivi: perhaps drm-for-linux-next to be clear
20:28 airlied: rodrigovivi: I know in the past we used to use -x on cherry-picks but there was some push-back because I believe we ended up with commit ids that weren't in Linus' tree yet
20:32 agd5f: We still use -x for traceability