02:29 Mangix: hrm I checked mesa to see if vulkan hardware decode would be possible. Looks like that's a big fat no: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_video_enc.c?ref_type=heads#L3538
02:53 airlied: you can just lie for that function to get the basic hw to work, it just won't pass vulkan compliance
03:17 Mangix: airlied: you mean with env RADV_PERFTEST=video_decode ?
03:38 airlied: Mangix: yes, but you'd need to add support for older versions of UVD I suspect
03:43 airlied: the code has TONGA+ for UVD in it
03:47 Mangix: lovely
11:35 Venemo: Mangix: that was already discussed on this channel last week. we don't support Vulkan video on HW. in theory we could, but there is not much interest in doing so.
11:37 Venemo: Mangix: there may be ways to solve that, but until then please just use vaapi
11:37 Venemo: as a side note, Vulkan video works well on newer HW
15:13 johnny0: agd5f: for the power measurement on CIK/VI cards, how much of the reported value is the sampling process itself?
15:14 agd5f: johnny0, what do you mean?
15:14 johnny0: i see that the continuous averaging mode adds a few watts, but I'm wondering how much that is on top of the amount for just sampling
15:14 johnny0: like, is gathering samples and tossing them into the circular buffer a few microwatts? or something more?
15:15 johnny0: because I'm not seeing a difference in reported power when always sampling versus only sampling for 1ms
15:21 agd5f: johnny0, I'm not following. the CPU is doing the sampling. the SMU only provides instantaneous power on those chips
15:29 johnny0: so from what see through testing, a sending PmStatusLogStart starts collecting samples to a ring buffer, and then a follow up call to PmStatusLogSample returns the average of the samples collected
15:31 johnny0: normally sending PmStatusLogSample also seems to stop collection of samples -- so successive calls will return zero (or perhaps the last average)
15:31 johnny0: but there seems to be another state that can PmStatusLogStart can end up in, where successive calls to PmStatusLogSample *does* return new results
15:32 johnny0: this seems to be the continuous averaging mode I was talking about, and it definitely guzzles a few watts
15:37 agd5f: oh, I guess, it does average it, but you have to wait for the sampling period to end to get a result. I don't really remember the details off hand.
15:38 johnny0: yeah, so I'm wondering if the sampling itself eats a big chunk of power
15:40 johnny0: (for the laptop battery drain angle)
15:40 agd5f: probably not that much. the SMU is always running, it just kicks off a sampling period. Not sure how the SMU actually processes that command through. If it's part of it's event loop or if it's blocking
15:41 agd5f: if you wanted to handle it more gracefully, you could probably just cache the results when you query it and then if there are multiple calls within 500ms, you can just return the cached value.
15:42 johnny0: yeah, I have an implementation which caches the last average, but resets the sampling after each call
15:44 johnny0: so polling more frequently gets less-smooth results, but ones that might paint a better picture of what's going on w.r.t. power spikes
15:50 johnny0: an non-graphical example would be clpeak -- with 500ms averaging I can't how bad certain modes are w.r.t. power use because the tests finish too fast
15:57 johnny0: on the graphics side, mangohud + a game works beautifully, even with per-frame updates and FPS in the hundreds
15:59 johnny0: the display itself becomes a limitation at that point due to ghosting, but it's one of those good problems to have
16:22 johnny0: agd5f: anyway, thanks for bearing with me -- I'll try to cook up a variant which rate-limits the updates to 500ms but avoids blocking
16:24 agd5f: johnny0, sounds good. thanks!
22:59 fililip: Does anyone know if VCN5 supports encoding/decoding yuv444 for any supported codec?
23:50 Mangix: Venemo: I see that newer cards work fine based on the code.