[Libva] performances question with libva on i5 sandy bridge

Xiang, Haihao haihao.xiang at intel.com
Tue Jan 20 22:32:34 PST 2015


On Mon, 2015-01-19 at 07:37 +0100, Gilles Chanteperdrix wrote:
> On Mon, Jan 19, 2015 at 10:34:37AM +0800, Xiang, Haihao wrote:
> > On Mon, 2015-01-19 at 00:20 +0100, Gilles Chanteperdrix wrote:
> > > Hi,
> > > 
> > > I am testing libva with ffmpeg on Linux to decode h264 video. 
> > > Linux version is 3.4.29 
> > > FFmpeg version is 2.5.3 
> > > Mesa version is 10.4.0 
> > > libdrm version is 2.4.58 
> > > libva version is 1.5.0
> > > 
> > > From what I could gather from the documentation and examples, using
> > > vaDeriveImage should be preferred if it is available. However, I
> > > have compared, with top, the CPU consumed, and I observe that the
> > > following code:
> > > 
> > > #ifdef USE_VADERIVEIMAGE
> > > 	vrc = vaDeriveImage(ctx->display, buf->surface_id, &va_image);
> > > 	CHECK_VASTATUS(vrc, "vaDeriveImage");
> > > #else
> > > 	vrc = vaGetImage(ctx->display, buf->surface_id,
> > > 			0, 0, cctx->coded_width, cctx->coded_height,
> > > 			va_image.image_id);
> > > 	CHECK_VASTATUS(vrc, "vaGetImage");
> > > #endif
> > > 
> > > 	vrc = vaMapBuffer(ctx->display, va_image.buf, &data);
> > > 	CHECK_VASTATUS(vrc, "vaMapBuffer");
> > > 
> > > 	memcpy(f->img[0], data + va_image.offsets[0],
> > > 		va_image.pitches[0] * cctx->coded_height);
> > > 	memcpy(f->img[1], data + va_image.offsets[1],
> > > 		va_image.pitches[1] * cctx->coded_height / 2);
> > > 
> > > 	vrc = vaUnmapBuffer(ctx->display, va_image.buf);
> > > 	CHECK_VASTATUS(vrc, "vaUnmapBuffer");
> > > 
> > > #ifdef USE_VADERIVEIMAGE
> > > 	vrc = vaDestroyImage(ctx->display, va_image.image_id);
> > > 	CHECK_VASTATUS(vrc, "vaDestroyImage");
> > > #endif
> > > 
> > > Results in a higher cpu consumption if compiled with
> > > USE_VADERIVEIMAGE. Is this normal, or is there something I am doing
> > > wrong? I can provide the complete code if needed.
> > 
> > It depends on the the underlying memory format. Most surfaces used in
> > the driver are tiled, so the derived images are tiled too, the memory
> > returned is uncached and reading data from it would be slow. If the
> > image isn't tiled, the returned memory is cached. 
> 
> Ok. Thanks for the explanation.
> 
> Is the result of vaMapBuffer always uncached, or only for
> a VA image obtained with vaDeriveImage ? 

You could try the following patch if you want to the result of
vaMapBuffer() on an Image is uncached.
http://lists.freedesktop.org/archives/libva/attachments/20140617/d9cc4b3c/attachment.bin

> If I plan to run the same
> program with multiple drivers, is there a way to know whether
> vaDeriveImage is optimal ?


> 
> Regards.
> 




More information about the Libva mailing list