[Libva] [PATCH 6/7] shaders: vpp: gen7: use yuv to rgb matrix to compute rgb values

[Zhao Yakui]

On 11/05/2015 06:22 PM, Lionel Landwerlin wrote:
> On 05/11/15 00:31, Zhao Yakui wrote:
>> On 11/04/2015 11:27 PM, Lionel Landwerlin wrote:
>>> ---
>>> src/shaders/post_processing/gen7/YUV_to_RGB.g4a | 626
>>> ++++++++++++----------
>>> src/shaders/post_processing/gen7/pl2_to_rgbx.g75b | 528
>>> +++++++++---------
>>> src/shaders/post_processing/gen7/pl2_to_rgbx.g7b | 528
>>> +++++++++---------
>>> 3 files changed, 909 insertions(+), 773 deletions(-)
>>>
>>> diff --git a/src/shaders/post_processing/gen7/YUV_to_RGB.g4a
>>> b/src/shaders/post_processing/gen7/YUV_to_RGB.g4a
>>> index 24616dc..6af651f 100644
>>> --- a/src/shaders/post_processing/gen7/YUV_to_RGB.g4a
>>> +++ b/src/shaders/post_processing/gen7/YUV_to_RGB.g4a
>>> @@ -386,34 +386,36 @@
>>> mov (8) fBUFFER_V(0, 0)<1> r[a0.0, 1]<16;8,2>:ub
>>> mov (8) fBUFFER_V(1, 0)<1> r[a0.0, 17]<16;8,2>:ub
>>>
>>> - add (16) fBUFFER_U(0, 0)<1> fBUFFER_U(0, 0)<8;8,1> -128.0f
>>> - add (16) fBUFFER_V(0, 0)<1> fBUFFER_V(0, 0)<8;8,1> -128.0f
>>
>> As far as I know, the value in fBUEER_U/V is still in [0 255] range.
>> So I think that it still should be extraced by 128 before it is
>> normalized to [0..1].
>
> Looking at the green component for example, given the following
> coefficients for Y, U and V :
>
> CY = 1.0
> CU = -0.344
> CV = -0.714
>
> This is what the current shader does :
>
> green = ((Y + (U - 128) * CU + (V - 128) * CV) * 0.0039216) * 255
>
> The shader in this patch does this :
>
> green = (Y * 0.0039216 + (U * 0.0039216 - 128.0 / 255) * CU + (CV *
> 0.0039216 - 128.0 / 255) * CV) * 255
>
> This looks equivalent to me given that
>
> 128.0 / 255 ~= 128 * 0.0039216
>
> we just distribute the [0..1] normalizing factor earlier.

It seems that you are reusing the conversion matrix defined for render 
processing.
So it is correct that it is normalized before using the conversion matrix.

>
> It's possible to do what you suggest, but it would require more
> instructions.
> Maybe I'm missing some precision stuff that is specific to the hardware?
>
>>
>>
>>> + mul (16) fBUFFER_Y(0, 0)<1> fBUFFER_Y(0, 0)<1> 0.0039216f
>>> + mul (16) fBUFFER_U(0, 0)<1> fBUFFER_U(0, 0)<1> 0.0039216f
>>> + mul (16) fBUFFER_V(0, 0)<1> fBUFFER_V(0, 0)<1> 0.0039216f
>>
>