[Libva] How to detect the type of memory returned...

[Gwenole Beauchesne]

2014-06-17 14:55 GMT+02:00 Jean-Yves Avenard <jyavenard at gmail.com>:
> On 17 June 2014 22:44, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
>
>> On any platform that natively supports output to an X pixmap, this
>> will be an obvious gain. In the distant past, I measured on a very old
>> Poulsbo, up to +30% increase, i.e. smoother rendering. Reality is I
>> only needed VA/GLX for XvBA. Since OSS drivers matured a lot, I don't
>> see the point to stick to proprietary drivers. Anyway, someone from
>> the VLC team used to maintain the older xvba-driver nowadays though.
>>
>> If we focus on the Intel hardware, in GLX, using vaPutSurface() + TFP
>> would not only be the optimum way (for GLX, again), but also the most
>> correct one since the VA intel-driver does not implement the VA/GLX
>
> From which libva version is vaPutSurface supported?

vaPutSurface() was supported from the very beginning. :)
vaPutSurface() to a Pixmap was supported in most VA drivers, including
NVIDIA through vdpau-video. Only xvba-video did not support that for
performance reasons.

> (gosh, we are very off-topic from my original question)

Yes, I have to concur. Back to the original question:
- No, there is no existing way to query the underlying memory type ;
- However, it should be safe to assume: (i) USWC memory for both
vaDeriveImage() or vaGetImage() buffer on any platform that supports
vaDeriveImage() [Intel HW], and (ii) normal CPU memory on others
[wrappers like vdpau-driver, xvba-driver -- malloc()'ed buffer].

If SSE4 copy doesn't incur any performance hit on platforms with
NVIDIA or AMD HW, then just go for it by default.
The performance issue you observed on Intel HW for vaGetImage() will
need to be fixed to align with the vaDeriveImage() gains. Is this an
acceptable plan to you?

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199