03:56mareko: if you want to know cache and memory latencies, cache sizes, and cache line sizes for your GPU: https://gitlab.freedesktop.org/mesa/gpu-ratemeter#latency-memory-load-latency-in-clock-cycles
03:58HdkR: Oh, kind of like https://github.com/sebbbi/perftest
04:00HdkR: Results are in cycles, is there a way to query the GPU cycle counter frequency to get nanoseconds?
04:04mareko: manual conversion (not possible if the frequency isn't fixed)
04:05HdkR: Ideally at least when running a bench like this you would want to pin the clocks at least
04:06mareko: it actually makes no difference for this one
04:06HdkR: monotonic like a CPU cycle counter?
04:07mareko: the SIMD and the first 2-3 levels of cache use the same clock, so the clock cycle counts are always about the same regardless of frequency
04:08HdkR: On AMD at least I guess :D
04:08mareko: yes
04:09mareko: a fixed frequency is useful if a conversion to nanoseconds is needed, and a fixed core:memory frequency ratio is good to see the same memory latencies every time
04:10HdkR: yea
04:10HdkR: I'd want to do fun comparisons like compare Strix Halo to Snapdragon
04:11HdkR: If there's no frequency query then it's kind of annoying but not impossible
04:12mareko: it can also be used to deduce the cache hierarchy and cache sizes if that information is unknown
04:12HdkR: Yea, I'm definitely curious about that :)
04:22mareko: there are 2 ways to get nanoseconds, and I'm not sure which one is better: 1) convert clock cycles to ns at the end (accurate but needs a fixed frequency), 2) read the timestamp clock in the shader (very easy to convert to ns, but not as useful if the shader frequency is random)
04:26HdkR: hm. I guess I have easy mode on CPUs if there is no way to guarantee a fixed frequency
04:27mareko: the page explains which tool to use to set a fixed frequency on AMD GPUs, it has a nice UI
04:27HdkR: Well, cycle counter on Adreno might also be fixed since it might be reading the same SoC global 19.2Mhz counter even. I'm just not sure
04:28HdkR: and next gen hardware is probably going to decouple that since the CPU can't be locked to 19.2Mhz for ARMv9.1 :D
13:04katzenmann: Hi everyone. I want to ask if the turnip vulkan driver is going to get Vulkan Video support? I have a device with a Adreno 615, video acceleration already works through v4l2m2m but it would be great to have Vulkan Video too since Firefox now supports that.
13:06katzenmann: Is this the right channel for that or should I ask somewhere else?
13:58glehmann: katzenmann: it's not the wrong channel, but there's also #freedreno where the relevant devs might pay more attention
14:01katzenmann: Okay I will ask there. Thank oyu
14:01katzenmann: Okay I will ask there. Thank youi
14:01katzenmann: Okay I will ask there. Thank you
16:12alyssa: glehmann: Is radv planning on VK_EXT_shader_subgroup_partitioned ?
16:13zmike: isn't the real question whether mesa will support GL_NV_shader_subgroup_partitioned ?
16:14alyssa: No?
17:28glehmann: alyssa: I don't think we can better than generic waterfall loop lowering
17:28glehmann: *can do
17:29glehmann: so probably not
17:29alyssa: it's unclear to me if intel's actually better positioned here
18:05zmike: dcbaker: any update on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41605
18:05dcbaker: zmike: No, I've mucked around a little bit with the macros, but haven't gotten it all working
18:06dcbaker: C++ doesn't allow mixed designated and undesignated initializers
18:06dcbaker: which our macros make heavy use of
18:06zmike: 🤕
20:47zmike: this drm-shim MR is hitting historically comical levels of CI failure