[Mesa-dev] [RFC PATCH 0/7] gallium: Video postprocessor rework

[Thomas Hellstrom]

So after an off-line chat with Christian we decided to drop this series,
since I don't have the cycles to fix this up.

For completeness, if anybody decides at some point to (re)use some of
the code, some comments below.

On 03/03/2017 01:32 PM, Christian König wrote:
> Hi Thomas,
>
> Am 02.03.2017 um 21:00 schrieb Thomas Hellstrom:
>> This patch series introduces a postprocessor abstraction. It could be
>> promoted
>> to a gallium interface but for now it's implemented as a utility.
>
> Well, first of all use a gallium interface for this. Putting this into
> utility doesn't look like it makes much sense when it is supposed to
> be a driver interface.
>
>> The idea
>> is that a driver wanting to implement the whole or part of the
>> postprocessing
>> pipeline using video hardware can do that. It also significantly
>> simplifies
>> implementing a future full postprocessor pipeline also in the libVA
>> state tracker.
>>
>> Some highlights:
>> - The postprocessor abstraction is very similar to the vl compositor
>> API,
>> except it add filters.
>
> NAK on that, we already had that design and it was a pain to support.
>
> If you want to implement parts of the post processing pipeline in the
> driver make each pipeline step a separate object.

The compositor API very well suited our needs and was very easy and
straightforward to work with. I guess mostly because it resembles the
postprocessing pipeline of both VAAPI, VDPAU and DXVA/D3D11.

>
>> - The bounce buffer cache. Caches buffers where we know more about
>> the usage.
>> This may duplicate driver functionality but for drivers with strongly
>> typed
>> buffers, it's a big win.
>
> That's similar to what I've done for the video buffers, but in general
> I think that this doesn't belong into the state tracker.
>
> The driver should implement buffer reuse if it can do this without
> problems, but how many buffers should be in there and when they are
> reclaimed is strongly hardware dependent.

True. Although for drivers with strongly typed buffers, that becomes
difficult since caches needs to be quite large to facilitate hits. The
caching needs for this pipeline is also special in that the number of
cached buffers is small very predictable and there's no need to wait for
idle before reusing buffers...


>
>> - Moving the bicubic filter. Avoids duplicated code and makes things
>> like
>> rotation and blending straightforward.
>
> A BIG NAK on that as well. The bicubic filter doesn't work on all
> hardware, so creating the shaders all the time while it isn't use is
> clearly not an option.
>
> Additional to that I would rather remove functionality from the
> compositor than stuffing even more into it.

Compiling on-demand is an easy fix.

Having all scaling options in one place logically and physically seemed
attractive and helped avoiding unwanted behaviour like filtering
overlaid  or already scaled surfaces and video-background borders,
double scaling of overlay surfaces. Also enabled blending and rotation.


Thanks,
Thomas

>
>> - A g3dvl implementation. Mostly replicates the old implementation
>> using the
>> vl compositor, but with provisions to replace part of the postprocessing
>> pipeline.
>> - State tracker modifications for VDPAU and VA.
>>
>> - Tested with mplayer -vo vdpau software playback on Nouveau.
>
> Please test that with radeon hardware as well if possible. Nouveau
> doesn't fully support all the functionality and project like Kodi
> don't test with it.
>
> Regards,
> Christian.
>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwICaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=GDt3ZtrRjpa7Se4bsMYXF18gBs6IXAqtSW_3Y3df0Bs&s=-HnyAt6aoAvWpesLw7KAHyyQmiJVv43cJNL7VmIjOh0&e=
>
>
>