[Libva] [libva-intel-driver PATCH 03/10] Add support for P010 in vaPutSurface()

[Emil Velikov]

On 9 December 2015 at 04:09, Xiang, Haihao <haihao.xiang at intel.com> wrote:
> On Mon, 2015-12-07 at 17:33 +0000, Emil Velikov wrote:
>> On 6 December 2015 at 16:38, Xiang, Haihao <haihao.xiang at intel.com>
>> wrote:
>> > > -----Original Message-----
>> > > From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>> > > Sent: Friday, December 4, 2015 10:12 PM
>> > > To: Xiang, Haihao
>> > > Cc: libva at lists.freedesktop.org
>> > > Subject: Re: [Libva] [libva-intel-driver PATCH 03/10] Add support
>> > > for P010 in
>> > > vaPutSurface()
>> > >
>> > > On 3 December 2015 at 18:13, Xiang, Haihao <haihao.xiang at intel.co
>> > > m> wrote:
>> > > > Currently it converts P010 to RBGA32
>> > > >
>> > > > v2: P010 has interleaved UV planar (Peng)
>> > > Typo in RBGA32 ? Don't think I've seen such format before.
>> >
>> > Yes, it is a typo, thanks for catching it.
>> >
>> > >
>> > > Also the commit message explain say "why" we need this. The
>> > > current "there
>> > > is no native support we emulate things" does not sound at all
>> > > appealing.
>> >
>> > vaPutSurface() is only implemented in a X window system.
>> Hmm in this case does things just crash when one tries to use
>> vaPutSurface on Android ?
>
> VA_STATUS_ERROR_UNIMPLEMENTED is returned if someone tries to use
> vaPutsurface() with libva-intel-driver on Android. AFAIK, user needn't
> vaPutsurface() if he/she wants to try VAAPI on Android now.
>
>> How are the in-tree tests suppose to work in
>> this case ?
>
> pvr driver implements vaPutSurface() on Android.
>
So it's a single driver interface ? Doesn't that make the API less
flexible and enforces the user to add hacks in their code ? Regardless
what's done is done. API is there and cannot be removed without
bumping the major version.

>>
>> > The drawable to vaPutSurface() is in RGBA32, so we convert P010 to
>> > RGBA32. We can add P010 to R10B10G10A2 once the drawable is in
>> > R10G10B10A2.
>> >
>> The header (va_x11.h) does not say anything about this limitation
>> (The
>> drawable to vaPutSurface() is in RGBA32). Is that intentional ?
>
> No, vaPutSurface() doesn't have such limitation. We will add the
> support for R10G10B10A2 in vaPutsurface() if we can get a R10G10B10A2 render target.
>
>>
>> Afaict vaCreateSurface _does_ accept various formats, so I'm
>> wondering
>> how are things going to work if one requests/creates a non RGBA32 one
>> ?
>
> A X drawable isn't a VA surface, you can't use vaCreateSurface() to
> create a drawable.
>
I guess the idea behind the latter two is "who enforces that RGBA32
drawable is created/supported and is the user aware (is it documented)
about that". Skimming through the libva public header(s) it's not
obvious, perhaps I should be looking at another place ?

Thanks for enlightening answers !

Emil