| Summary: | [BDW] AVC_cqp_encoding had lower pass rate comparing with IVB | ||
|---|---|---|---|
| Product: | libva | Reporter: | zhenxiang.li <zhenxiang.li> |
| Component: | intel | Assignee: | Pengfei <pengfei.qu> |
| Status: | RESOLVED FIXED | QA Contact: | Sean V Kelley <seanvk> |
| Severity: | major | ||
| Priority: | medium | CC: | haihao.xiang, shengyanx.zhao, shuang.he, zhenxiang.li, zhixinx.liu |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Data compare to vpg/win7 driver | ||
Besides, gst10_AVC_cqp_encoding had lower pass rate than HSW:
BDW HSW IVB
mode=0 68/84 84/84 84/84
mode=1 80/84 81/84 84/84
mode=2 69/84 74/84 84/84
Cases failed when qp value is bigger than 40 or 44 as well as using avcenc encoding, and mode=2 has the most impact.
promoting to high priority as it severely impacts the pass rate. Will you please spilt this into two bugs? (For haswell and broadwell).
BTW: Do we use the windows driver data on the Haswell for the reference during the comparison? o we use the windows driver data on the Broadwell for the reference during the comparison?
Thanks.
Yakui
Hi. The reference data was produced with Windows driver on HSW. It will be better that the compared data is produced by using windows driver on the BDW machine.
Thanks.
Yakui
Blocked by getting the windows encoding data or vpg driver encoding data on BDW, but still in progress. Created attachment 100495 [details]
Data compare to vpg/win7 driver
Identified it was driver issue, VPG/Win7 driver didn't have this issue
Changed to High priority.
By using BDW E0 stepping, the issue still happened:
passed/total cases
mode=0 67/84
mode=0 80/84
mode=0 69/84
Is there a reason why this code has not been moved to Master yet? Anything that is a High priority bug must be on Master and not Staging. Staging is by definition Work-In-Progress. Since this is not on Master, then this bug importance should be lowered. Thanks, Sean In fact, currently on Master branch also had this issue. For Q2 release, Val team plan to use 3 cycles test to cover it: 1), The first test cycle used the staging branch start on ww23.2 which would help Dev team to build the Q2 release packages and also let validation team know whether there are any risk for Q2 release. 2), The 2th and 3th cycles test will use the master branch for ; The 2th cycle will be started on ww24.1; The 3th cycle ETA ww25.3. Thanks Focus use new patch to check this problem, the test result is
BDW HSW IVB
mode=0 84/84 84/84 84/84
mode=1 83/84 81/84 84/84
mode=2 72/84 74/84 84/84
current data is very close to HSW, so change importance from high to medium.
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Environment: ------------- Libva: (staging)8be6d274d931d8041934efa63caaee75a5984755 Libva_intel_driver: (staging)bd630edd844b88ea543a027654db296ff7da16cd Command line: ------------- 1. /opt/X11R7/bin/avcenc 720 576 iceage_720x576_491.yuv iceage_720x576_491.yuv.enc.h264 qp=44 mode=0 2. /root/media_tools/encoder/ldecod.exe -i iceage_720x576_491.yuv.enc.h264 -o iceage_720x576_491.yuv.jm.dump -r iceage_720x576_491.yuv 3. get the psnr value: /root/media_tools/encoder/metrics_calc_lite.ia32e -i1 iceage_720x576_491.yuv -i2 iceage_720x576_491.yuv.jm.dump -w 720 -h 576 -nopfm psnr y Bug Info: ------------- -It happened when the qp value is equal or gt 40, mode=0, 1, 2; -The following data is produced from the above command(mode=0); h264_size bitrate y-psnr -ivb 3299058 1574 28.87887 -hsw 3561618 1700 28.88024 -bdw 5314288 2536 27.52403