Re: [Libva] [PATCH 00/31] Encoder Architecture Changes (Primarily AVC)

[Qu, Pengfei]

-Original Message-
From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of Xiang, 
Haihao
Sent: Thursday, January 12, 2017 10:15 AM
To: Zhao, Yakui ; sea...@posteo.de
Cc: libva@lists.freedesktop.org
Subject: Re: [Libva] [PATCH 00/31] Encoder Architecture Changes (Primarily AVC)

On Thu, 2017-01-12 at 09:40 +0800, Zhao Yakui wrote:
> On 01/11/2017 07:37 AM, Sean V Kelley wrote:
> > Encoder architecture restructuring for H.264 (with some impact to 
> > HEVC now) on HSW+
> > * Improvements to the shaders
> > * Improvements to the B frame efficiency
> > * Improvements to the low bit rate mode
> > * Improved features in two stage VME/PAK pipeline
> > 
> 
> After checking the code, it seems that assert is used widely.
> But the assert is only for the debug purpose, which causes that the 
> program will abort. This doesn't make sense. It will be better that 
> the failure status is returned instead of crash program.
> 
> At the same time if the NDEBUG definition is added, the check is 
> disabled. In such case the driver should handle the failure scenario 
> and return the failure status to upper middleware.
> 
> That is to say: The assert had better be avoided and add more check to 
> check the failure status.

We can add some assert() for internal logic check in the driver, it would be 
better not use assert() for input validation.

Thanks
Haihao
[Pengfei] I will keep assert for internal logic and replace assert for input 
validation.

> Thanks.
> 
> > 
> > Pengfei Qu (31):
> >    ENC: move gpe related function into src/i965_gpe_utils.h/c
> >    ENC: add common structure for AVC/HEVC encoder
> >    ENC:add context init function for AVC/HEVC encoder
> >    ENC: add const data/table for AVC encoder
> >    ENC: add AVC kernel binary on SKL
> >    ENC: add AVC common structure and functions
> >    ENC: add kernel related structure and define for AVC
> >    ENC: add misc parameter check for AVC encoder
> >    ENC: add resource and surface allocation and free function for 
> > AVC
> >  encoder
> >    ENC: add init table for frame/mb brc update
> >    ENC: add resource/surface allocation/free function for AVC 
> > encoder
> >    ENC: add kernel media object related functions for AVC encoder
> >    ENC: add scaling kernel for AVC encoder
> >    ENC: add const data/table init function for AVC RC logic
> >    ENC: add BRC init/reset kernel for AVC RC logic
> >    ENC: add BRC frame update kernel for AVC RC logic
> >    ENC: add BRC MB level update kernel for AVC RC logic
> >    ENC: add REF frame QA caculation and MB level const data init for 
> > AVC
> >  MBenc stage
> >    ENC: MBENC kernel for AVC encoder
> >    ENC: ME kernel for AVC encoder
> >    ENC: WP/SFD kernel for AVC encoder
> >    ENC: kernel init/destroy function for AVC encoder
> >    ENC: kernel related parameter check function for AVC encoder
> >    ENC: VME pipeline init/prepare/run function for AVC encoder
> >    ENC: add MFX command for AVC encoder
> >    ENC: add MFX command for AVC encoder
> >    ENC: add MFX Picture/slice level command init for AVC encoder
> >    ENC: add MFX pipeline init/prepare/run for AVC encoder
> >    ENC: add VME/MFX context init for AVC encoder
> >    ENC: add Misc parameter check for AVC encoder
> >    ENC:support more quality level and switch to new AVC encoder 
> > solution
> >  on SKL
> > 
> >   src/Makefile.am|11 +
> >   src/gen9_avc_const_def.c   |  1090 
> >   src/gen9_avc_const_def.h   |   115 +
> >   src/gen9_avc_encoder.c |  7613 
> >   src/gen9_avc_encoder.h |  2345 
> >   src/gen9_avc_encoder_kernels.c | 12081
> > +++
> >   src/gen9_avc_encoder_kernels.h |36 +
> >   src/gen9_vp9_encoder.c |   154 +-
> >   src/gen9_vp9_encoder.h |10 -
> >   src/i965_avc_encoder_common.c  |   319 ++
> >   src/i965_avc_encoder_common.h  |   305 +
> >   src/i965_drv_video.c   | 8 +-
> >   src/i965_drv_video.h   | 2 +
> >   src/i965_encoder.c |39 +-
> >   src/i965_encoder_api.h |59 +
> >   src/i965_encoder_common.c  |   124 +
> >   src/i965_encoder_common.h  |   533 ++
> >   src/i965_gpe_utils.c   |   265 +-
> >   src/i965_gpe_utils.h   |87 +
> >   19 files changed, 25026 insertions(+), 170 deletions(-)
> >   create mode 100755 src/gen9_avc_const_def.c
> >   create mode 100755 src/gen9_avc_const_def.h
> >   create mode 100755 src/gen9_avc_encoder.c
> >   create mode 100755 src/gen9_avc_encoder.h
> >   create mode 100755 src/gen9_avc_encoder_kernels.c
> >   create mode 100755 src/gen9_avc_encoder_kernels.h
> >   create mode 100755 src/i965_avc_encoder_common.c
> >   create mode 100755 src/i965_avc_encoder_common.h
> >   create mode 100755 src/i965_encoder_api.h
> >   create mode 100755 src/i965_encoder_common.c
> >   create mode 100755 src/i965_encoder_common.h
> > 
> 
> 

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

[Xiang, Haihao]

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:s...@jkqxz.net]
>Sent: Friday, January 13, 2017 6:11 AM
>To: libva@lists.freedesktop.org; Xiang, Haihao 
>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:
>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: .
>
>Apply patches adding framerate configuration and VP8 encode support to
>libav: framerate-parameters-to-driver.patch>,
>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:
>.
>
>Backtrace of userspace at the hang point:
>
>#0  0x76351cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
>#1  0x75821708 in drmIoctl () from /usr/lib/x86_64-linux-
>gnu/libdrm.so.2
>#2  0x748e3e00 in ?? () from /usr/lib/x86_64-linux-
>gnu/libdrm_intel.so.1
>#3  0x748e4036 in ?? () from /usr/lib/x86_64-linux-
>gnu/libdrm_intel.so.1
>#4  0x74bded57 in intel_batchbuffer_flush (batch=0x56c03240)
>at ../../src/intel_batchbuffer.c:147
>#5  0x74b9c821 in i965_run_kernel_media_object
>(ctx=0x56ad15b0, encoder_context=0x56bfff10,
>gpe_context=0x56b6da38, media_function=11, param=0x7fffd5f0)
>at ../../src/i965_encoder_vp8.c:2174
>#6  0x74baa044 in i965_encoder_vp8_pak_tpu (ctx=0x56ad15b0,
>encode_state=0x56ae5cd0, encoder_context=0x56bfff10)
>at ../../src/i965_encoder_vp8.c:6503
>#7  0x74baa5a7 in i965_encoder_vp8_pak_pipeline
>(ctx=0x56ad15b0, profile=VAProfileVP8Version0_3,
>encode_state=0x56ae5cd0, encoder_context=0x56bfff10)
>at ../../src/i965_encoder_vp8.c:6620
>#8  0x74b988b3 in intel_encoder_end_picture (ctx=0x56ad15b0,
>profile=VAProfileVP8Version0_3, codec_state=0x56ae5cd0,
>hw_context=0x56bfff10) at ../../src/i965_encoder.c:1313
>#9  0x74b8aa23 in i965_EndPicture (ctx=0x56ad15b0,
>context=33554433) at ../../src/i965_drv_video.c:3588
>#10 0x776744ca in vaEndPicture (dpy=0x56ad1540,
>context=33554433) at ../../git/va/va.c:1285
>#11 0x55df76d8 in vaapi_encode_issue (avctx=0x56b5f100,
>pic=0x56c64d20) at
>/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:387
>#12 0x55df7f29 in vaapi_encode_step (avctx=0x56b5f100,
>target=0x56c64d20) at
>/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:608
>#13 0x55df8be9 in ff_vaapi_encode2 (avctx=0x56b5f100,
>pkt=0x56b19380, input_image=0x56b188c0,
>got_packet=0x7fffdcfc) at
>/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:895
>#14 0x557a409b in avcodec_encode_video2 (avctx=0x56b5f100,
>avpkt=0x56b19380, frame=0x56b188c0,
>got_packet_ptr=0x7fffdcfc) at
>/home/mrt/video/libav/vp8/libavcodec/encode.c:231
>#15 0x557a4280 in do_encode (avctx=0x56b5f100,
>frame=

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

[Mark Thompson]

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: 
.
  (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: .

Apply patches adding framerate configuration and VP8 encode support to libav: 
,
 .

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: 
.

Backtrace of userspace at the hang point:

#0  0x76351cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x75821708 in drmIoctl () from /usr/lib/x86_64-linux-gnu/libdrm.so.2
#2  0x748e3e00 in ?? () from /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1
#3  0x748e4036 in ?? () from /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1
#4  0x74bded57 in intel_batchbuffer_flush (batch=0x56c03240) at 
../../src/intel_batchbuffer.c:147
#5  0x74b9c821 in i965_run_kernel_media_object (ctx=0x56ad15b0, 
encoder_context=0x56bfff10, gpe_context=0x56b6da38, media_function=11, 
param=0x7fffd5f0) at ../../src/i965_encoder_vp8.c:2174
#6  0x74baa044 in i965_encoder_vp8_pak_tpu (ctx=0x56ad15b0, 
encode_state=0x56ae5cd0, encoder_context=0x56bfff10) at 
../../src/i965_encoder_vp8.c:6503
#7  0x74baa5a7 in i965_encoder_vp8_pak_pipeline (ctx=0x56ad15b0, 
profile=VAProfileVP8Version0_3, encode_state=0x56ae5cd0, 
encoder_context=0x56bfff10) at ../../src/i965_encoder_vp8.c:6620
#8  0x74b988b3 in intel_encoder_end_picture (ctx=0x56ad15b0, 
profile=VAProfileVP8Version0_3, codec_state=0x56ae5cd0, 
hw_context=0x56bfff10) at ../../src/i965_encoder.c:1313
#9  0x74b8aa23 in i965_EndPicture (ctx=0x56ad15b0, 
context=33554433) at ../../src/i965_drv_video.c:3588
#10 0x776744ca in vaEndPicture (dpy=0x56ad1540, context=33554433) 
at ../../git/va/va.c:1285
#11 0x55df76d8 in vaapi_encode_issue (avctx=0x56b5f100, 
pic=0x56c64d20) at /home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:387
#12 0x55df7f29 in vaapi_encode_step (avctx=0x56b5f100, 
target=0x56c64d20) at 
/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:608
#13 0x55df8be9 in ff_vaapi_encode2 (avctx=0x56b5f100, 
pkt=0x56b19380, input_image=0x56b188c0, got_packet=0x7fffdcfc) at 
/home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:895
#14 0x557a409b in avcodec_encode_video2 (avctx=0x56b5f100, 
avpkt=0x56b19380, frame=0x56b188c0, got_packet_ptr=0x7fffdcfc) at 
/home/mrt/video/libav/vp8/libavcodec/encode.c:231
#15 0x557a4280 in do_encode (avctx=0x56b5f100, 
frame=0x56b188c0, got_packet=0x7fffdcfc) at 
/home/mrt/video/libav/vp8/libavcodec/encode.c:278
#16 0x557a444a in avcodec_send_frame (avctx=0x56b5f100, 
frame=0x56b188c0) at /home/mrt/video/libav/vp8/libavcodec/encode.c:327
#17 0x555c3c5c in do_video_out (of=0x56c61ba0, ost=0x56c61680, 
in_picture=0x56b188c0, frame_size=0x7fffe1cc) at 
/home/mrt/video/libav/vp8/avconv.c:579
#18 0x555c43ce in poll_filter (ost=0x56c61680)