[Libva] Master sync with libva31 branch

[Yuan, Shengquan]

On Thu, Aug 27, 2009 at 8:27 PM, Gwenole
Beauchesne<gbeauchesne at splitted-desktop.com> wrote:
> Hi,
>
> On Thu, 27 Aug 2009, Yuan, Shengquan wrote:
>
>> Now five patches from Gwenole
>> (http://www.splitted-desktop.com/~gbeauchesne/libva/patches/ 104,
>> 301,302,303,304) were added into master branch. I also combined
>> vaPutImage/vaPutImage2, vaAssociatedSubpicture/vaAssociatedSubpicture2
>> and bumped VAAPI version to 0.31 (the new SONAME is libva.so.1 now). The
>> old libva30 was put into "libva30" branch. Please help to see if my
>> change will break something.
>
> Thanks, I will try to have a look ASAP.
>
>> Besides these changes, I also want to remove "context" from
>> vaSyncSurface API, since I think sometimes a surface may not associate
>> with a context, but we want to get its status. If nobody disagree with
>> it, I will check in the change.
>
> I have checked all my drivers and each surface already links to its parent
> context when it is passed to vaCreateContext(). This shouldn't be a
> problem to me.
>
> BTW, what are the use cases for no context/surface association?
>
Here is one example:
vaCreateSurface
vaPutImage
vaPutSurface
vaSyncSurface

>> Now comparing "master" with "libva31" branch, master doesn't integrate
>> Gwenole's patch 202_split_libva.patch which splits libva.so into
>> libva-core.so and libva-x11.so. Personally I like one single libva.so
>> because currently every VA API relies on a "DISPLAY" which depends on
>> libva-x11, that means libva-core.so can't be used individually.  Is
>> there a strong reason we must splite them, code complexity? or is
>> there any idea to support decode/encode even without a DISPLAY/X
>> environment (libva-null, libva-fb?), and only need a X when display
>> something?
>
> In decreasing order of likelihood:
>
> (a) I have drivers that support rendering to an OpenGL texture without
> going through TFP, so we can't use vaPutSurface(Pixmap,...). That's why I
> am trying to design GLX extensions that could cover both cases. This is
> done for two drivers now, probably requires a third iteration of the API
> extensions.
>
> (b) I have not checked yet whether this is possible or not, but I would
> also like to have a VA driver to accelerators implementing OpenMAX.
> Planned next.
>
> (c) IIRC, there are also hardware accelerators that can work in an OpenGL
> ES environment, without X11. No visibility, I am finally not working on
> that platform.
>
Ok. Just checked in that patch.