[Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

[Mark Thompson]

On 29/09/17 17:25, Leo Liu wrote:
> On 09/29/2017 11:37 AM, Leo Liu wrote:
>> On 09/29/2017 10:45 AM, Andy Furniss wrote:
>>> Marek Olšák wrote:
>>>> Can you test this?
>>>
>>> My mpv test case is fixed by
>>>
>>> radeonsi/uvd: fix planar formats broken since f70f6baaa3bb0f8b280ac2eaea69bb
>>
>> With Andy's information that this happens on newer MPV, and with Marek's fixes, we know MPV is changed to
>> interop decode buffer instead of previous output buffer, which means the CSC is done within MPV by most likely calling GL directly instead of
>> previously done by VL shader. This might increase CPU usage for MPV in general.

How would you intend to render without GL (or similar, like Vulkan)?  While it might be possible to support all possible variations (of colour primaries / transfer characteristic / matrix coefficients / range / subsample location) in Mesa colour conversion, VAAPI does not currently allow this detail to be expressed.  For playback cases the user may also want other features which modify the output directly (e.g. brightness) or which influence how the image is rendered (e.g. alternative scaling methods suited to animation rather than live video).

I am preparing a patch to add support for specifying the colour properties (in the usual five dimensions) to libva for VPP, but obviously the drivers would need to read and act upon them for it to do anything useful.

> I had a quick test between older and newer MPV on a system, there is no obvious difference on CPU usage, which is good.
> 
> And we may expect to get more flexibilities with the change.

Adding the proper export support to libva and the associated series in Mesa drops CPU use for worst-case high-bitrate H.265/4K/10-bit video from something like ~1 CPU to ~0.05 CPUs on a normalish desktop system.

(Previously it was forced to go through a download-upload step in order to get the surfaces into GL.)

Thanks,

- Mark