[Libva] Add coefficients yuv to rgb conversion

[Zhao Yakui]

On 11/06/2015 05:00 AM, Gilles Chanteperdrix wrote:
> On Thu, Nov 05, 2015 at 02:13:29PM +0000, Emil Velikov wrote:
>> On 4 November 2015 at 00:54, Gilles Chanteperdrix
>> <gilles.chanteperdrix at xenomai.org>  wrote:
>>> On Tue, Nov 03, 2015 at 04:56:14PM +0000, Lionel Landwerlin wrote:
>>>> Hi,
>>>>
>>>> Following your comments on the previous patch, here is an serie to add
>>>> support for coefficients passed down to the EUs for the vpp yuv to rgb
>>>> conversion path.
>>>
>>> Hi,
>>>
>>> sorry for intruding on the mailing list, but this is a topic on
>>> which I worked recently. First question is: I implemented yuv to rgb
>>> conversion using GLSL shaders (only for yuv420p, but this could be
>>> easily implemented for other pixel formats), and the code is
>>> relatively simple:
>>> https://git.click-hack.org/vplayer.git/tree/lib/yuv420p_frag.glsl
>>> What is the gain of using libva instead?
>>>
>> I'm no expert in the libva code so take this with a grain of salt.
>>
>> For doing things the GLSL way - you have an extra GL context
>> creation/management not to mention the overhead of
>> parsing/compiling/linking etc the GLSL shader. While the result (from
>> a hardware's perspective/instructions emitted) may be almost
>> identical, doing things within i965 libva driver should be less
>> CPU/memory intensive.
>
> Well, compiling/linking the GLSL shader happens only once at
> initialization. The advantage I see with a GLSL shader is that it
> looks more portable, OpenGL with GLSL is almost universally
> available, whereas libva runs on Linux only.

I agree that the GLSL shader is more portable.
But as far as we know, the sampler defined in 3D is quite 
simple.(LINEAR, NEAREST). When doing the scaling conversion, the quality 
looks quite poor.

The VPP in libva driver can make good use of hardware feature and have 
better quality when doing the scaling conversion.

Thanks
    Yakui

>