On 17 June 2014 22:44, Gwenole Beauchesne <[email protected]> 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 Hi I've implemented vaPutSurface + TFP in place of vaCopySurfaceGLX, there's indeed a reduction in CPU usage; from 14-15% to 9-10% I've noticed a drop in output quality compare to vaCopySurfaceGLX for SD media. Is this expected? I haven't looked much into it as I only just got it working. But somehow it appears more "blurry" I'm also puzzled with your earlier comment: "At best, directly use vaPutSurface() + TFP (EXT_texture_from_pixmap), but an RGBA backing store is not efficient enough, unless you downscale for thumbnailing purposes for instance." So is this method to be used or use something else? It breaks our PiP however, the PiP window doesn't show, also need to look into that, working with X has always been a pain to properly do compositing. _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
