[Libva] [Libva-intel-driver][PATCH] Enable AVC VDEnc on BXT

[Xiang, Haihao]

I verified AVC VDEnc with the HuC loading patch from
https://patchwork.freedesktop.org/api/1.0/series/16584/revisions/1/mbox/

Signed-off-by: Xiang, Haihao 
---
 src/i965_device_info.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/i965_device_info.c b/src/i965_device_info.c
index 13ac49c..73602ae 100644
--- a/src/i965_device_info.c
+++ b/src/i965_device_info.c
@@ -419,6 +419,9 @@ static struct hw_codec_info bxt_hw_codec_info = {
 .has_hevc10_decoding = 1,
 .has_vp9_decoding = 1,
 .has_vpp_p010 = 1,
+.has_lp_h264_encoding = 1,
+
+.lp_h264_brc_mode = VA_RC_CQP,
 
 .num_filters = 5,
 .filters = {
-- 
1.9.1

___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] [PATCH 1/4] i965_encoder: consistently represent framerate as a fraction

[Xiang, Haihao]

> On 15/12/16 08:54, Xiang, Haihao wrote:
> > 
> > Hi Mark,
> > 
> > Thanks for your patch, is there any benefit to use a fraction?
> > using
> > 100 as framerate_den works well in the driver.
> 
> Everything the driver interacts with directly, on both sides, uses a
> fraction:
> 
> * In VAAPI, VAEncMiscParameterFrameRate contains a 16 / 16 fraction.
> 
> * Newer hardware uses a fraction directly where it requires a
> framerate (gen9_vp9_encoder.c:1204, gen9_vdenc.c:1648).
> 
> * H.264 and H.265 streams contain num_units_in_tick / time_scale.
> 
> * gstreamer (GstVideoInfo.fps_[nd]), libyami
> (VideoFrameRate.frameRate{Num,Denom}) and libavcodec
> (AVCodecContext.{time_base,framerate} are fraction structures) all
> represent framerate as a fraction.
> 
> The driver should use a fraction as well to preserve the exact value
> and be consistent with everything it interacts with.

Agree, the driver should use a fraction. What I mean is that
(frames_per_100s / 100) works well in practice, so I prefer 1 field
instead of 2 fields in the corresponding structure.

Thanks
Haihao

> 
> Do you have any other concerns about the patch?  If there are
> additional references outside the core driver code which I have
> missed somehow then I would be happy to update them as well.
> 
> Thanks,
> 
> - Mark
> 
> ___
> Libva mailing list
> Libva@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libva
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?

[Peter Frühberger]

Something I have forgotten,

On Thu, Dec 15, 2016 at 8:14 PM, Peter Frühberger  wrote:

> Hi Veeranna,
>
> On Thu, Dec 15, 2016 at 6:03 PM, ViruS Tadala <
> tadala.veerannab...@gmail.com> wrote:
>
>> Hi Peter,
>>
>> Thanks for your quick response.
>>
>> Mentioned figures are GPU load values. I have ran the intel_gpu_top
>> command to get the same.
>>
>> I didn't check any clock details. Used below pipeline and ran multiple
>> instances.
>>
>> gst-launch-1.0 videotestsrc is-live=true pattern=22 horizontal-speed=20 !
>> 'video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080,
>> framerate=(fraction)10/1' ! vaapiencode_h264 min-qp=20 ! queue !
>> vaapidecode ! queue ! appsink
>>
>> Please let me know if you need more information.
>>
>> Best Regards,
>> Veeranna.
>>
>>
>>
>> On Thu, Dec 15, 2016 at 11:47 AM, Peter Frühberger 
>> wrote:
>>
>>> Hi Veeranna,
>>>
>>> i cannot even interpret your figures. Is that the CPU load? If yes - did
>>> you check the clocks?
>>> Which benchmark did you use? Where did the data come from, where was it
>>> encoded to? Was it stored? Which format?
>>>
>>> In short: Without more details you most likely get the following answer:
>>>
>>> Depends!
>>>
>>> Best regards
>>> Peter
>>>
>>> On Thu, Dec 15, 2016 at 4:19 PM, ViruS Tadala <
>>> tadala.veerannab...@gmail.com> wrote:
>>>
 Hi,

 I have done some benchmarking on both platforms & observed that
 braswell did lesser number of channels(decode + re-encode using vaapi) than
 baytrail.

 60-65% for 6channels on braswell.

 60-66 % for 10channels on baytrail.

 Please let me know whether we can expect better GPU performance on
 braswell than baytrail or not?

 Best Regards,

 Veeranna.

 ___
 Libva mailing list
 Libva@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/libva


>>>
>>
>>
>> --
>> Best Regards,
>> ViruS
>>
>
> Does this kernel patch help:
>
>
> From 32c513eeafa681f798b04488524994fe47355cad Mon Sep 17 00:00:00 2001
> From: fritsch 
> Date: Sat, 13 Aug 2016 22:56:37 +0200
> Subject: [PATCH] drm/i915: intel-pm enable thresholds
>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 06e5596..38e613c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4982,8 +4982,7 @@ static void valleyview_set_rps(struct drm_i915_private 
> *dev_priv, u8 val)
>
>   if (val != dev_priv->rps.cur_freq) {
>   vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
> - if (!IS_CHERRYVIEW(dev_priv))
> - gen6_set_rps_thresholds(dev_priv, val);
> + gen6_set_rps_thresholds(dev_priv, val);
>   }
>
>   dev_priv->rps.cur_freq = val;
> --
> 2.7.4
>
>
>
> Best regards
>
> Peter
>
>
And also check this: /sys/class/drm/card0/gt_min_freq_mhz while
benchmarking, it might simply be that the gpu is not clocking correctly.
You can increase the min clock by doing:  echo 600 >
/sys/class/drm/card0/gt_min_freq_mhz
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?

[Peter Frühberger]

Hi Veeranna,

On Thu, Dec 15, 2016 at 6:03 PM, ViruS Tadala  wrote:

> Hi Peter,
>
> Thanks for your quick response.
>
> Mentioned figures are GPU load values. I have ran the intel_gpu_top
> command to get the same.
>
> I didn't check any clock details. Used below pipeline and ran multiple
> instances.
>
> gst-launch-1.0 videotestsrc is-live=true pattern=22 horizontal-speed=20 !
> 'video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080,
> framerate=(fraction)10/1' ! vaapiencode_h264 min-qp=20 ! queue !
> vaapidecode ! queue ! appsink
>
> Please let me know if you need more information.
>
> Best Regards,
> Veeranna.
>
>
>
> On Thu, Dec 15, 2016 at 11:47 AM, Peter Frühberger 
> wrote:
>
>> Hi Veeranna,
>>
>> i cannot even interpret your figures. Is that the CPU load? If yes - did
>> you check the clocks?
>> Which benchmark did you use? Where did the data come from, where was it
>> encoded to? Was it stored? Which format?
>>
>> In short: Without more details you most likely get the following answer:
>>
>> Depends!
>>
>> Best regards
>> Peter
>>
>> On Thu, Dec 15, 2016 at 4:19 PM, ViruS Tadala <
>> tadala.veerannab...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have done some benchmarking on both platforms & observed that braswell
>>> did lesser number of channels(decode + re-encode using vaapi) than baytrail.
>>>
>>> 60-65% for 6channels on braswell.
>>>
>>> 60-66 % for 10channels on baytrail.
>>>
>>> Please let me know whether we can expect better GPU performance on
>>> braswell than baytrail or not?
>>>
>>> Best Regards,
>>>
>>> Veeranna.
>>>
>>> ___
>>> Libva mailing list
>>> Libva@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/libva
>>>
>>>
>>
>
>
> --
> Best Regards,
> ViruS
>

Does this kernel patch help:


>From 32c513eeafa681f798b04488524994fe47355cad Mon Sep 17 00:00:00 2001
From: fritsch 
Date: Sat, 13 Aug 2016 22:56:37 +0200
Subject: [PATCH] drm/i915: intel-pm enable thresholds

---
 drivers/gpu/drm/i915/intel_pm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 06e5596..38e613c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4982,8 +4982,7 @@ static void valleyview_set_rps(struct
drm_i915_private *dev_priv, u8 val)

if (val != dev_priv->rps.cur_freq) {
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
-   if (!IS_CHERRYVIEW(dev_priv))
-   gen6_set_rps_thresholds(dev_priv, val);
+   gen6_set_rps_thresholds(dev_priv, val);
}

dev_priv->rps.cur_freq = val;
-- 
2.7.4



Best regards

Peter
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake

[Tank, Jayesh KumarX]

Hi Vasavee,
   .ivf format is not the same as .webm

https://wiki.multimedia.cx/index.php?title=IVF 

yamiencode does not output in webm format.

Hope it helps.

Thanks,
Jayesh Kumar

-Original Message-
From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of 
Vijayaraghavan, Vasavee
Sent: Thursday, December 15, 2016 10:02 AM
To: Xiang, Haihao ; Charles, Daniel 

Cc: libva@lists.freedesktop.org
Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake

Hi Haihao,

I think I mislead you by not stating the problem correctly, sorry about that! I 
will rephrase the issue that I am facing:

- OTC graphics stack (Ubuntu 16.10 (kernel 4.8), libdrm 2.4.68, libva 1.7.2 and 
libyami/libyami-utils)
- Command line used for encode:
 ./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 -o 
output.ivf (or output.webm)

I wanted to play the output.ivf (output.webm) file to verify whether it was 
encoded properly. Tried looking at the encoded output using ffplay/ VLC/ 
Dragging and dropping in chrome browser I am unable to view this encoded video 
completely (able to see only first and last frame of the video - chrome browser 
is not able to play the video even for the first and last frames)

On the other hand, decoding this output.ivf (/output.webm) back to yuv doesn’t 
give any issue to me. The decoded yuv plays back fine and looks similar to the 
original input yuv that I have used. 
Also, I did not use ffmpeg for anything but just for using the player (ffplay) 
so I assume the issue is not related to ffmpeg in my case. 

-Thanks
Vasavee 


-Original Message-
From: Xiang, Haihao
Sent: Thursday, December 15, 2016 12:08 AM
To: Charles, Daniel ; Vijayaraghavan, Vasavee 

Cc: libva@lists.freedesktop.org
Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake


Hi Vasavee,

Maybe it is not a yami issue. I encountered another issue for VP8
 video which is encoded by another vaapi based tool. I saw double frames when 
transcoding the video back to YUV using ffmpeg, however vpxdec works well for 
me, so I guess there are some issues in FFmpeg.
Could you try vpxdec with your VP9 video? I think it is not yami issue if 
vpxdec works for you.

Thanks
Haihao


> Hi Daniel,
> 
> Sure, will do that! Thank you for the pointers.
> 
> -Best Regards,
> Vasavee
> 
> -Original Message-
> From: Charles, Daniel [mailto:daniel.char...@intel.com]
> Sent: Monday, December 12, 2016 10:53 AM
> To: Vijayaraghavan, Vasavee 
> Cc: Xiang, Haihao ; libva@lists.freedesktop.o 
> rg
> Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode 
> on KabyLake
> 
> Hi Vasavee,
> 
> Can you file a bug on libyami for your observation?
> 
> https://github.com/01org/libyami/issues
> 
> Thanks.
> 
> --
> Daniel.
> 
> On Mon, Dec 12, 2016 at 10:45 AM, Vijayaraghavan, Vasavee  jayaragha...@intel.com> wrote:
> > Hi Haihao,
> > 
> > I might have missed setting the PKG_CONFIG_PATH while trying to use 
> > './configure --prefix=/usr --exec-prefix=/'.
> > But like Daniel suggested, I did a clean install with default paths 
> > and it works fine for me.
> > 
> > I have installed libyami and libyami utils to test VP9 encode and 
> > decode. I am able to run VP9 encode and decode using the pre-built 
> > binaries located in libyami-utils/tools (yamiencode and yamidecode).
> > I am facing issues in playing back the VP9 encoded video.
> > Say test.ivf is my VP9 encoded output, when I playback the file 
> > using ffplay or VLC player, I am able to see only the first and last 
> > frame of the encoded video (though the video shows to have 500 
> > frames - same as the input yuv; verified the number of frames using 
> > ffprobe). Although, when I decode it back to yuv, the yuv is exactly 
> > the same as original input yuv and plays all the frames fine.
> > 
> > At this point, I haven’t added any quality control factor to encode 
> > the video and hence I have used a simple command line:
> > $cd /home/user/libyami-utils/tools
> > $./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 
> > -o test.ivf
> > 
> > Am I missing something in the commandline which is why I am unable 
> > to play the output?
> > 
> > Note: I tried playing pre-encoded test_vp9.ivf files available 
> > through MediaSDK samples and they played without an issue.
> > 
> > -Thanks
> > Vasavee
> > 
> > -Original Message-
> > From: Xiang, Haihao
> > Sent: Wednesday, December 7, 2016 8:07 PM
> > To: Charles, Daniel ; Vijayaraghavan, 
> > Vasavee 
> > Cc: libva@lists.freedesktop.org
> > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode 
> > on KabyLake
> > 
> > 
> > I think './configure --prefix=/usr --exec-prefix=/' should work too, 
> > otherwise it might have issue. Actually this configuration works 
> > fine for me when I build libva and libva-intel-driver. I set 
> > PKG_CONFIG_PATH variable to /lib/pkgconfig because libva.pc is 
> > installed in /lib/pkgconfig wh

Re: [Libva] g45-h264 branch status

[Sean V Kelley]

On Thu, 2016-12-15 at 20:05 +0200, Bob Bib wrote:
> On 15/12/16 09:44, Xiang, Haihao wrote:
> > It was removed for this git repository. Please check https://lists.
> > free
> > desktop.org/archives/libva/2016-June/004018.html . You may fork
> > g45-
> > h264 branch from git://people.freedesktop.org/~haihao/libva-intel-
> > driver.
> 
> Thanks for the info.
> 
> I've checked it, and the last commit dates back to October 2014. It's
> no 
> longer supported, right?

We do not actively work on it, unfortunately.  But if you have
questions or patches or changes feel free to voice them on this list.

Thanks,

Sean

___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] [PATCH 2/3] H.265 main 10 encoder supports only 10bpp render targets

[Sean V Kelley]

On Thu, 2016-12-15 at 13:04 +, Mark Thompson wrote:
> On 05/12/16 17:54, Mark Thompson wrote:
> > Signed-off-by: Mark Thompson 
> > ---
> > The supported surface formats are already correct (i.e. only P010);
> > this makes the render target format right as well (before this, it
> > declares that it supports only YUV 4:2:0 8-bit).
> > 
> >  src/i965_drv_video.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
> > index d83427c..9e1c92a 100644
> > --- a/src/i965_drv_video.c
> > +++ b/src/i965_drv_video.c
> > @@ -880,6 +880,8 @@
> > i965_get_default_chroma_formats(VADriverContextP ctx, VAProfile
> > profile,
> >  break;
> >  
> >  case VAProfileHEVCMain10:
> > +if (HAS_HEVC10_ENCODING(i965) && entrypoint ==
> > VAEntrypointEncSlice)
> > +chroma_formats = VA_RT_FORMAT_YUV420_10BPP;
> >  if (HAS_HEVC10_DECODING(i965) && entrypoint ==
> > VAEntrypointVLD)
> >  chroma_formats |= i965->codec_info-
> > >hevc_dec_chroma_formats;
> >  break;
> > 
> 
> Ping.  (The other patches in this series have been considered
> separately.)

Yes this is a good catch.  It was overlooked with the addition of 10bit
support.  We may need to make further adjustment when we roll in new
encoder formats too.

lgtm.

applied.

Sean


> Thanks,
> 
> - Mark
> 
> ___
> Libva mailing list
> Libva@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libva

___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] g45-h264 branch status

[Bob Bib]

On 15/12/16 09:44, Xiang, Haihao wrote:

It was removed for this git repository. Please check https://lists.free
desktop.org/archives/libva/2016-June/004018.html . You may fork g45-
h264 branch from git://people.freedesktop.org/~haihao/libva-intel-
driver.


Thanks for the info.

I've checked it, and the last commit dates back to October 2014. It's no 
longer supported, right?


--
Best wishes,
Bob
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake

[Vijayaraghavan, Vasavee]

Hi Haihao,

I think I mislead you by not stating the problem correctly, sorry about that! I 
will rephrase the issue that I am facing:

- OTC graphics stack (Ubuntu 16.10 (kernel 4.8), libdrm 2.4.68, libva 1.7.2 and 
libyami/libyami-utils)
- Command line used for encode:
 ./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 -o 
output.ivf (or output.webm)

I wanted to play the output.ivf (output.webm) file to verify whether it was 
encoded properly. Tried looking at the encoded output using ffplay/ VLC/ 
Dragging and dropping in chrome browser
I am unable to view this encoded video completely (able to see only first and 
last frame of the video - chrome browser is not able to play the video even for 
the first and last frames)

On the other hand, decoding this output.ivf (/output.webm) back to yuv doesn’t 
give any issue to me. The decoded yuv plays back fine and looks similar to the 
original input yuv that I have used. 
Also, I did not use ffmpeg for anything but just for using the player (ffplay) 
so I assume the issue is not related to ffmpeg in my case. 

-Thanks
Vasavee 


-Original Message-
From: Xiang, Haihao 
Sent: Thursday, December 15, 2016 12:08 AM
To: Charles, Daniel ; Vijayaraghavan, Vasavee 

Cc: libva@lists.freedesktop.org
Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake


Hi Vasavee,

Maybe it is not a yami issue. I encountered another issue for VP8
 video which is encoded by another vaapi based tool. I saw double frames when 
transcoding the video back to YUV using ffmpeg, however vpxdec works well for 
me, so I guess there are some issues in FFmpeg.
Could you try vpxdec with your VP9 video? I think it is not yami issue if 
vpxdec works for you.

Thanks
Haihao


> Hi Daniel,
> 
> Sure, will do that! Thank you for the pointers.
> 
> -Best Regards,
> Vasavee
> 
> -Original Message-
> From: Charles, Daniel [mailto:daniel.char...@intel.com]
> Sent: Monday, December 12, 2016 10:53 AM
> To: Vijayaraghavan, Vasavee 
> Cc: Xiang, Haihao ; libva@lists.freedesktop.o 
> rg
> Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode 
> on KabyLake
> 
> Hi Vasavee,
> 
> Can you file a bug on libyami for your observation?
> 
> https://github.com/01org/libyami/issues
> 
> Thanks.
> 
> --
> Daniel.
> 
> On Mon, Dec 12, 2016 at 10:45 AM, Vijayaraghavan, Vasavee  jayaragha...@intel.com> wrote:
> > Hi Haihao,
> > 
> > I might have missed setting the PKG_CONFIG_PATH while trying to use 
> > './configure --prefix=/usr --exec-prefix=/'.
> > But like Daniel suggested, I did a clean install with default paths 
> > and it works fine for me.
> > 
> > I have installed libyami and libyami utils to test VP9 encode and 
> > decode. I am able to run VP9 encode and decode using the pre-built 
> > binaries located in libyami-utils/tools (yamiencode and yamidecode).
> > I am facing issues in playing back the VP9 encoded video.
> > Say test.ivf is my VP9 encoded output, when I playback the file 
> > using ffplay or VLC player, I am able to see only the first and last 
> > frame of the encoded video (though the video shows to have 500 
> > frames - same as the input yuv; verified the number of frames using 
> > ffprobe). Although, when I decode it back to yuv, the yuv is exactly 
> > the same as original input yuv and plays all the frames fine.
> > 
> > At this point, I haven’t added any quality control factor to encode 
> > the video and hence I have used a simple command line:
> > $cd /home/user/libyami-utils/tools
> > $./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 
> > -o test.ivf
> > 
> > Am I missing something in the commandline which is why I am unable 
> > to play the output?
> > 
> > Note: I tried playing pre-encoded test_vp9.ivf files available 
> > through MediaSDK samples and they played without an issue.
> > 
> > -Thanks
> > Vasavee
> > 
> > -Original Message-
> > From: Xiang, Haihao
> > Sent: Wednesday, December 7, 2016 8:07 PM
> > To: Charles, Daniel ; Vijayaraghavan, 
> > Vasavee 
> > Cc: libva@lists.freedesktop.org
> > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode 
> > on KabyLake
> > 
> > 
> > I think './configure --prefix=/usr --exec-prefix=/' should work too, 
> > otherwise it might have issue. Actually this configuration works 
> > fine for me when I build libva and libva-intel-driver. I set 
> > PKG_CONFIG_PATH variable to /lib/pkgconfig because libva.pc is 
> > installed in /lib/pkgconfig which is not in the default pkg-config 
> > search path.
> > 
> > Thanks
> > Haihao
> > 
> > > Hi Daniel,
> > > 
> > > That was right. I messed up a bit with the paths, uninstalling and 
> > > then re-installing with the default path in configure worked fine 
> > > this time.
> > > Thanks!
> > > 
> > > -best Regards,
> > > Vasavee
> > > 
> > > 
> > > -Original Message-
> > > From: Charles, Daniel [mailto:daniel.char...@intel.com]
> > > Sent: Wednesday, December 7, 2016 5:25 PM
> > > To: Vi

Re: [Libva] [PATCH 1/4] i965_encoder: consistently represent framerate as a fraction

[Sean V Kelley]

I'm fine with this change and it adds consistency.

lgtm

Thanks,

Sean

On Thu, Dec 15, 2016 at 4:26 AM, Mark Thompson  wrote:

> On 15/12/16 08:54, Xiang, Haihao wrote:
> >
> > Hi Mark,
> >
> > Thanks for your patch, is there any benefit to use a fraction? using
> > 100 as framerate_den works well in the driver.
>
> Everything the driver interacts with directly, on both sides, uses a
> fraction:
>
> * In VAAPI, VAEncMiscParameterFrameRate contains a 16 / 16 fraction.
>
> * Newer hardware uses a fraction directly where it requires a framerate
> (gen9_vp9_encoder.c:1204, gen9_vdenc.c:1648).
>
> * H.264 and H.265 streams contain num_units_in_tick / time_scale.
>
> * gstreamer (GstVideoInfo.fps_[nd]), libyami 
> (VideoFrameRate.frameRate{Num,Denom})
> and libavcodec (AVCodecContext.{time_base,framerate} are fraction
> structures) all represent framerate as a fraction.
>
> The driver should use a fraction as well to preserve the exact value and
> be consistent with everything it interacts with.
>
> Do you have any other concerns about the patch?  If there are additional
> references outside the core driver code which I have missed somehow then I
> would be happy to update them as well.
>
> Thanks,
>
> - Mark
>
> ___
> Libva mailing list
> Libva@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libva
>



-- 
Sean V. Kelley 
Open Source Technology Center / SSG
Intel Corp.
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?

[ViruS Tadala]

Hi Peter,

Thanks for your quick response.

Mentioned figures are GPU load values. I have ran the intel_gpu_top command
to get the same.

I didn't check any clock details. Used below pipeline and ran multiple
instances.

gst-launch-1.0 videotestsrc is-live=true pattern=22 horizontal-speed=20 !
'video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080,
framerate=(fraction)10/1' ! vaapiencode_h264 min-qp=20 ! queue !
vaapidecode ! queue ! appsink

Please let me know if you need more information.

Best Regards,
Veeranna.



On Thu, Dec 15, 2016 at 11:47 AM, Peter Frühberger  wrote:

> Hi Veeranna,
>
> i cannot even interpret your figures. Is that the CPU load? If yes - did
> you check the clocks?
> Which benchmark did you use? Where did the data come from, where was it
> encoded to? Was it stored? Which format?
>
> In short: Without more details you most likely get the following answer:
>
> Depends!
>
> Best regards
> Peter
>
> On Thu, Dec 15, 2016 at 4:19 PM, ViruS Tadala <
> tadala.veerannab...@gmail.com> wrote:
>
>> Hi,
>>
>> I have done some benchmarking on both platforms & observed that braswell
>> did lesser number of channels(decode + re-encode using vaapi) than baytrail.
>>
>> 60-65% for 6channels on braswell.
>>
>> 60-66 % for 10channels on baytrail.
>>
>> Please let me know whether we can expect better GPU performance on
>> braswell than baytrail or not?
>>
>> Best Regards,
>>
>> Veeranna.
>>
>> ___
>> Libva mailing list
>> Libva@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libva
>>
>>
>


-- 
Best Regards,
ViruS
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?

[Peter Frühberger]

Hi Veeranna,

i cannot even interpret your figures. Is that the CPU load? If yes - did
you check the clocks?
Which benchmark did you use? Where did the data come from, where was it
encoded to? Was it stored? Which format?

In short: Without more details you most likely get the following answer:

Depends!

Best regards
Peter

On Thu, Dec 15, 2016 at 4:19 PM, ViruS Tadala  wrote:

> Hi,
>
> I have done some benchmarking on both platforms & observed that braswell
> did lesser number of channels(decode + re-encode using vaapi) than baytrail.
>
> 60-65% for 6channels on braswell.
>
> 60-66 % for 10channels on baytrail.
>
> Please let me know whether we can expect better GPU performance on
> braswell than baytrail or not?
>
> Best Regards,
>
> Veeranna.
>
> ___
> Libva mailing list
> Libva@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libva
>
>
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

[Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?

[ViruS Tadala]

Hi,

I have done some benchmarking on both platforms & observed that braswell
did lesser number of channels(decode + re-encode using vaapi) than baytrail.

60-65% for 6channels on braswell.

60-66 % for 10channels on baytrail.

Please let me know whether we can expect better GPU performance on braswell
than baytrail or not?

Best Regards,

Veeranna.
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] [PATCH 2/3] H.265 main 10 encoder supports only 10bpp render targets

[Mark Thompson]

On 05/12/16 17:54, Mark Thompson wrote:
> Signed-off-by: Mark Thompson 
> ---
> The supported surface formats are already correct (i.e. only P010); this 
> makes the render target format right as well (before this, it declares that 
> it supports only YUV 4:2:0 8-bit).
> 
>  src/i965_drv_video.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
> index d83427c..9e1c92a 100644
> --- a/src/i965_drv_video.c
> +++ b/src/i965_drv_video.c
> @@ -880,6 +880,8 @@ i965_get_default_chroma_formats(VADriverContextP ctx, 
> VAProfile profile,
>  break;
>  
>  case VAProfileHEVCMain10:
> +if (HAS_HEVC10_ENCODING(i965) && entrypoint == VAEntrypointEncSlice)
> +chroma_formats = VA_RT_FORMAT_YUV420_10BPP;
>  if (HAS_HEVC10_DECODING(i965) && entrypoint == VAEntrypointVLD)
>  chroma_formats |= i965->codec_info->hevc_dec_chroma_formats;
>  break;
> 

Ping.  (The other patches in this series have been considered separately.)

Thanks,

- Mark

___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] [PATCH 1/4] i965_encoder: consistently represent framerate as a fraction

[Mark Thompson]

On 15/12/16 08:54, Xiang, Haihao wrote:
> 
> Hi Mark,
> 
> Thanks for your patch, is there any benefit to use a fraction? using
> 100 as framerate_den works well in the driver.

Everything the driver interacts with directly, on both sides, uses a fraction:

* In VAAPI, VAEncMiscParameterFrameRate contains a 16 / 16 fraction.

* Newer hardware uses a fraction directly where it requires a framerate 
(gen9_vp9_encoder.c:1204, gen9_vdenc.c:1648).

* H.264 and H.265 streams contain num_units_in_tick / time_scale.

* gstreamer (GstVideoInfo.fps_[nd]), libyami 
(VideoFrameRate.frameRate{Num,Denom}) and libavcodec 
(AVCodecContext.{time_base,framerate} are fraction structures) all represent 
framerate as a fraction.

The driver should use a fraction as well to preserve the exact value and be 
consistent with everything it interacts with.

Do you have any other concerns about the patch?  If there are additional 
references outside the core driver code which I have missed somehow then I 
would be happy to update them as well.

Thanks,

- Mark

___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] [PATCH 1/4] i965_encoder: consistently represent framerate as a fraction

[Xiang, Haihao]

Hi Mark,

Thanks for your patch, is there any benefit to use a fraction? using
100 as framerate_den works well in the driver.

Regards
Haihao


> Update references in both H.264 encoders (gen6_mfc and gen9_vdenc).
> 
> Signed-off-by: Mark Thompson 
> ---
>  src/gen6_mfc_common.c | 11 ++
>  src/gen9_vdenc.c  | 29 ++--
>  src/gen9_vdenc.h  |  3 ++-
>  src/i965_encoder.c| 61 +--
> 
>  src/i965_encoder.h|  3 ++-
>  5 files changed, 72 insertions(+), 35 deletions(-)
> 
> diff --git a/src/gen6_mfc_common.c b/src/gen6_mfc_common.c
> index 68d030e..c29817e 100644
> --- a/src/gen6_mfc_common.c
> +++ b/src/gen6_mfc_common.c
> @@ -119,16 +119,19 @@ static void intel_mfc_brc_init(struct
> encode_state *encode_state,
>  
>  if (i == 0) {
>  bitrate = encoder_context->brc.bits_per_second[0];
> -framerate = (double)encoder_context-
> >brc.framerate_per_100s[0] / 100.0;
> +framerate = (double)encoder_context-
> >brc.framerate_num[0] / (double)encoder_context-
> >brc.framerate_den[0];
>  } else {
>  bitrate = (encoder_context->brc.bits_per_second[i] -
> encoder_context->brc.bits_per_second[i - 1]);
> -framerate = (double)(encoder_context-
> >brc.framerate_per_100s[i] - encoder_context-
> >brc.framerate_per_100s[i - 1]) / 100.0;
> +framerate = ((double)encoder_context-
> >brc.framerate_num[i] / (double)encoder_context-
> >brc.framerate_den[i]) -
> +((double)encoder_context->brc.framerate_num[i - 1] /
> (double)encoder_context->brc.framerate_den[i - 1]);
>  }
>  
>  if (i == encoder_context->layer.num_layers - 1)
>  factor = 1.0;
> -else
> -factor = (double)encoder_context-
> >brc.framerate_per_100s[i] / encoder_context-
> >brc.framerate_per_100s[encoder_context->layer.num_layers - 1];
> +else {
> +factor = ((double)encoder_context->brc.framerate_num[i]
> / (double)encoder_context->brc.framerate_den[i]) /
> +((double)encoder_context->brc.framerate_num[i - 1] /
> (double)encoder_context->brc.framerate_den[i - 1]);
> +}
>  
>  hrd_factor = (double)bitrate / encoder_context-
> >brc.bits_per_second[encoder_context->layer.num_layers - 1];
>  
> diff --git a/src/gen9_vdenc.c b/src/gen9_vdenc.c
> index 8009b31..b2d0b21 100644
> --- a/src/gen9_vdenc.c
> +++ b/src/gen9_vdenc.c
> @@ -851,7 +851,8 @@
> gen9_vdenc_update_misc_parameters(VADriverContextP ctx,
>  if (vdenc_context->internal_rate_mode != I965_BRC_CQP &&
>  encoder_context->brc.need_reset) {
>  /* So far, vdenc doesn't support temporal layer */
> -vdenc_context->frames_per_100s = encoder_context-
> >brc.framerate_per_100s[0];
> +vdenc_context->framerate_num = encoder_context-
> >brc.framerate_num[0];
> +vdenc_context->framerate_den = encoder_context-
> >brc.framerate_den[0];
>  
>  vdenc_context->vbv_buffer_size_in_bit = encoder_context-
> >brc.hrd_buffer_size;
>  vdenc_context->init_vbv_buffer_fullness_in_bit =
> encoder_context->brc.hrd_initial_buffer_fullness;
> @@ -927,7 +928,8 @@ gen9_vdenc_update_parameters(VADriverContextP
> ctx,
>   !vdenc_context->vbv_buffer_size_in_bit ||
>   !vdenc_context->max_bit_rate ||
>   !vdenc_context->target_bit_rate ||
> - !vdenc_context->frames_per_100s))
> + !vdenc_context->framerate_num ||
> + !vdenc_context->framerate_den))
>  vdenc_context->brc_enabled = 0;
>  
>  if (!vdenc_context->brc_enabled) {
> @@ -1565,7 +1567,8 @@
> gen9_vdenc_get_profile_level_max_frame(VADriverContextP ctx,
>  tmpf = max_mbps / 172.0;
>  
>  max_byte_per_frame0 = (uint64_t)(tmpf * bits_per_mb);
> -max_byte_per_frame1 = (uint64_t)(((double)max_mbps * 100) /
> vdenc_context->frames_per_100s *bits_per_mb);
> +max_byte_per_frame1 = (uint64_t)(((double)max_mbps *
> vdenc_context->framerate_den) /
> + (double)vdenc_context-
> >framerate_num * bits_per_mb);
>  
>  /* TODO: check VAEncMiscParameterTypeMaxFrameSize */
>  ret = (unsigned int)MIN(max_byte_per_frame0,
> max_byte_per_frame1);
> @@ -1586,12 +1589,12 @@
> gen9_vdenc_calculate_initial_qp(VADriverContextP ctx,
>  
>  frame_size = (vdenc_context->frame_width * vdenc_context-
> >frame_height * 3 / 2);
>  qp = (int)(1.0 / 1.2 * pow(10.0,
> -   (log10(frame_size * 2.0 / 3.0 *
> ((float)vdenc_context->frames_per_100s) /
> -  ((float)(vdenc_context-
> >target_bit_rate * 1000) * 100)) - x0) *
> +   (log10(frame_size * 2.0 / 3.0 *
> vdenc_context->framerate_num /
> +  ((double)vdenc_context-
> >target_bit_rate * 1000.0 * vdenc_context->framerate_den)) - x0) *
> (y1 - y0) / (x1 

Re: [Libva] Observed random hang on intel platform like baytrail, haswell and skylake

[Xiang, Haihao]

Hi Veeranna,

How many instances did you launch? can you remotely access your machine when 
system hang?

Thanks
Haihao


Hi,

I have downloaded krogoth version of yocto and build it.

Kernel version : 4.4
gstreamer-vaapi : 1.8.0
libva : 1.7.0
Intel-driver : 1.7.0

Then flashed the built image on haswell(Intel i5-4590) and launched multiple 
instances of below pipeline and observed system hang at some point.

gst-launch-1.0 videotestsrc is-live=true pattern=22 horizontal-speed=20 ! 
'video/x-raw, format=(string)I420, width=(int)864, height=(int)480, 
framerate=(fraction)10/1' ! vaapiencode_h264 min-qp=20 ! queue ! vaapidecode ! 
queue ! vaapisink

Didn't get any kernel logs or gstreamer error messages when it occurs. I tried 
below tests but didn't get helped.

1. Tried kernel version 4.8
2. Other versions of gstreamer-vaapi and libva.


Looking forward for your suggestions and let me know if you need more 
information.

Best Regards,
Veeranna





___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake

[Xiang, Haihao]

Hi Vasavee,

Maybe it is not a yami issue. I encountered another issue for VP8
 video which is encoded by another vaapi based tool. I saw double
frames when transcoding the video back to YUV using ffmpeg, however
vpxdec works well for me, so I guess there are some issues in FFmpeg.
Could you try vpxdec with your VP9 video? I think it is not yami issue
if vpxdec works for you.

Thanks
Haihao


> Hi Daniel,
> 
> Sure, will do that! Thank you for the pointers.
> 
> -Best Regards,
> Vasavee
> 
> -Original Message-
> From: Charles, Daniel [mailto:daniel.char...@intel.com] 
> Sent: Monday, December 12, 2016 10:53 AM
> To: Vijayaraghavan, Vasavee 
> Cc: Xiang, Haihao ; libva@lists.freedesktop.o
> rg
> Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode
> on KabyLake
> 
> Hi Vasavee,
> 
> Can you file a bug on libyami for your observation?
> 
> https://github.com/01org/libyami/issues
> 
> Thanks.
> 
> --
> Daniel.
> 
> On Mon, Dec 12, 2016 at 10:45 AM, Vijayaraghavan, Vasavee  jayaragha...@intel.com> wrote:
> > Hi Haihao,
> > 
> > I might have missed setting the PKG_CONFIG_PATH while trying to use
> > './configure --prefix=/usr --exec-prefix=/'.
> > But like Daniel suggested, I did a clean install with default paths
> > and it works fine for me.
> > 
> > I have installed libyami and libyami utils to test VP9 encode and
> > decode. I am able to run VP9 encode and decode using the pre-built
> > binaries located in libyami-utils/tools (yamiencode and
> > yamidecode).
> > I am facing issues in playing back the VP9 encoded video.
> > Say test.ivf is my VP9 encoded output, when I playback the file
> > using ffplay or VLC player, I am able to see only the first and
> > last frame of the encoded video (though the video shows to have 500
> > frames - same as the input yuv; verified the number of frames using
> > ffprobe). Although, when I decode it back to yuv, the yuv is
> > exactly the same as original input yuv and plays all the frames
> > fine.
> > 
> > At this point, I haven’t added any quality control factor to encode
> > the video and hence I have used a simple command line:
> > $cd /home/user/libyami-utils/tools
> > $./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500
> > -o 
> > test.ivf
> > 
> > Am I missing something in the commandline which is why I am unable
> > to play the output?
> > 
> > Note: I tried playing pre-encoded test_vp9.ivf files available
> > through MediaSDK samples and they played without an issue.
> > 
> > -Thanks
> > Vasavee
> > 
> > -Original Message-
> > From: Xiang, Haihao
> > Sent: Wednesday, December 7, 2016 8:07 PM
> > To: Charles, Daniel ; Vijayaraghavan, 
> > Vasavee 
> > Cc: libva@lists.freedesktop.org
> > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated
> > encode/decode 
> > on KabyLake
> > 
> > 
> > I think './configure --prefix=/usr --exec-prefix=/' should work
> > too, otherwise it might have issue. Actually this configuration
> > works fine for me when I build libva and libva-intel-driver. I set
> > PKG_CONFIG_PATH variable to /lib/pkgconfig because libva.pc is
> > installed in /lib/pkgconfig which is not in the default pkg-config
> > search path.
> > 
> > Thanks
> > Haihao
> > 
> > > Hi Daniel,
> > > 
> > > That was right. I messed up a bit with the paths, uninstalling
> > > and 
> > > then re-installing with the default path in configure worked fine
> > > this time.
> > > Thanks!
> > > 
> > > -best Regards,
> > > Vasavee
> > > 
> > > 
> > > -Original Message-
> > > From: Charles, Daniel [mailto:daniel.char...@intel.com]
> > > Sent: Wednesday, December 7, 2016 5:25 PM
> > > To: Vijayaraghavan, Vasavee 
> > > Cc: Xiang, Haihao ; libva@lists.freedeskt
> > > op.o 
> > > rg
> > > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated
> > > encode/decode 
> > > on KabyLake
> > > 
> > > That's not expected, libdrm should also compile ok on the
> > > defaults.
> > > Normally what I see Ubuntu users do is to run  $sudo make install
> > > 
> > > If you just want to install it on a custom folder, -- 
> > > prefix= should be sufficient for all packages you
> > > listed, 
> > > no need to mess up with --exec-dir
> > > 
> > > --
> > > Daniel.
> > > 
> > > 
> > > 
> > > On Wed, Dec 7, 2016 at 5:07 PM, Vijayaraghavan, Vasavee 
> > >  wrote:
> > > > Hi Daniel.
> > > > I believe so, I used this configuration because my libdrm
> > > > doesn’t 
> > > > build if I use the default config options.
> > > > 
> > > > -Thanks
> > > > Vasavee
> > > > 
> > > > -Original Message-
> > > > From: Charles, Daniel [mailto:daniel.char...@intel.com]
> > > > Sent: Wednesday, December 7, 2016 3:36 PM
> > > > To: Vijayaraghavan, Vasavee 
> > > > Cc: Xiang, Haihao ; libva@lists.freedes
> > > > ktop 
> > > > .org
> > > > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated 
> > > > encode/decode on KabyLake
> > > > 
> > > > Hello Vasavee,
> > > > 
> > > > Is your user allowed to write files on the --prefix=/usr and
> > > > the -- 
> > > > exec-pr