Skip to content

Conversation

@nowrep
Copy link

@nowrep nowrep commented Nov 27, 2024

Driver should minimize latency of operations, possibly at the cost of increased power use.

Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32369

@RushingAlien
Copy link

Hey it's been over a year, I just wanna remind maintainers of the existence of this PR in case it was missed and or forgotten.

@XinfengZhang
Copy link
Contributor

I understand that you want this just because you want HW still work on highest frequency even there is few tasks. then each frame will take less time.
my question is: is there any HW supporting? or some backend driver could implement it? because in most of time, combination of minigop structure (P frame only, 1 reference frame only) and quality_level (highest value) could meet most of requirement.

@nowrep
Copy link
Author

nowrep commented Dec 9, 2025

is there any HW supporting? or some backend driver could implement it?

AMD VCN supports this, and I have linked Mesa MR implementing it for radeonsi driver.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32369

because in most of time, combination of minigop structure (P frame only, 1 reference frame only) and quality_level (highest value) could meet most of requirement.

That can't be used, because this has no relation to ref structure.

The issue this is trying to solve is the case when there is idle time between frames, for example recording screen or game streaming.

For screen recording the latency is not a problem, because FW will ramp up the clocks to reach the target fps. But there is no benefit to set max clocks in this case, as that would only waste power.

For game streaming the latency is very important. Here we want the clocks to be max to get the encoded frame as soon as possible. But there is no way to detect this usecase just from the encode parameters. We need a hint to the driver to enable this.

@XinfengZhang
Copy link
Contributor

from this perspective, looks we need another kind of parameter: such as VAEncMiscParameterUsageSenario, or something like this. of cource , current one also could be used to resolve the problem you mentioned.

@dec05eba
Copy link

dec05eba commented Dec 9, 2025

For screen recording the latency is not a problem, because FW will ramp up the clocks to reach the target fps. But there is no benefit to set max clocks in this case, as that would only waste power.

I do use this feature for screen recording as well for high resolution high fps cases (4k 144 fps av1) while playing heavy games because if you happen to play a video on your system that also uses vaapi then the active vaapi session (screen recording) will run at a lower framerate, even after you close the video player (which prevents it from running at even 4k 60 fps). This low latency option prevents both of those issues (running at a much lower framerate when watching a video and also from not being able to go back to regular framerate after closing the video). But that might be an issue in the amd driver, I dont know. I believe it's still needed for consistent frame times at those high end cases.

@XinfengZhang
Copy link
Contributor

it should not be an API problem, it is about the policy about the task dispatch. I am not sure AMD driver behavior. but for intel. there are two dimensions: 1. one session will occupy more HW bandwidth if you close another one. 2. less task may lead to many idle, so GPU will drop frequency.
with this mode , it just mean it force GPU work on higher frequency, even there is few tasks.

Driver should minimize latency of operations, possibly at the cost of
increased power use.

Signed-off-by: David Rosca <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants