[Libva] [PATCH 1/3] Declare I010 support for QueryImageFormats

[Mark Thompson]

On 06/12/16 01:37, Zhao Yakui wrote:
> On 12/06/2016 01:49 AM, Mark Thompson wrote:
>> Signed-off-by: Mark Thompson<sw at jkqxz.net>
>> ---
>> It's already returned as a usable surface format for the video processor, but is missing from the list returned by vaQueryImageFormats().
>>
>>   src/i965_drv_video.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
>> index 79a2aec..d83427c 100644
>> --- a/src/i965_drv_video.c
>> +++ b/src/i965_drv_video.c
>> @@ -268,6 +268,8 @@ i965_image_formats_map[I965_MAX_IMAGE_FORMATS + 1] = {
>>         { VA_FOURCC_BGRX, VA_LSB_FIRST, 32, 24, 0x00ff0000, 0x0000ff00, 0x000000ff } },
>>       { I965_SURFACETYPE_YUV,
>>         { VA_FOURCC_P010, VA_LSB_FIRST, 24, } },
>> +    { I965_SURFACETYPE_YUV,
>> +      { VA_FOURCC_I010, VA_LSB_FIRST, 24, } },
>>   };
>>
> 
> The format returned by vaQueryImageFormats is mainly used for calling vaCreateImage. That is to say: if we want to add the I010 to the image_format list, we should firstly add the support in i965_CreateImage.
> 
> For the 10-bit surfaces(P010, I010), it will be preferred that it is created by using vaCreateSurfaces. If the image is needed, the vaDeriveImage can be used instead.
> 
> Is it OK to you?

Right, testing a bit more I can see there is more support missing than I initially thought.  It needs support throughout the VPP processing chain for vaGetImage() in particular to work, so the cases I was hoping for aren't yet possible.

The use-case I'm thinking of here is to be able to move data back and forth between software (typically LSB-packed three-plane YUV 4:2:0, here being called I010: e.g. libx264, libvpx, libavcodec) and hardware (all MSB-packed two-plane YUV 4:2:0, i.e. P010) without an additional shift/(de)interleave step in software.  Since we want to avoid CPU involvement where possible, full image support is helpful because we can get the GPU to deal with the copying/conversion between normal memory and surfaces - vaDeriveImage() is not really sufficient because the CPU then has to do the copy (and also has to deal with the uncached memory requiring the streaming operations, making it even more awkward to use).

I'll drop this patch for now, since the changes required to make that work are somewhat more involved than I was hoping.

Thanks,

- Mark