[Libva] [PATCH 2/4] Set the pipeline to use the new VP8 encoding shaders on BSW

Xiang, Haihao haihao.xiang at intel.com
Fri Jan 13 00:02:20 UTC 2017 

Thanks for the detailed info, I will look into the issue. BTW can you try other vaapi based tools, such as yamitranscode?

Thanks
Haihao

>-----Original Message-----
>From: Mark Thompson [mailto:sw at jkqxz.net]
>Sent: Friday, January 13, 2017 6:11 AM
>To: libva at lists.freedesktop.org; Xiang, Haihao <haihao.xiang at intel.com>
>Subject: Re: [Libva] [PATCH 2/4] Set the pipeline to use the new VP8 encoding
>shaders on BSW
>
>On 12/01/17 07:30, Xiang, Haihao wrote:
>>
>> Hi Mark,
>>
>> Can you reproduce the issue you mentioned below? If yes, I would like
>> to fix it in the new version of the patch series.
>
>Hi,
>
>Yes, I can reproduce it consistently on both Skylake and Kaby Lake.  Some
>detailed instructions follow...
>
>
>Get standard test input:
><http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_10
>80p_60fps_normal.mp4>.  (The input file does matter somewhat: I tried some
>others and found it harder to reproduce.  Maybe the highly variable
>complexity here helps to show the problem.)
>
>Get current libav from git: <git://git.libav.org/libav.git>.
>
>Apply patches adding framerate configuration and VP8 encode support to
>libav: <http://ixia.jkqxz.net/~mrt/libva/vp8/0001-vaapi_encode-Pass-
>framerate-parameters-to-driver.patch>,
><http://ixia.jkqxz.net/~mrt/libva/vp8/0002-vaapi_encode-Add-VP8-
>support.patch>.
>
>Configure libav with --enable-vaapi and build.
>
>
>Now run a transcode from the H.264 of the input file to VP8.  What happens
>varies with the bitrate selected (this is now on Skylake GT2, 6300):
>
>
>./avconv -y -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -
>hwaccel_output_format vaapi -i bbb_sunflower_1080p_60fps_normal.mp4 -
>an -c:v vp8_vaapi -r 60 -b:v 5M out.webm
>
>(CBR at 5Mbps)  Everything works and the output looks good: yay!  (This is an
>immense improvement over the current driver - if you run the same
>command there, the output is working but terrible quality.)
>
>
>./avconv -y -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -
>hwaccel_output_format vaapi -i bbb_sunflower_1080p_60fps_normal.mp4 -
>an -c:v vp8_vaapi -r 60 -b:v 5M out.webm
>
>(CBR at 2Mbps)  Mostly works, but the output is broken at times and the
>bitrate target is often missed by a long way.
>
>
>./avconv -y -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -
>hwaccel_output_format vaapi -i bbb_sunflower_1080p_60fps_normal.mp4 -
>an -c:v vp8_vaapi -r 60 -b:v 1M out.webm
>
>(CBR at 1Mbps)  Consistently hangs at around frame 570.
>
>
>[1321697.079583] drm/i915: Resetting chip after gpu hang [1321697.081571]
>[drm] GuC firmware load skipped [1321699.063831] [drm] RC6 on
>
>/sys/class/drm/card0/error for one case:
><http://ixia.jkqxz.net/~mrt/libva/vp8/sys_class_drm_card0_error>.
>
>Backtrace of userspace at the hang point:
>
>#0  0x00007ffff6351cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
>#1  0x00007ffff5821708 in drmIoctl () from /usr/lib/x86_64-linux-
>gnu/libdrm.so.2
>#2  0x00007ffff48e3e00 in ?? () from /usr/lib/x86_64-linux-
>gnu/libdrm_intel.so.1
>#3  0x00007ffff48e4036 in ?? () from /usr/lib/x86_64-linux-
>gnu/libdrm_intel.so.1
>#4  0x00007ffff4bded57 in intel_batchbuffer_flush (batch=0x555556c03240)
>at ../../src/intel_batchbuffer.c:147
>#5  0x00007ffff4b9c821 in i965_run_kernel_media_object
>(ctx=0x555556ad15b0, encoder_context=0x555556bfff10,
>gpe_context=0x555556b6da38, media_function=11, param=0x7fffffffd5f0)
>at ../../src/i965_encoder_vp8.c:2174
>#6  0x00007ffff4baa044 in i965_encoder_vp8_pak_tpu (ctx=0x555556ad15b0,
>encode_state=0x555556ae5cd0, encoder_context=0x555556bfff10)
>at ../../src/i965_encoder_vp8.c:6503
>#7  0x00007ffff4baa5a7 in i965_encoder_vp8_pak_pipeline
>(ctx=0x555556ad15b0, profile=VAProfileVP8Version0_3,
>encode_state=0x555556ae5cd0, encoder_context=0x555556bfff10)
>at ../../src/i965_encoder_vp8.c:6620
>#8  0x00007ffff4b988b3 in intel_encoder_end_picture (ctx=0x555556ad15b0,
>profile=VAProfileVP8Version0_3, codec_state=0x555556ae5cd0,
>hw_context=0x555556bfff10) at ../../src/i965_encoder.c:1313
>#9  0x00007ffff4b8aa23 in i965_EndPicture (ctx=0x555556ad15b0,
>context=33554433) at ../../src/i965_drv_video.c:3588
>#10 0x00007ffff76744ca in vaEndPicture (dpy=0x555556ad1540,
>context=33554433) at ../../git/va/va.c:1285
>#11 0x0000555555df76d8 in vaapi_encode_issue (avctx=0x555556b5f100,
>pic=0x555556c64d20) at
>/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:387
>#12 0x0000555555df7f29 in vaapi_encode_step (avctx=0x555556b5f100,
>target=0x555556c64d20) at
>/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:608
>#13 0x0000555555df8be9 in ff_vaapi_encode2 (avctx=0x555556b5f100,
>pkt=0x555556b19380, input_image=0x555556b188c0,
>got_packet=0x7fffffffdcfc) at
>/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:895
>#14 0x00005555557a409b in avcodec_encode_video2 (avctx=0x555556b5f100,
>avpkt=0x555556b19380, frame=0x555556b188c0,
>got_packet_ptr=0x7fffffffdcfc) at
>/home/mrt/video/libav/vp8/libavcodec/encode.c:231
>#15 0x00005555557a4280 in do_encode (avctx=0x555556b5f100,
>frame=0x555556b188c0, got_packet=0x7fffffffdcfc) at
>/home/mrt/video/libav/vp8/libavcodec/encode.c:278
>#16 0x00005555557a444a in avcodec_send_frame (avctx=0x555556b5f100,
>frame=0x555556b188c0) at
>/home/mrt/video/libav/vp8/libavcodec/encode.c:327
>#17 0x00005555555c3c5c in do_video_out (of=0x555556c61ba0,
>ost=0x555556c61680, in_picture=0x555556b188c0, frame_size=0x7fffffffe1cc)
>at /home/mrt/video/libav/vp8/avconv.c:579
>#18 0x00005555555c43ce in poll_filter (ost=0x555556c61680) at
>/home/mrt/video/libav/vp8/avconv.c:718
>#19 0x00005555555c4753 in poll_filters () at
>/home/mrt/video/libav/vp8/avconv.c:792
>#20 0x00005555555cab23 in transcode () at
>/home/mrt/video/libav/vp8/avconv.c:2730
>#21 0x00005555555cb063 in main (argc=20, argv=0x7fffffffe438) at
>/home/mrt/video/libav/vp8/avconv.c:2898
>
>
>avconv there also supports CQP mode as well as CBR (pass "-qindex N" for N
>between 0 and 127 instead of the "-b:v M" above): this is always fine for me.
>
>Can you reproduce a hang with that?  Is there any other information I can
>provide to help?
>
>Thanks,
>
>- Mark
>
>
>>>> On Tue, Jan 10, 2017 at 4:21 PM, Mark Thompson <sw at jkqxz.net> wrote:
>>>>> On 10/01/17 22:02, Sean V Kelley wrote:
>>>>>> From: "Xiang, Haihao" <haihao.xiang at intel.com>
>>>>>>
>>>>>> Currently only one temporal layer is supported
>>>>>>
>>>>>> Signed-off-by: Xiang, Haihao <haihao.xiang at intel.com>
>>>>>> Reviewed-by: Sean V Kelley <seanvk at posteo.de>
>>>>>> ---
>>>>>>   src/Makefile.am        |    3 +
>>>>>>   src/gen8_encoder_vp8.c |  140 +
>>>>>>   src/gen8_mfc.c         |    8 +-
>>>>>>   src/gen8_vme.c         |    5 +
>>>>>>   src/i965_defines.h     |   10 +
>>>>>>   src/i965_encoder.c     |    2 +
>>>>>>   src/i965_encoder_vp8.c | 6697
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>   src/i965_encoder_vp8.h | 2643 +++++++++++++++++++
>>>>>>   8 files changed, 9507 insertions(+), 1 deletion(-)
>>>>>
>>>>> I had a go with this on Kaby Lake.  In general, big win - looks
>>>>> like it can be under half the bitrate at comparable quality (though
>>>>> it was pretty terrible before...).
>>>>>
>>>>> However, the rate control seems to do odd things at low bitrate
>>>>> relative to the frame size?  I can get GPU hangs and wildly varying
>>>>> output bitrate with it, though it seems ok at high bitrate.
>>>> That's a concern.  Please report the If it really is a GPU hang, I
>>>> need the error report for the DRM card0 log.
>>>>
>>>> cat /sys/class/drm/card0/error
>>>>
>>>> Please rerun and capture the DRM (i915) card0 error log.
>>>>
>>>>>
>>>>> I had a look around the rate control and found two minor issues in
>>>>> the RC configuration, though I don't think either of them are
>>>>> relevant to my problem (see below).  I can try to make a reproducer
>>>>> if this is not already known?
>>>>>
>>>> Please do attempt to reproduce.  That's why I've put the patches out
>>>> here to test.
>>>
>>> Thanks for testing the patch, could you detail the steps to reproduce
>>> this issue?
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Sean
>>>>
>>>>>  Thanks,
>>>>>
>>>>> - Mark
>>>>>

More information about the Libva mailing list