-
Notifications
You must be signed in to change notification settings - Fork 310
va: Add VAConfigAttribLowLatency #841
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
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. |
|
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. |
0d5f2b0 to
b4708a5
Compare
AMD VCN supports this, and I have linked Mesa MR implementing it for radeonsi driver. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32369
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. |
|
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. |
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. |
|
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. |
Driver should minimize latency of operations, possibly at the cost of increased power use. Signed-off-by: David Rosca <[email protected]>
b4708a5 to
f4c33f5
Compare
Driver should minimize latency of operations, possibly at the cost of increased power use.
Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32369