libva icon indicating copy to clipboard operation
libva copied to clipboard

add new interface vaMapBuffer2 for map operation optimization

Open XinfengZhang opened this issue 5 years ago • 1 comments

add new vaMapBuffer2 backend driver need some usage hint to optimize the operation

Signed-off-by: Carl Zhang [email protected]

XinfengZhang avatar Feb 24 '20 08:02 XinfengZhang

@XinfengZhang What the current status? This change can significantly improve encoding performance.

IlyaSergeyev avatar Jul 30 '20 14:07 IlyaSergeyev

What's the status of this? It would be great to have it merged. Currently the issue in Mesa is that mapping all buffers read+write leads to bad performance on dGPUs.

nowrep avatar Oct 07 '23 18:10 nowrep

If I recall correctly, it was not merged because of lack of implementation on the (intel) driver side. However, considering that new driver appeared (vaon12) and obviously it has interest in this feature, I think we need to go forward with it. PR needs to be rebased and conflicts which appeared while it was hanging around resolved (@XinfengZhang : can you, please, do that? or I can pick it up). And PR needs re-review.

@nowrep : you are looking for this PR in regards of mesa's vaon12?

dvrogozh avatar Oct 07 '23 18:10 dvrogozh

That sounds good, thanks!

My interest for this PR is radeonsi but it will benefit all Mesa drivers, so that also includes vaon12.

nowrep avatar Oct 07 '23 18:10 nowrep

Is there any discussion on mesa side regarding this? Maybe some issue filed?

dvrogozh avatar Oct 07 '23 18:10 dvrogozh

This PR came up in discussion of this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25597

Context: Mesa always mapped the buffer as write-only. Up until recently vaDeriveImage was not implemented for multi-planar formats on radeonsi, so applications would fallback to vaPut/GetImage. That's not the case anymore and it is now an issue when applications try to read from the mapped memory. The simple fix was to map the buffer as read+write, but it regressed performance when used for writing only so the change was reverted.

nowrep avatar Oct 07 '23 18:10 nowrep

@nowrep, @sivileri : we are ready to merge in this libva change as soon as some driver(s) will raise a PR on their side to use this new VAAPI feature. Can you, please, help to prepare a change on mesa side and get it tried out?

dvrogozh avatar Oct 09 '23 14:10 dvrogozh

Mesa implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25620

nowrep avatar Oct 09 '23 15:10 nowrep

Thank you @nowrep for quick follow up. Quoting perf example from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25620#note_2119488:

"Example with patched ffmpeg to use vaMapBuffer2:

ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc=size=1280x720 -vf format=nv12,hwupload -c:v h264_vaapi -async_depth 1 -f null -

Before (read+write): 540fps
After  (write only): 620fps

It's around 10-15% faster depending on the resolution. At 2048x2048 it's 160fps before and 180fps after."

dvrogozh avatar Oct 10 '23 20:10 dvrogozh

I don't see a reason to hold it on any further. Merging in.

dvrogozh avatar Oct 10 '23 20:10 dvrogozh