On 9 December 2015 at 04:09, Xiang, Haihao <[email protected]> wrote: > On Mon, 2015-12-07 at 17:33 +0000, Emil Velikov wrote: >> On 6 December 2015 at 16:38, Xiang, Haihao <[email protected]> >> wrote: >> > > -----Original Message----- >> > > From: Emil Velikov [mailto:[email protected]] >> > > Sent: Friday, December 4, 2015 10:12 PM >> > > To: Xiang, Haihao >> > > Cc: [email protected] >> > > Subject: Re: [Libva] [libva-intel-driver PATCH 03/10] Add support >> > > for P010 in >> > > vaPutSurface() >> > > >> > > On 3 December 2015 at 18:13, Xiang, Haihao <[email protected] >> > > 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 _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
