On 11/06/2015 05:00 AM, Gilles Chanteperdrix wrote:
On Thu, Nov 05, 2015 at 02:13:29PM +0000, Emil Velikov wrote:
On 4 November 2015 at 00:54, Gilles Chanteperdrix
<[email protected]> wrote:
On Tue, Nov 03, 2015 at 04:56:14PM +0000, Lionel Landwerlin wrote:
Hi,
Following your comments on the previous patch, here is an serie to add
support for coefficients passed down to the EUs for the vpp yuv to rgb
conversion path.
Hi,
sorry for intruding on the mailing list, but this is a topic on
which I worked recently. First question is: I implemented yuv to rgb
conversion using GLSL shaders (only for yuv420p, but this could be
easily implemented for other pixel formats), and the code is
relatively simple:
https://git.click-hack.org/vplayer.git/tree/lib/yuv420p_frag.glsl
What is the gain of using libva instead?
I'm no expert in the libva code so take this with a grain of salt.
For doing things the GLSL way - you have an extra GL context
creation/management not to mention the overhead of
parsing/compiling/linking etc the GLSL shader. While the result (from
a hardware's perspective/instructions emitted) may be almost
identical, doing things within i965 libva driver should be less
CPU/memory intensive.
Well, compiling/linking the GLSL shader happens only once at
initialization. The advantage I see with a GLSL shader is that it
looks more portable, OpenGL with GLSL is almost universally
available, whereas libva runs on Linux only.
I agree that the GLSL shader is more portable.
But as far as we know, the sampler defined in 3D is quite
simple.(LINEAR, NEAREST). When doing the scaling conversion, the quality
looks quite poor.
The VPP in libva driver can make good use of hardware feature and have
better quality when doing the scaling conversion.
Thanks
Yakui
_______________________________________________
Libva mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libva
