<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 8, 2023 at 1:37 PM Alex Deucher <<a href="mailto:alexdeucher@gmail.com">alexdeucher@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Dec 8, 2023 at 12:27 PM Joshua Ashton <<a href="mailto:joshua@froggi.es" target="_blank">joshua@froggi.es</a>> wrote:<br>
><br>
> FWIW, we are shipping this right now in SteamOS Preview channel<br>
> (probably going to Stable soon) and it seems to be working as expected<br>
> and fixing issues there in instances we need to composite, compositor<br>
> work we are forced to do would take longer than the compositor redzone<br>
> to vblank.<br>
><br>
> Previously in high gfx workloads like Cyberpunk using 100% of the GPU,<br>
> we would consistently miss the deadline as composition could take<br>
> anywhere from 2-6ms fairly randomly.<br>
><br>
> Now it seems the time for the compositor's work to complete is pretty<br>
> consistent and well in-time in gpuvis for every frame.<br>
<br>
I was mostly just trying to look up the information to verify that it<br>
was set up correctly, but I guess Marek already did and provided you<br>
with that info, so it's probably fine as is.<br>
<br>
><br>
> The only times we are not meeting deadline now is when there is an<br>
> application using very little GPU and finishes incredibly quick, and the<br>
> compositor is doing significantly more work (eg. FSR from 800p -> 4K or<br>
> whatever), but that's a separate problem that can likely be solved by<br>
> inlining some of the composition work with the client's dmabuf work if<br>
> it has focus to avoid those clock bubbles.<br>
><br>
> I heard some musings about dmabuf deadline kernel work recently, but not<br>
> sure if any of that is applicable to AMD.<br>
<br>
I think something like a workload hint would be more useful.  We did a<br>
few patch sets to allow userspace to provide a hint to the kernel<br>
about the workload type so the kernel could adjust the power<br>
management heuristics accordingly, but there were concerns that the<br>
UMDs would have to maintain application lists to select which<br>
heuristic worked best for each application.  Maybe it would be better<br>
to provide a general classification?  E.g., if the GL or vulkan app<br>
uses these extensions, it's probably a compute type application vs<br>
something more graphics-y.  The usual trade-off between power and<br>
performance.  In general, just letting the firmware pick the clock<br>
based on perf counters generally seems to work the best.  Maybe a<br>
general workload hint set by the compositor based on the content type<br>
it's displaying would be a better option (video vs gaming vs desktop)?<br>
<br>
The deadline stuff doesn't really align well with what we can do with<br>
our firmware and seems ripe for abuse.  Apps can just ask for high<br>
clocks all the time which is great for performance, but not great for<br>
power.  Plus there is not much room for anything other than max clocks<br>
since you don't know how big the workload is or which clocks are the<br>
limiting factor.<br></blockquote><div><br></div><div>Max clocks also decrease performance due to thermal and power limits. You'll get more performance and less heat if you let the GPU turn off idle blocks and boost clocks for busy blocks.<br></div><div><br></div><div>Marek<br></div><br></div></div>