RE: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC

[Liu, Leo]

[AMD Official Use Only - General]

This is being looked.

> -Original Message-
> From: mesa-dev  On Behalf Of
> Chris Rankin
> Sent: Thursday, February 15, 2024 10:38 AM
> To: mesa-dev@lists.freedesktop.org
> Subject: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC
>
> I have discovered that my RX6600 cannot use VDPAU to decode HEVC, although
> VA-API works OK. Unfortunately, VLC 3.x only supports VDPAU these days for
> hardware decoding.
>
> I have raised this issue:
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10599
>
> Mesa 23.3.5 just used to fail, but both Mesa 24.0.1 and 24.1.0-devel actually
> lock up the GPU and force me to reboot my PC.
>
> According to vdpauinfo:
>
> namelevel macbs width height
> 
> ...
> HEVC_MAIN  186 139264  8192  4352
> HEVC_MAIN_10   186 139264  8192  4352
> HEVC_MAIN_STILL--- not supported ---
> HEVC_MAIN_12   --- not supported ---
> HEVC_MAIN_444  --- not supported ---
> HEVC_MAIN_444_10   --- not supported ---
> HEVC_MAIN_444_12   --- not supported ---
> ...
>
> Cheers,
> Chris

Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting

[Liu, Leo]

+Thong.

-Original Message-
From: mesa-dev  On Behalf Of Ilia Mirkin
Sent: November 25, 2020 5:48 PM
To: ML Mesa-dev ; Thai, Thong 

Subject: Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when 
blitting

Hi Thong,

In this change:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D49465babdb35d88ed8a283e925d6cd346255d50cdata=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135677095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=g1pJUxsSM68kEjNZ6VDJGufaOF1Wwcezl1ehezq8mqo%3Dreserved=0

You appear to change the height of the underlying resource while doing a blit. 
This is never legal though -- the height of the resource is effectively 
immutable (and subject to various constraints). I'm not sure what issue you're 
having, but this is not the way to fix it.

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135687091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ug6N9kvs1JzjDhHPpB%2F9ttrCaahVgm7NJ6Bk0zCxc4A%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeon/vcn: Handle crop parameters for encoder

[Liu, Leo]

The mesa process has switched to using merge requests.

-Original Message-
From: mesa-dev  On Behalf Of Satyajit 
Sahu
Sent: Tuesday, December 24, 2019 4:39 AM
To: mesa-dev@lists.freedesktop.org
Cc: Sharma, Deepak ; Sahu, Satyajit 

Subject: [Mesa-dev] [PATCH] radeon/vcn: Handle crop parameters for encoder

Set proper cropping parameter if frame cropping is enabled

Signed-off-by: Satyajit Sahu 

diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index aa9182f273b..0bcce867327 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -52,10 +52,17 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder 
*enc, struct pipe_pic
   enc->enc_pic.ref_idx_l1 = pic->ref_idx_l1;
   enc->enc_pic.not_referenced = pic->not_referenced;
   enc->enc_pic.is_idr = (pic->picture_type == 
PIPE_H264_ENC_PICTURE_TYPE_IDR);
-  enc->enc_pic.crop_left = 0;
-  enc->enc_pic.crop_right = (align(enc->base.width, 16) - enc->base.width) 
/ 2;
-  enc->enc_pic.crop_top = 0;
-  enc->enc_pic.crop_bottom = (align(enc->base.height, 16) - 
enc->base.height) / 2;
+  if (pic->pic_ctrl.enc_frame_cropping_flag) {
+  enc->enc_pic.crop_left = pic->pic_ctrl.enc_frame_crop_left_offset;
+  enc->enc_pic.crop_right = pic->pic_ctrl.enc_frame_crop_right_offset;
+  enc->enc_pic.crop_top = pic->pic_ctrl.enc_frame_crop_top_offset;
+  enc->enc_pic.crop_bottom = 
pic->pic_ctrl.enc_frame_crop_bottom_offset;
+  } else {
+  enc->enc_pic.crop_left = 0;
+  enc->enc_pic.crop_right = (align(enc->base.width, 16) - 
enc->base.width) / 2;
+  enc->enc_pic.crop_top = 0;
+  enc->enc_pic.crop_bottom = (align(enc->base.height, 16) - 
enc->base.height) / 2;
+  }
   enc->enc_pic.rc_layer_init.target_bit_rate = 
pic->rate_ctrl.target_bitrate;
   enc->enc_pic.rc_layer_init.peak_bit_rate = pic->rate_ctrl.peak_bitrate;
   enc->enc_pic.rc_layer_init.frame_rate_num = 
pic->rate_ctrl.frame_rate_num;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cleo.liu%40amd.com%7Cebe0ab52bd1948be95b108d788552cd2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637127771729035994sdata=8APh%2FJucqePZPxtib0Wg5spsKYysUtAlzR6W34muOcc%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate change in encoder

[Liu, Leo]

+Boyuan

From: Marek Olšák 
Sent: December 3, 2019 7:21:23 PM
To: Sahu, Satyajit ; Liu, Leo 
Cc: ML Mesa-dev ; Sharma, Deepak 

Subject: Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate 
change in encoder

+Leo

On Mon, Dec 2, 2019 at 11:31 PM Satyajit Sahu 
mailto:satyajit.s...@amd.com>> wrote:
Added support for bitrate change in between encoding.

Signed-off-by: Satyajit Sahu 
mailto:satyajit.s...@amd.com>>

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 84d3c1e2fa4..7d7a2fa4eb3 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -268,7 +268,8 @@ static void rvce_begin_frame(struct pipe_video_codec 
*encoder,
enc->pic.rate_ctrl.rate_ctrl_method != 
pic->rate_ctrl.rate_ctrl_method ||
enc->pic.quant_i_frames != pic->quant_i_frames ||
enc->pic.quant_p_frames != pic->quant_p_frames ||
-   enc->pic.quant_b_frames != pic->quant_b_frames;
+   enc->pic.quant_b_frames != pic->quant_b_frames ||
+   enc->pic.rate_ctrl.target_bitrate != 
pic->rate_ctrl.target_bitrate;

enc->pic = *pic;
si_get_pic_param(enc, pic);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index aa9182f273b..c4fb9a7bd92 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -247,6 +247,17 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
 {
struct radeon_encoder *enc = (struct radeon_encoder*)encoder;
struct vl_video_buffer *vid_buf = (struct vl_video_buffer *)source;
+   bool need_rate_control = false;
+
+   if (u_reduce_video_profile(enc->base.profile) == 
PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+   struct pipe_h264_enc_picture_desc *pic = (struct 
pipe_h264_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rate_ctrl.target_bitrate;
+   } else if (u_reduce_video_profile(picture->profile) == 
PIPE_VIDEO_FORMAT_HEVC) {
+struct pipe_h265_enc_picture_desc *pic = (struct 
pipe_h265_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rc.target_bitrate;
+   }

radeon_vcn_enc_get_param(enc, picture);

@@ -266,6 +277,10 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
flush(enc);
si_vid_destroy_buffer();
}
+   if (need_rate_control) {
+   enc->begin(enc, picture);
+   flush(enc);
+   }
 }

 static void radeon_enc_encode_bitstream(struct pipe_video_codec *encoder,
--
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev=02%7C01%7Cleo.liu%40amd.com%7Cae84ee699f3246cb915708d7784ffad3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637110157225190450=dw2yJa%2BgZ3t1BlOH87PypwWIhmH2y7pZ8vU5SiWBkO8%3D=0>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac: add missing Arcturus to the info of pc lines

[Liu, Leo]

Signed-off-by: Leo Liu 
Cc: Marek Olšák 
---
 src/amd/common/ac_gpu_info.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 9caa51cb8b9..0061d2deb01 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -616,6 +616,7 @@ bool ac_query_gpu_info(int fd, void *dev_p,
case CHIP_RAVEN:
case CHIP_RAVEN2:
case CHIP_RENOIR:
+   case CHIP_ARCTURUS:
case CHIP_NAVI10:
case CHIP_NAVI12:
pc_lines = 1024;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] radeon/vcn: exclude raven2 from vcn 2.0 encode initialization

[Liu, Leo]

Reviewed-by: Leo Liu 

On 2019-09-10 10:06 a.m., Das, Indrajit-kumar wrote:
> From: Indrajit Das 
> Date: Tue, 10 Sep 2019 14:52:14 +0530
> Subject: [PATCH] radeon/vcn: exclude raven2 from vcn 2.0 encode initialization
>
> Signed-off-by: Indrajit Das 
> ---
>   src/gallium/drivers/radeon/radeon_vcn_enc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> index afdc2a9..2ab4e45 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> @@ -410,7 +410,7 @@ struct pipe_video_codec *radeon_create_encoder(struct 
> pipe_context *context,
>   goto error;
>   }
>   
> - if (sscreen->info.family <= CHIP_RAVEN)
> + if (sscreen->info.family <= CHIP_RAVEN2)
>   radeon_enc_1_2_init(enc);
>   else
>   radeon_enc_2_0_init(enc);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeon/vcn: add RENOIR VCN decode support

[Liu, Leo]

It has same VCN2.x block as Navi1x

Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index 77bfe187674..0743d47f703 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -840,7 +840,7 @@ static struct pb_buffer *rvcn_dec_message_decode(struct 
radeon_decoder *dec,
decode->sc_coeff_size = 0;
 
decode->sw_ctxt_size = RDECODE_SESSION_CONTEXT_SIZE;
-   decode->db_pitch = (((struct si_screen*)dec->screen)->info.family >= 
CHIP_ARCTURUS &&
+   decode->db_pitch = (((struct si_screen*)dec->screen)->info.family >= 
CHIP_RENOIR &&
dec->base.width > 32 && dec->stream_type == 
RDECODE_CODEC_VP9) ?
align(dec->base.width, 64) :
align(dec->base.width, 32) ;
@@ -938,7 +938,7 @@ static struct pb_buffer *rvcn_dec_message_decode(struct 
radeon_decoder *dec,
/* default probability + probability data */
ctx_size = 2304 * 5;
 
-   if (((struct si_screen*)dec->screen)->info.family >= 
CHIP_ARCTURUS) {
+   if (((struct si_screen*)dec->screen)->info.family >= 
CHIP_RENOIR) {
/* SRE collocated context data */
ctx_size += 32 * 2 * 128 * 68;
/* SMP collocated context data */
@@ -1263,7 +1263,7 @@ static unsigned calc_dpb_size(struct radeon_decoder *dec)
case PIPE_VIDEO_FORMAT_VP9:
max_references = MAX2(max_references, 9);
 
-   dpb_size = (((struct si_screen*)dec->screen)->info.family >= 
CHIP_ARCTURUS) ?
+   dpb_size = (((struct si_screen*)dec->screen)->info.family >= 
CHIP_RENOIR) ?
(8192 * 4320 * 3 / 2) * max_references :
(4096 * 3000 * 3 / 2) * max_references;
 
@@ -1607,7 +1607,7 @@ struct pipe_video_codec *radeon_create_decoder(struct 
pipe_context *context,
dec->reg.data1 = RDECODE_VCN2_5_GPCOM_VCPU_DATA1;
dec->reg.cmd = RDECODE_VCN2_5_GPCOM_VCPU_CMD;
dec->reg.cntl = RDECODE_VCN2_5_ENGINE_CNTL;
-   } else if (sctx->family >= CHIP_NAVI10) {
+   } else if (sctx->family >= CHIP_NAVI10 || sctx->family == CHIP_RENOIR) {
dec->reg.data0 = RDECODE_VCN2_GPCOM_VCPU_DATA0;
dec->reg.data1 = RDECODE_VCN2_GPCOM_VCPU_DATA1;
dec->reg.cmd = RDECODE_VCN2_GPCOM_VCPU_CMD;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeon/vcn: adding engine type for new fw interface

[Liu, Leo]

Reviewed-by Leo Liu 

On 2019-07-11 5:56 p.m., boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang 
>
> Signed-off-by: Boyuan Zhang 
> ---
>   src/gallium/drivers/radeon/radeon_vcn_enc.h | 2 ++
>   src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 1 +
>   src/gallium/drivers/radeon/radeon_vcn_enc_2_0.c | 4 ++--
>   3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.h 
> b/src/gallium/drivers/radeon/radeon_vcn_enc.h
> index fb800c3c6a3..bcff114ff18 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.h
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.h
> @@ -42,6 +42,8 @@
>   #define RENCODE_IF_MINOR_VERSION_MASK   
> 0x
>   #define RENCODE_IF_MINOR_VERSION_SHIFT  0
>   
> +#define RENCODE_ENGINE_TYPE_ENCODE   1
> +
>   #define RENCODE_ENCODE_STANDARD_HEVC0
>   #define RENCODE_ENCODE_STANDARD_H2641
>   
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> index 9a47affd14b..a437add48ee 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> @@ -69,6 +69,7 @@ static void radeon_enc_session_info(struct radeon_encoder 
> *enc)
>   RADEON_ENC_BEGIN(enc->cmd.session_info);
>   RADEON_ENC_CS(enc->enc_pic.session_info.interface_version);
>   RADEON_ENC_READWRITE(enc->si->res->buf, enc->si->res->domains, 0x0);
> + RADEON_ENC_CS(RENCODE_ENGINE_TYPE_ENCODE);
>   RADEON_ENC_END();
>   }
>   
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_2_0.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc_2_0.c
> index dfad95a4dd9..d2c6378a055 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_2_0.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_2_0.c
> @@ -35,8 +35,8 @@
>   #include "radeon_video.h"
>   #include "radeon_vcn_enc.h"
>   
> -#define RENCODE_FW_INTERFACE_MAJOR_VERSION   0
> -#define RENCODE_FW_INTERFACE_MINOR_VERSION   2
> +#define RENCODE_FW_INTERFACE_MAJOR_VERSION   1
> +#define RENCODE_FW_INTERFACE_MINOR_VERSION   1
>   
>   #define RENCODE_IB_PARAM_SESSION_INFO   
> 0x0001
>   #define RENCODE_IB_PARAM_TASK_INFO  
> 0x0002
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Expose support for 10 bit VP9 decode

[Liu, Leo]

On 2019-06-26 11:56 p.m., Vishwakarma, Pratik wrote:
> Fix si_vid_is_format_supported to expose
> support for 10-bit VP9 decode using P016 format

You could have a better commit message here, like what it will cause by 
missing this patch.


Regards,

Leo


>
> Signed-off-by: Pratik Vishwakarma 
> ---
>   src/gallium/drivers/radeonsi/si_get.c | 4 
>   1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index 4e23d283ab7..8cc5933f9bc 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -709,6 +709,10 @@ static boolean si_vid_is_format_supported(struct 
> pipe_screen *screen,
>   return (format == PIPE_FORMAT_NV12) ||
>   (format == PIPE_FORMAT_P016);
>   
> + /* Vp9 profile 2 supports 10 bit decoding using P016 */
> + if (profile == PIPE_VIDEO_PROFILE_VP9_PROFILE2)
> + return format == PIPE_FORMAT_P016;
> +
>   /* we can only handle this one with UVD */
>   if (profile != PIPE_VIDEO_PROFILE_UNKNOWN)
>   return format == PIPE_FORMAT_NV12;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeon/vcn: enable rate control for hevc encoding

[Liu, Leo]

Please tag the bugzilla link to the commit messages. With that, the set 
of patches are

Acked-by: Leo Liu 


On 2019-06-17 3:07 p.m., boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang 
>
> Set cu_qp_delta_enable_flag on when rate control is enabled, and it
> off when no rate control is disabled (constant qp).
>
> Signed-off-by: Boyuan Zhang 
> ---
>   src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 8 +++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> index 3302ed7524..e4b9162034 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> @@ -687,7 +687,13 @@ static void radeon_enc_nalu_pps_hevc(struct 
> radeon_encoder *enc)
>   radeon_enc_code_se(enc, 0x0);
>   radeon_enc_code_fixed_bits(enc, 
> enc->enc_pic.hevc_spec_misc.constrained_intra_pred_flag, 1);
>   radeon_enc_code_fixed_bits(enc, 0x0, 1);
> - radeon_enc_code_fixed_bits(enc, 0x0, 1);
> + if (enc->enc_pic.rc_session_init.rate_control_method ==
> + RENC_UVD_RATE_CONTROL_METHOD_NONE)
> + radeon_uvd_enc_code_fixed_bits(enc, 0x0, 1);
> + else {
> + radeon_uvd_enc_code_fixed_bits(enc, 0x1, 1);
> + radeon_uvd_enc_code_ue(enc, 0x0);
> + }
>   radeon_enc_code_se(enc, enc->enc_pic.hevc_deblock.cb_qp_offset);
>   radeon_enc_code_se(enc, enc->enc_pic.hevc_deblock.cr_qp_offset);
>   radeon_enc_code_fixed_bits(enc, 0x0, 1);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeon/vcn: fix poc for hevc encode

[Liu, Leo]

These 2 patches are:

Acked-by: Leo Liu 

On 5/29/19 2:41 PM, boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang 
>
> MaxPicOrderCntLsb should be at least 16 according to the spec,
> therefore add minimum value check.
>
> Also use poc value passed from st instead of calculation
> in slice header encoding.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta...@lists.freedesktop.org
>
> V2: Fix typo
>
> V3: Use MAX2 macro instead of coding. Also MaxPicOrderCntLsb
> should be power of 2 according to spec.
>
> Signed-off-by: Boyuan Zhang 
> ---
>   src/gallium/drivers/radeon/radeon_vcn_enc.c | 3 ++-
>   src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 2 +-
>   2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> index 8f9af73c66..3651d8a86b 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> @@ -72,7 +72,8 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder 
> *enc, struct pipe_pic
> enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
> enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
> enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
> -  enc->enc_pic.max_poc = pic->seq.intra_period;
> +  enc->enc_pic.max_poc =
> + MAX2(16, util_next_power_of_two(pic->seq.intra_period));
> enc->enc_pic.log2_max_poc = 0;
> for (int i = enc->enc_pic.max_poc; i != 0; 
> enc->enc_pic.log2_max_poc++)
>i = (i >> 1);
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> index 7f5b190934..3302ed7524 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> @@ -988,7 +988,7 @@ static void radeon_enc_slice_header_hevc(struct 
> radeon_encoder *enc)
>   }
>   
>   if ((enc->enc_pic.nal_unit_type != 19) && (enc->enc_pic.nal_unit_type 
> != 20)) {
> - radeon_enc_code_fixed_bits(enc, enc->enc_pic.frame_num % 
> enc->enc_pic.max_poc, enc->enc_pic.log2_max_poc);
> + radeon_enc_code_fixed_bits(enc, enc->enc_pic.pic_order_cnt, 
> enc->enc_pic.log2_max_poc);
>   if (enc->enc_pic.picture_type == PIPE_H264_ENC_PICTURE_TYPE_P)
>   radeon_enc_code_fixed_bits(enc, 0x1, 1);
>   else {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeon/vcn: fix max poc for hevc encode

[Liu, Leo]

On 5/17/19 7:54 PM, boyuan.zh...@amd.com wrote:
> [CAUTION: External Email]
>
> From: Boyuan Zhang 
>
> Fix max poc value with hardcoded value until new feature requires
> to change this in the future.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta...@lists.freedesktop.org
>
> Signed-off-by: Boyuan Zhang 
> ---
>   src/gallium/drivers/radeon/radeon_vcn_enc.c | 4 +++-
>   src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 1 -
>   2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> index 7d64a28a405..b8c73227929 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> @@ -72,7 +72,9 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder 
> *enc, struct pipe_pic
> enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
> enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
> enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
> -  enc->enc_pic.max_poc = pic->seq.intra_period;
> +  enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;
> +  enc->enc_pic.max_poc =
> + (enc->enc_pic.layer_ctrl.max_num_temporal_layers == 4) ? 32 : 16;

You have set "+  enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;", why 
to check whether it's 4?

Regards,
Leo

> enc->enc_pic.log2_max_poc = 0;
> for (int i = enc->enc_pic.max_poc; i != 0; 
> enc->enc_pic.log2_max_poc++)
>i = (i >> 1);
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c 
> b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> index 7f5b1909344..c489de39a89 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> @@ -253,7 +253,6 @@ static void radeon_enc_session_init_hevc(struct 
> radeon_encoder *enc)
>
>   static void radeon_enc_layer_control(struct radeon_encoder *enc)
>   {
> -   enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;
>  enc->enc_pic.layer_ctrl.num_temporal_layers = 1;
>
>  RADEON_ENC_BEGIN(RENCODE_IB_PARAM_LAYER_CONTROL);
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: set back buffer from output to NULL with front buffer case

[Liu, Leo]

On 2019-05-14 5:29 a.m., Michel Dänzer wrote:
> [CAUTION: External Email]
>
> On 2019-05-09 8:10 p.m., Liu, Leo wrote:
>> Since the using output optimization is only for back buffer case
>>
>> Signed-off-by: Leo Liu 
>> ---
>>   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> index 1558d832555..77d1972af2c 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> @@ -438,6 +438,7 @@ dri3_set_drawable(struct vl_dri3_screen *scrn, Drawable 
>> drawable)
>>ret = false;
>> else {
>>scrn->is_pixmap = true;
>> + scrn->base.set_back_texture_from_output = NULL;
>>if (scrn->front_buffer) {
>>   dri3_free_front_buffer(scrn, scrn->front_buffer);
>>   scrn->front_buffer = NULL;
>>
> Couldn't dri3_set_drawable be called for a pixmap first, then later for
> a window, for the same scrn?

I could not think of any of such case. AFAIK, the video is rendering 
either to window drawable as back buffer case or to pixmap drawable as 
front buffer case.

Thanks,

Leo


>
> --
> Earthling Michel Dänzer   |  https://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: set back buffer from output to NULL with front buffer case

[Liu, Leo]

Ping...

On 5/9/19 2:10 PM, Liu, Leo wrote:
> Since the using output optimization is only for back buffer case
>
> Signed-off-by: Leo Liu 
> ---
>   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 1558d832555..77d1972af2c 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -438,6 +438,7 @@ dri3_set_drawable(struct vl_dri3_screen *scrn, Drawable 
> drawable)
>ret = false;
> else {
>scrn->is_pixmap = true;
> + scrn->base.set_back_texture_from_output = NULL;
>if (scrn->front_buffer) {
>   dri3_free_front_buffer(scrn, scrn->front_buffer);
>   scrn->front_buffer = NULL;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vl/dri3: set back buffer from output to NULL with front buffer case

[Liu, Leo]

Since the using output optimization is only for back buffer case

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 1558d832555..77d1972af2c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -438,6 +438,7 @@ dri3_set_drawable(struct vl_dri3_screen *scrn, Drawable 
drawable)
  ret = false;
   else {
  scrn->is_pixmap = true;
+ scrn->base.set_back_texture_from_output = NULL;
  if (scrn->front_buffer) {
 dri3_free_front_buffer(scrn, scrn->front_buffer);
 scrn->front_buffer = NULL;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group

[Liu, Leo]

On 5/8/19 9:19 AM, Koenig, Christian wrote:
> Am 08.05.19 um 15:14 schrieb Liu, Leo:
>> On 5/8/19 9:02 AM, Christian König wrote:
>>> [CAUTION: External Email]
>>>
>>> Am 08.05.19 um 14:56 schrieb Liu, Leo:
>>>> There is no user fence for JPEG, the bug triggering
>>>> kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)
>>> Oh, we are probably going to need to check for this in the kernel as
>>> well.
>>>
>>> Currently we only check for UVD and VCE there,
>> Are you talking about the checking for JPEG engine? if that, and then
>> yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there,
>> that's why current JPEG is triggering that.
> Yeah, but this check comes way to late.
>
> We usually already reject command submissions when they have user fences
> for UVD & VCE, see amdgpu_cs_ib_fill():
>>      /* UVD & VCE fw doesn't support user fences */
>>      ring = to_amdgpu_ring(parser->entity->rq->sched);
>>      if (parser->job->uf_addr && (
>>      ring->funcs->type == AMDGPU_RING_TYPE_UVD ||
>>      ring->funcs->type == AMDGPU_RING_TYPE_VCE))
>>      return -EINVAL;
> We should probably make that a ring flag or something like that and
> generalize he code here.
>
> Then the WARN_ON in the JPEG fence code can be removed.

Yep. I will take a look at this on the kernel side, in the meantime, can 
I have a RB on the Mesa side?

Thanks,
Leo


>
> Christian.
>
>>
>> Regards,
>>
>> Leo
>>
>>
>>> do you want to take a
>>> look Leo or should I do this?
>>>
>>> Christian.
>>>
>>>> Signed-off-by: Leo Liu 
>>>> Cc: mesa-sta...@lists.freedesktop.org
>>>> ---
>>>>     src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++-
>>>>     1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>>> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>>> index 4a2377f7e09..972030eaaa8 100644
>>>> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>>> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>>>> @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct
>>>> amdgpu_cs_context *cs)
>>>>       cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE &&
>>>>       cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC &&
>>>>       cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC &&
>>>> -  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC;
>>>> +  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC &&
>>>> +  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG;
>>>>     }
>>>>
>>>>     static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group

[Liu, Leo]

On 5/8/19 9:02 AM, Christian König wrote:
> [CAUTION: External Email]
>
> Am 08.05.19 um 14:56 schrieb Liu, Leo:
>> There is no user fence for JPEG, the bug triggering
>> kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)
>
> Oh, we are probably going to need to check for this in the kernel as 
> well.
>
> Currently we only check for UVD and VCE there,

Are you talking about the checking for JPEG engine? if that, and then 
yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there, 
that's why current JPEG is triggering that.


Regards,

Leo


> do you want to take a
> look Leo or should I do this?
>
> Christian.
>
>>
>> Signed-off-by: Leo Liu 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>   src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
>> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> index 4a2377f7e09..972030eaaa8 100644
>> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct 
>> amdgpu_cs_context *cs)
>>     cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE &&
>>     cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC &&
>>     cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC &&
>> -  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC;
>> +  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC &&
>> +  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG;
>>   }
>>
>>   static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs)
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group

[Liu, Leo]

There is no user fence for JPEG, the bug triggering
kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)

Signed-off-by: Leo Liu 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 4a2377f7e09..972030eaaa8 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct 
amdgpu_cs_context *cs)
   cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE &&
   cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC &&
   cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC &&
-  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC;
+  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC &&
+  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG;
 }
 
 static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs)
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] radeon/vce:Add support for frame_cropping_flag of VAEncSequenceParameterBufferH264

[Liu, Leo]

On 2019-04-11 6:36 a.m., Sahu, Satyajit wrote:
> From: suresh guttula 
>
> This patch will add support for frame_cropping when the input size is not
> matched with aligned size. Currently vaapi driver ignores frame cropping
> values provided by client. This change will update SPS nalu with proper
> cropping values.
>
> Signed-off-by: Satyajit Sahu 
> ---
>   src/gallium/drivers/radeon/radeon_vce_52.c | 6 ++
>   1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> b/src/gallium/drivers/radeon/radeon_vce_52.c
> index fc7ddc62a90..53f7b2f5fb5 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> @@ -83,6 +83,12 @@ static void get_pic_control_param(struct rvce_encoder 
> *enc, struct pipe_h264_enc
>   encNumMBsPerSlice *= align(enc->base.height, 16) / 16;
>   enc->enc_pic.pc.enc_crop_right_offset = (align(enc->base.width, 16) - 
> enc->base.width) >> 1;
>   enc->enc_pic.pc.enc_crop_bottom_offset = (align(enc->base.height, 16) - 
> enc->base.height) >> 1;

Please put above 2 lines to the else case of frame_cropping_flag.

With that fixed, the series are

Reviewed-by: Leo Liu 


> + if (pic->pic_ctrl.enc_frame_cropping_flag) {
> + enc->enc_pic.pc.enc_crop_left_offset = 
> pic->pic_ctrl.enc_frame_crop_left_offset;
> + enc->enc_pic.pc.enc_crop_right_offset = 
> pic->pic_ctrl.enc_frame_crop_right_offset;
> + enc->enc_pic.pc.enc_crop_top_offset = 
> pic->pic_ctrl.enc_frame_crop_top_offset;
> + enc->enc_pic.pc.enc_crop_bottom_offset = 
> pic->pic_ctrl.enc_frame_crop_bottom_offset;
> + }
>   enc->enc_pic.pc.enc_num_mbs_per_slice = encNumMBsPerSlice;
>   enc->enc_pic.pc.enc_b_pic_pattern = MAX2(enc->base.max_references, 1) - 
> 1;
>   enc->enc_pic.pc.enc_number_of_reference_frames = 
> MIN2(enc->base.max_references, 2);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Add support for frame_cropping_flag of VAEncSequenceParameterBufferH264

[Liu, Leo]

On 4/9/19 12:23 AM, Sahu, Satyajit wrote:
> On 4/9/2019 12:34 AM, Liu, Leo wrote:
>> On 4/8/19 1:17 AM, Sahu, Satyajit wrote:
>>> From: suresh guttula 
>>>
>>> This patch will add support for frame_cropping when the input size is not
>>> matched with aligned size. Currently vaapi driver ignores frame cropping
>>> values provided by client. This change will update SPS nalu with proper
>>> cropping values.
>>>
>>> Signed-off-by: suresh guttula 
>>> Signed-off-by: Satyajit Sahu 
>>> ---
>>> src/gallium/drivers/radeon/radeon_vce_52.c   | 8 ++--
>>> src/gallium/include/pipe/p_video_state.h | 5 +
>>> src/gallium/state_trackers/va/picture_h264_enc.c | 8 
>>> 3 files changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
>>> b/src/gallium/drivers/radeon/radeon_vce_52.c
>>> index fc7ddc62a90..593730756d5 100644
>>> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
>>> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
>>> @@ -81,8 +81,12 @@ static void get_pic_control_param(struct rvce_encoder 
>>> *enc, struct pipe_h264_enc
>>> unsigned encNumMBsPerSlice;
>>> encNumMBsPerSlice = align(enc->base.width, 16) / 16;
>>> encNumMBsPerSlice *= align(enc->base.height, 16) / 16;
>>> -   enc->enc_pic.pc.enc_crop_right_offset = (align(enc->base.width, 16) - 
>>> enc->base.width) >> 1;
>>> -   enc->enc_pic.pc.enc_crop_bottom_offset = (align(enc->base.height, 16) - 
>>> enc->base.height) >> 1;
>> Shouldn't we need to keep this code path when the cropping info is not
>> available, since VA spec says it's optional.
>>
>> Regards,
>>
>> Leo
> As per H264 standard
>
> When frame_cropping_flag is equal to 0, the values of
> frame_crop_left_offset, frame_crop_right_offset, frame_crop_top_offset,
> and frame_crop_bottom_offset shall be inferred to be equal to 0.
> (https://www.itu.int/rec/T-REC-H.264)
>
> So I think it should be under frame_cropping_flag condition.

For OMX encode, gst-omx haven't passed any cropping information to 
driver, that's why the alignment was used as cropping for certain size 
video, we should keep the code path for OMX.

Also you should separate the patch to three, titled as for vl:, 
radeon/vce:, and st/va/enc:


Leo


>
> Regards,
>
> Satyajit
>
>>
>>
>>> +   if (pic->pic_ctrl.enc_frame_cropping_flag) {
>>> +   enc->enc_pic.pc.enc_crop_left_offset = 
>>> pic->pic_ctrl.enc_frame_crop_left_offset;
>>> +   enc->enc_pic.pc.enc_crop_right_offset = 
>>> pic->pic_ctrl.enc_frame_crop_right_offset;
>>> +   enc->enc_pic.pc.enc_crop_top_offset = 
>>> pic->pic_ctrl.enc_frame_crop_top_offset;
>>> +   enc->enc_pic.pc.enc_crop_bottom_offset = 
>>> pic->pic_ctrl.enc_frame_crop_bottom_offset;
>>> +   }
>>> enc->enc_pic.pc.enc_num_mbs_per_slice = encNumMBsPerSlice;
>>> enc->enc_pic.pc.enc_b_pic_pattern = 
>>> MAX2(enc->base.max_references, 1) - 1;
>>> enc->enc_pic.pc.enc_number_of_reference_frames = 
>>> MIN2(enc->base.max_references, 2);
>>> diff --git a/src/gallium/include/pipe/p_video_state.h 
>>> b/src/gallium/include/pipe/p_video_state.h
>>> index 05855a36e23..1369f1a8ca6 100644
>>> --- a/src/gallium/include/pipe/p_video_state.h
>>> +++ b/src/gallium/include/pipe/p_video_state.h
>>> @@ -395,6 +395,11 @@ struct pipe_h264_enc_pic_control
>>> {
>>>unsigned enc_cabac_enable;
>>>unsigned enc_constraint_set_flags;
>>> +   unsigned enc_frame_cropping_flag;
>>> +   unsigned enc_frame_crop_left_offset;
>>> +   unsigned enc_frame_crop_right_offset;
>>> +   unsigned enc_frame_crop_top_offset;
>>> +   unsigned enc_frame_crop_bottom_offset;
>>> };
>>> 
>>> struct pipe_h264_enc_picture_desc
>>> diff --git a/src/gallium/state_trackers/va/picture_h264_enc.c 
>>> b/src/gallium/state_trackers/va/picture_h264_enc.c
>>> index abfd39633de..f46b3425566 100644
>>> --- a/src/gallium/state_trackers/va/picture_h264_enc.c
>>> +++ b/src/gallium/state_trackers/va/picture_h264_enc.c
>>> @@ -127,6 +127,14 @@ 
>>> vlVaHandleVAEncSequenceParameterBufferTypeH264(vlVaDriver *drv, vlVaContext 
>>> *con
>>>context-&g

Re: [Mesa-dev] [PATCH] gallium: Add support for frame_cropping_flag of VAEncSequenceParameterBufferH264

[Liu, Leo]

On 4/8/19 1:17 AM, Sahu, Satyajit wrote:
> From: suresh guttula 
>
> This patch will add support for frame_cropping when the input size is not
> matched with aligned size. Currently vaapi driver ignores frame cropping
> values provided by client. This change will update SPS nalu with proper
> cropping values.
>
> Signed-off-by: suresh guttula 
> Signed-off-by: Satyajit Sahu 
> ---
>   src/gallium/drivers/radeon/radeon_vce_52.c   | 8 ++--
>   src/gallium/include/pipe/p_video_state.h | 5 +
>   src/gallium/state_trackers/va/picture_h264_enc.c | 8 
>   3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> b/src/gallium/drivers/radeon/radeon_vce_52.c
> index fc7ddc62a90..593730756d5 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> @@ -81,8 +81,12 @@ static void get_pic_control_param(struct rvce_encoder 
> *enc, struct pipe_h264_enc
>   unsigned encNumMBsPerSlice;
>   encNumMBsPerSlice = align(enc->base.width, 16) / 16;
>   encNumMBsPerSlice *= align(enc->base.height, 16) / 16;
> - enc->enc_pic.pc.enc_crop_right_offset = (align(enc->base.width, 16) - 
> enc->base.width) >> 1;
> - enc->enc_pic.pc.enc_crop_bottom_offset = (align(enc->base.height, 16) - 
> enc->base.height) >> 1;

Shouldn't we need to keep this code path when the cropping info is not 
available, since VA spec says it's optional.

Regards,

Leo



> + if (pic->pic_ctrl.enc_frame_cropping_flag) {
> + enc->enc_pic.pc.enc_crop_left_offset = 
> pic->pic_ctrl.enc_frame_crop_left_offset;
> + enc->enc_pic.pc.enc_crop_right_offset = 
> pic->pic_ctrl.enc_frame_crop_right_offset;
> + enc->enc_pic.pc.enc_crop_top_offset = 
> pic->pic_ctrl.enc_frame_crop_top_offset;
> + enc->enc_pic.pc.enc_crop_bottom_offset = 
> pic->pic_ctrl.enc_frame_crop_bottom_offset;
> + }
>   enc->enc_pic.pc.enc_num_mbs_per_slice = encNumMBsPerSlice;
>   enc->enc_pic.pc.enc_b_pic_pattern = MAX2(enc->base.max_references, 1) - 
> 1;
>   enc->enc_pic.pc.enc_number_of_reference_frames = 
> MIN2(enc->base.max_references, 2);
> diff --git a/src/gallium/include/pipe/p_video_state.h 
> b/src/gallium/include/pipe/p_video_state.h
> index 05855a36e23..1369f1a8ca6 100644
> --- a/src/gallium/include/pipe/p_video_state.h
> +++ b/src/gallium/include/pipe/p_video_state.h
> @@ -395,6 +395,11 @@ struct pipe_h264_enc_pic_control
>   {
>  unsigned enc_cabac_enable;
>  unsigned enc_constraint_set_flags;
> +   unsigned enc_frame_cropping_flag;
> +   unsigned enc_frame_crop_left_offset;
> +   unsigned enc_frame_crop_right_offset;
> +   unsigned enc_frame_crop_top_offset;
> +   unsigned enc_frame_crop_bottom_offset;
>   };
>   
>   struct pipe_h264_enc_picture_desc
> diff --git a/src/gallium/state_trackers/va/picture_h264_enc.c 
> b/src/gallium/state_trackers/va/picture_h264_enc.c
> index abfd39633de..f46b3425566 100644
> --- a/src/gallium/state_trackers/va/picture_h264_enc.c
> +++ b/src/gallium/state_trackers/va/picture_h264_enc.c
> @@ -127,6 +127,14 @@ 
> vlVaHandleVAEncSequenceParameterBufferTypeH264(vlVaDriver *drv, vlVaContext 
> *con
>  context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
>  context->desc.h264enc.rate_ctrl.frame_rate_den = h264->num_units_in_tick;
>  context->desc.h264enc.pic_order_cnt_type = 
> h264->seq_fields.bits.pic_order_cnt_type;
> +
> +   if (h264->frame_cropping_flag) {
> +  context->desc.h264enc.pic_ctrl.enc_frame_cropping_flag = 
> h264->frame_cropping_flag;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_left_offset = 
> h264->frame_crop_left_offset;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_right_offset = 
> h264->frame_crop_right_offset;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_top_offset = 
> h264->frame_crop_top_offset;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_bottom_offset = 
> h264->frame_crop_bottom_offset;
> +   }
>  return VA_STATUS_SUCCESS;
>   }
>   
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeon/vcn/vp9: search the render target from the whole list

[Liu, Leo]

The number of render targets could be more than max of references,
so we search the full list of the render pictures for the current
render target index

https://bugs.freedesktop.org/show_bug.cgi?id=109648

Signed-off-by: Leo Liu 
Cc: 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index d165c55f835..688cef90103 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -491,7 +491,7 @@ static rvcn_dec_message_vp9_t get_vp9_msg(struct 
radeon_decoder *dec,
 
assert(dec->base.max_references + 1 <= 16);
 
-   for (i = 0 ; i < dec->base.max_references + 1 ; ++i) {
+   for (i = 0 ; i < 16 ; ++i) {
if (dec->render_pic_list[i] && dec->render_pic_list[i] == 
target) {
result.curr_pic_idx =

(uintptr_t)vl_video_buffer_get_associated_data(target, >base);
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeon/vcn: add H.264 constrained baseline support

[Liu, Leo]

VCN supports this profile as well as UVD, so add it

Signed-off-by: Leo Liu 
CC: 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index a4e6d9dc6b5..d165c55f835 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -64,6 +64,7 @@ static rvcn_dec_message_avc_t get_h264_msg(struct 
radeon_decoder *dec,
memset(, 0, sizeof(result));
switch (pic->base.profile) {
case PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE:
+   case PIPE_VIDEO_PROFILE_MPEG4_AVC_CONSTRAINED_BASELINE:
result.profile = RDECODE_H264_PROFILE_BASELINE;
break;
 
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Liu, Leo]

On 2019-03-20 1:56 p.m., Michel Dänzer wrote:
> On 2019-03-20 4:42 p.m., Liu, Leo wrote:
>> The wait here is unnecessary since we got a pool of back buffers,
>> and the wait for swap buffer will happen before the present pixmap,
>> at the same time the previous back buffer will be put back to pool
>> for reuse after the check for PresentIdleNotify event
>>
>> Signed-off-by: Leo Liu 
>>
>>   [...]
>>
>> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
>> *vscreen, void *drawable)
>>  if (!dri3_set_drawable(scrn, (Drawable)drawable))
>> return NULL;
>>   
>> -   if (scrn->flushed) {
>> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> - if (!dri3_wait_present_events(scrn))
>> -return NULL;
>> -   }
>> -   scrn->flushed = false;
>> -
>>  buffer = (scrn->is_pixmap) ?
>>   dri3_get_front_buffer(scrn) :
>>   dri3_get_back_buffer(scrn);
>>
> Hmm. Is the wait here not necessary before getting a pixmap's front
> buffer either though? Maybe wait only here for a pixmap, and only in
> vl_dri3_flush_frontbuffer for a window?
>
> Sorry I didn't realize this earlier.
>
The pixmap case is used by Totem player, or previous GLX case for MPV 
player, and the front buffer of the pixmap is a temporary buffer, and 
later as source for GL to present.

For pixmap case, there is no need to wait,  and the dri3 present wait 
before dri3_get_front_buffer() is not get called, because scrn->flushed 
will never be true, since our presentation flush code is not used by 
this case.

Thanks,

Leo

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Liu, Leo]

On 2019-03-21 4:15 a.m., Ernst Sjöstrand wrote:
> What's the expected change in behavior?

The change will make vl_dri3_screen_texture_from_drawable() call not to 
hold the pipeline. Because of the multiple of back buffers,  we can get 
the texture of the ongoing presented back buffer, and no need to wait 
the last presenting back buffer.

> Does it fix any bugs?

Yeah. With some of relatively slower hardware to play 4k@60fps, the 
presentation will miss the targeted time, and make the duration of the 
playback longer than the actual. esp. like VDPAU with scheduled 
presentation.


Thanks,

Leo


>
> Regards
> //Ernst
>
> Den ons 20 mars 2019 kl 16:42 skrev Liu, Leo :
>> The wait here is unnecessary since we got a pool of back buffers,
>> and the wait for swap buffer will happen before the present pixmap,
>> at the same time the previous back buffer will be put back to pool
>> for reuse after the check for PresentIdleNotify event
>>
>> Signed-off-by: Leo Liu 
>> ---
>>   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 18 +++---
>>   1 file changed, 3 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> index 152d28e59fc..1558d832555 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> @@ -88,7 +88,6 @@ struct vl_dri3_screen
>>  uint64_t send_sbc, recv_sbc;
>>  int64_t last_ust, ns_frame, last_msc, next_msc;
>>
>> -   bool flushed;
>>  bool is_different_gpu;
>>   };
>>
>> @@ -570,11 +569,9 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
>>  if (!back)
>>  return;
>>
>> -   if (scrn->flushed) {
>> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> - if (!dri3_wait_present_events(scrn))
>> -return;
>> -   }
>> +   while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> +  if (!dri3_wait_present_events(scrn))
>> + return;
>>
>>  rectangle.x = 0;
>>  rectangle.y = 0;
>> @@ -610,8 +607,6 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
>>
>>  xcb_flush(scrn->conn);
>>
>> -   scrn->flushed = true;
>> -
>>  return;
>>   }
>>
>> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
>> *vscreen, void *drawable)
>>  if (!dri3_set_drawable(scrn, (Drawable)drawable))
>> return NULL;
>>
>> -   if (scrn->flushed) {
>> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> - if (!dri3_wait_present_events(scrn))
>> -return NULL;
>> -   }
>> -   scrn->flushed = false;
>> -
>>  buffer = (scrn->is_pixmap) ?
>>   dri3_get_front_buffer(scrn) :
>>   dri3_get_back_buffer(scrn);
>> --
>> 2.17.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Liu, Leo]

The wait here is unnecessary since we got a pool of back buffers,
and the wait for swap buffer will happen before the present pixmap,
at the same time the previous back buffer will be put back to pool
for reuse after the check for PresentIdleNotify event

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 152d28e59fc..1558d832555 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -88,7 +88,6 @@ struct vl_dri3_screen
uint64_t send_sbc, recv_sbc;
int64_t last_ust, ns_frame, last_msc, next_msc;
 
-   bool flushed;
bool is_different_gpu;
 };
 
@@ -570,11 +569,9 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
if (!back)
return;
 
-   if (scrn->flushed) {
-  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
- if (!dri3_wait_present_events(scrn))
-return;
-   }
+   while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
+  if (!dri3_wait_present_events(scrn))
+ return;
 
rectangle.x = 0;
rectangle.y = 0;
@@ -610,8 +607,6 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
 
xcb_flush(scrn->conn);
 
-   scrn->flushed = true;
-
return;
 }
 
@@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
if (!dri3_set_drawable(scrn, (Drawable)drawable))
   return NULL;
 
-   if (scrn->flushed) {
-  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
- if (!dri3_wait_present_events(scrn))
-return NULL;
-   }
-   scrn->flushed = false;
-
buffer = (scrn->is_pixmap) ?
 dri3_get_front_buffer(scrn) :
 dri3_get_back_buffer(scrn);
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gallium/auxiliary/vl: Change weave compute shader implementation

[Liu, Leo]

On 3/12/19 11:12 AM, Zhu, James wrote:
> Use 2D_ARRARY instead of RECT to fetch texels for weave compute
> shader.
>
> Problem 2,3: Fixed interpolation issue with weave de-interlace
>
> Fixes: 9364d66cb7f7 (Add video compositor compute shader render)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109646

The series are:

Acked-by: Leo Liu 



> Signed-off-by: James Zhu 
> Tested-by: Bruno Milreu 
> ---
>   src/gallium/auxiliary/vl/vl_compositor_cs.c | 79 
> ++---
>   1 file changed, 62 insertions(+), 17 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c 
> b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> index de0a3c7..bad7d5f 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor_cs.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> @@ -113,15 +113,16 @@ const char *compute_shader_weave =
> "DCL SV[1], BLOCK_ID\n"
>   
> "DCL CONST[0..5]\n"
> -  "DCL SVIEW[0..2], RECT, FLOAT\n"
> +  "DCL SVIEW[0..2], 2D_ARRAY, FLOAT\n"
> "DCL SAMP[0..2]\n"
>   
> "DCL IMAGE[0], 2D, WR\n"
> -  "DCL TEMP[0..9]\n"
> +  "DCL TEMP[0..15]\n"
>   
> "IMM[0] UINT32 { 8, 8, 1, 0}\n"
> "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
> "IMM[2] UINT32 { 1, 2, 4, 0}\n"
> +  "IMM[3] FLT32 { 0.25, 0.5, 0.125, 0.125}\n"
>   
> "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
>   
> @@ -137,26 +138,70 @@ const char *compute_shader_weave =
>/* Translate */
>"UADD TEMP[2].xy, TEMP[2], -CONST[5].xyxy\n"
>   
> - /* Texture layer */
> - "UMOD TEMP[2].z, TEMP[2]., IMM[2].\n"
> - "UMOD TEMP[3].z, TEMP[2]., IMM[2].\n"
> - "USHR TEMP[3].z, TEMP[3]., IMM[2].\n"
> + /* Top Y */
> + "U2F TEMP[2], TEMP[2]\n"
> + "DIV TEMP[2].y, TEMP[2]., IMM[1].\n"
> + /* Down Y */
> + "MOV TEMP[12], TEMP[2]\n"
> +
> + /* Top UV */
> + "MOV TEMP[3], TEMP[2]\n"
> + "DIV TEMP[3].xy, TEMP[3], IMM[1].\n"
> + /* Down UV */
> + "MOV TEMP[13], TEMP[3]\n"
> +
> + /* Texture offset */
> + "ADD TEMP[2].x, TEMP[2]., IMM[3].\n"
> + "ADD TEMP[2].y, TEMP[2]., IMM[3].\n"
> + "ADD TEMP[12].x, TEMP[12]., IMM[3].\n"
> + "ADD TEMP[12].y, TEMP[12]., IMM[3].\n"
> +
> + "ADD TEMP[3].x, TEMP[3]., IMM[3].\n"
> + "ADD TEMP[3].y, TEMP[3]., IMM[3].\n"
> + "ADD TEMP[13].x, TEMP[13]., IMM[3].\n"
> + "ADD TEMP[13].y, TEMP[13]., IMM[3].\n"
>   
> - "USHR TEMP[2].y, TEMP[2], IMM[2].\n"
> - "USHR TEMP[3].xy, TEMP[2], IMM[2].\n"
> + /* Scale */
> + "DIV TEMP[2].xy, TEMP[2], CONST[3].zwzw\n"
> + "DIV TEMP[12].xy, TEMP[12], CONST[3].zwzw\n"
> + "DIV TEMP[3].xy, TEMP[3], CONST[3].zwzw\n"
> + "DIV TEMP[13].xy, TEMP[13], CONST[3].zwzw\n"
>   
> - "U2F TEMP[4], TEMP[2]\n"
> - "U2F TEMP[5], TEMP[3]\n"
> + /* Weave offset */
> + "ADD TEMP[2].y, TEMP[2]., IMM[3].\n"
> + "ADD TEMP[12].y, TEMP[12]., -IMM[3].\n"
> + "ADD TEMP[3].y, TEMP[3]., IMM[3].\n"
> + "ADD TEMP[13].y, TEMP[13]., -IMM[3].\n"
>   
> - /* Scale */
> - "DIV TEMP[4], TEMP[4], CONST[3].zwzw\n"
> - "DIV TEMP[5], TEMP[5], CONST[3].zwzw\n"
> + /* Texture layer */
> + "MOV TEMP[14].x, TEMP[2].\n"
> + "MOV TEMP[14].yz, TEMP[3].\n"
> + "ROUND TEMP[15], TEMP[14]\n"
> + "ADD TEMP[14], TEMP[14], -TEMP[15]\n"
> + "MOV TEMP[14], |TEMP[14]|\n"
> + "MUL TEMP[14], TEMP[14], IMM[1].\n"
> +
> + /* Normalize */
> + "DIV TEMP[2].xy, TEMP[2], CONST[5].zwzw\n"
> + "DIV TEMP[12].xy, TEMP[12], CONST[5].zwzw\n"
> + "DIV TEMP[15].xy, CONST[5].zwzw, IMM[1].\n"
> + "DIV TEMP[3].xy, TEMP[3], TEMP[15].xyxy\n"
> + "DIV TEMP[13].xy, TEMP[13], TEMP[15].xyxy\n"
>   
>/* Fetch texels */
> - "TEX_LZ TEMP[6].x, TEMP[4], SAMP[0], RECT\n"
> - "TEX_LZ TEMP[6].y, TEMP[5], SAMP[1], RECT\n"
> - "TEX_LZ TEMP[6].z, TEMP[5], SAMP[2], RECT\n"
> -
> + "MOV TEMP[2].z, IMM[1].\n"
> + "MOV TEMP[3].z, IMM[1].\n"
> + "TEX_LZ TEMP[10].x, TEMP[2], SAMP[0], 2D_ARRAY\n"
> + "TEX_LZ TEMP[10].y, TEMP[3], SAMP[1], 2D_ARRAY\n"
> + "TEX_LZ TEMP[10].z, TEMP[3], SAMP[2], 2D_ARRAY\n"
> +
> + "MOV TEMP[12].z, IMM[1].\n"
> + "MOV TEMP[13].z, IMM[1].\n"
> + "TEX_LZ TEMP[11].x, TEMP[12], SAMP[0], 2D_ARRAY\n"
> + "TEX_LZ TEMP[11].y, TEMP[13], SAMP[1], 2D_ARRAY\n"
> + "TEX_LZ TEMP[11].z, TEMP[13], SAMP[2], 2D_ARRAY\n"
> +
> + "LRP TEMP[6], TEMP[14], TEMP[11], TEMP[10]\n"
>"MOV TEMP[6].w, IMM[1].\n"
>   
>/* Color Space Conversion */

Re: [Mesa-dev] [PATCH 1/3] gallium: add pipe_grid_info::last_block

[Liu, Leo]

Series are:

Acked-by: Leo Liu 

On 2/27/19 5:19 PM, Marek Olšák wrote:
> From: Marek Olšák 
>
> The OpenMAX state tracker will use this.
>
> RadeonSI is adapted to use pipe_grid_info::last_block instead of its
> internal state.
> ---
>   src/gallium/auxiliary/util/u_screen.c |  3 +++
>   src/gallium/docs/source/screen.rst|  2 ++
>   src/gallium/drivers/radeonsi/si_compute.c |  2 +-
>   .../drivers/radeonsi/si_compute_blit.c| 18 +--
>   src/gallium/drivers/radeonsi/si_get.c |  1 +
>   src/gallium/drivers/radeonsi/si_pipe.h| 22 ---
>   src/gallium/include/pipe/p_defines.h  |  1 +
>   src/gallium/include/pipe/p_state.h| 21 ++
>   8 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_screen.c 
> b/src/gallium/auxiliary/util/u_screen.c
> index 50964f3b3ef..b902c083ad4 100644
> --- a/src/gallium/auxiliary/util/u_screen.c
> +++ b/src/gallium/auxiliary/util/u_screen.c
> @@ -334,14 +334,17 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
> *pscreen,
> return 2047;
>   
>  case PIPE_CAP_SURFACE_SAMPLE_COUNT:
> return 0;
>  case PIPE_CAP_DEST_SURFACE_SRGB_CONTROL:
> return 1;
>   
>  case PIPE_CAP_MAX_VARYINGS:
> return 8;
>   
> +   case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
> +  return 0;
> +
>  default:
> unreachable("bad PIPE_CAP_*");
>  }
>   }
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index 85ca5e1f5ce..60ba9bcbde0 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -485,20 +485,22 @@ The integer capabilities:
>   * ``PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND``: True if the driver needs blend 
> state to use zero/one instead of destination alpha for RGB/XRGB formats.
>   * ``PIPE_CAP_GLSL_TESS_LEVELS_AS_INPUTS``: True if the driver wants 
> TESSINNER and TESSOUTER to be inputs (rather than system values) for 
> tessellation evaluation shaders.
>   * ``PIPE_CAP_DEST_SURFACE_SRGB_CONTROL``: Indicates whether the drivers
> supports switching the format between sRGB and linear for a surface that 
> is
> used as destination in draw and blit calls.
>   * ``PIPE_CAP_NIR_COMPACT_ARRAYS``: True if the compiler backend supports 
> NIR's compact array feature, for all shader stages.
>   * ``PIPE_CAP_MAX_VARYINGS``: The maximum number of fragment shader
> varyings. This will generally correspond to
> ``PIPE_SHADER_CAP_MAX_INPUTS`` for the fragment shader, but in some
> cases may be a smaller number.
> +* ``PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK``: Whether 
> pipe_grid_info::last_block
> +  is implemented by the driver. See struct pipe_grid_info for more details.
>   
>   .. _pipe_capf:
>   
>   PIPE_CAPF_*
>   
>   
>   The floating-point capabilities are:
>   
>   * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line.
>   * ``PIPE_CAPF_MAX_LINE_WIDTH_AA``: The maximum width of a smoothed line.
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 87addd53976..6c2269d903a 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -797,21 +797,21 @@ static void si_emit_dispatch_packets(struct si_context 
> *sctx,
>   radeon_set_sh_reg(cs, R_00B854_COMPUTE_RESOURCE_LIMITS,
> compute_resource_limits);
>   
>   unsigned dispatch_initiator =
>   S_00B800_COMPUTE_SHADER_EN(1) |
>   S_00B800_FORCE_START_AT_000(1) |
>   /* If the KMD allows it (there is a KMD hw register for it),
>* allow launching waves out-of-order. (same as Vulkan) */
>   S_00B800_ORDER_MODE(sctx->chip_class >= CIK);
>   
> - uint *last_block = sctx->compute_last_block;
> + uint *last_block = info->last_block;
>   bool partial_block_en = last_block[0] || last_block[1] || last_block[2];
>   
>   radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
>   
>   if (partial_block_en) {
>   unsigned partial[3];
>   
>   /* If no partial_block, these should be an entire block size, 
> not 0. */
>   partial[0] = last_block[0] ? last_block[0] : info->block[0];
>   partial[1] = last_block[1] ? last_block[1] : info->block[1];
> diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c 
> b/src/gallium/drivers/radeonsi/si_compute_blit.c
> index f5e9c02dd10..a7453099ac6 100644
> --- a/src/gallium/drivers/radeonsi/si_compute_blit.c
> +++ b/src/gallium/drivers/radeonsi/si_compute_blit.c
> @@ -374,45 +374,42 @@ void si_compute_copy_image(struct si_context *sctx,
>   ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 2, image);
>   
>   struct pipe_grid_info info = {0};
>   
>   if (dst->target == PIPE_TEXTURE_1D_ARRAY && 

Re: [Mesa-dev] [PATCH v3] gallium/auxiliary/vl: Fix transparent issue on compute shader with rgba

[Liu, Leo]

Reviewed-by: Leo Liu 

On 2019-02-15 4:19 p.m., Zhu, James wrote:
> Fixes: 9364d66cb7f7 (Add video compositor compute shader render)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109646
> Problem 1,4: they are caused by imcomplete blend comute shader
> implementation. So Reverts rgba back to frament shader.
>
> Signed-off-by: James Zhu 
> ---
>   src/gallium/auxiliary/vl/vl_compositor.c | 17 +++--
>   1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
> b/src/gallium/auxiliary/vl/vl_compositor.c
> index 8731ad9..a8f3620 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
> @@ -100,12 +100,12 @@ init_shaders(struct vl_compositor *c)
>debug_printf("Unable to create YCbCr-to-RGB weave fragment 
> shader.\n");
>return false;
> }
> +   }
>   
> -  c->fs_rgba = create_frag_shader_rgba(c);
> -  if (!c->fs_rgba) {
> - debug_printf("Unable to create RGB-to-RGB fragment shader.\n");
> - return false;
> -  }
> +   c->fs_rgba = create_frag_shader_rgba(c);
> +   if (!c->fs_rgba) {
> +  debug_printf("Unable to create RGB-to-RGB fragment shader.\n");
> +  return false;
>  }
>   
>  return true;
> @@ -132,8 +132,8 @@ static void cleanup_shaders(struct vl_compositor *c)
>  } else {
> c->pipe->delete_fs_state(c->pipe, c->fs_video_buffer);
> c->pipe->delete_fs_state(c->pipe, c->fs_weave_rgb);
> -  c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
>  }
> +   c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
>   }
>   
>   static bool
> @@ -642,10 +642,7 @@ vl_compositor_set_rgba_layer(struct vl_compositor_state 
> *s,
>  assert(layer < VL_COMPOSITOR_MAX_LAYERS);
>   
>  s->used_layers |= 1 << layer;
> -   if (c->pipe_compute_supported)
> -  s->layers[layer].cs = c->cs_rgba;
> -   else
> -  s->layers[layer].fs = c->fs_rgba;
> +   s->layers[layer].fs = c->fs_rgba;
>  s->layers[layer].samplers[0] = c->sampler_linear;
>  s->layers[layer].samplers[1] = NULL;
>  s->layers[layer].samplers[2] = NULL;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/auxiliary/vl: Revert rgba back to frament shader

[Liu, Leo]

On 2/15/19 3:42 PM, Zhu, James wrote:
> Bugzilla Bug 109646 - New video compositor compute shader render glitches mpv
> Problem 1,4: they are caused by imcomplete blend compute shader
> implementation. So Revert rgba back to frament shader.

Please refer to other commit message to put Bugzilla link here, also 
refer to others to add "FIXES:"

Leo


>
> Signed-off-by: James Zhu 
> ---
>   src/gallium/auxiliary/vl/vl_compositor.c | 17 +++--
>   1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
> b/src/gallium/auxiliary/vl/vl_compositor.c
> index 8731ad9..a8f3620 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
> @@ -100,12 +100,12 @@ init_shaders(struct vl_compositor *c)
>debug_printf("Unable to create YCbCr-to-RGB weave fragment 
> shader.\n");
>return false;
> }
> +   }
>   
> -  c->fs_rgba = create_frag_shader_rgba(c);
> -  if (!c->fs_rgba) {
> - debug_printf("Unable to create RGB-to-RGB fragment shader.\n");
> - return false;
> -  }
> +   c->fs_rgba = create_frag_shader_rgba(c);
> +   if (!c->fs_rgba) {
> +  debug_printf("Unable to create RGB-to-RGB fragment shader.\n");
> +  return false;
>  }
>   
>  return true;
> @@ -132,8 +132,8 @@ static void cleanup_shaders(struct vl_compositor *c)
>  } else {
> c->pipe->delete_fs_state(c->pipe, c->fs_video_buffer);
> c->pipe->delete_fs_state(c->pipe, c->fs_weave_rgb);
> -  c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
>  }
> +   c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
>   }
>   
>   static bool
> @@ -642,10 +642,7 @@ vl_compositor_set_rgba_layer(struct vl_compositor_state 
> *s,
>  assert(layer < VL_COMPOSITOR_MAX_LAYERS);
>   
>  s->used_layers |= 1 << layer;
> -   if (c->pipe_compute_supported)
> -  s->layers[layer].cs = c->cs_rgba;
> -   else
> -  s->layers[layer].fs = c->fs_rgba;
> +   s->layers[layer].fs = c->fs_rgba;
>  s->layers[layer].samplers[0] = c->sampler_linear;
>  s->layers[layer].samplers[1] = NULL;
>  s->layers[layer].samplers[2] = NULL;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 5/5] gallium/auxiliary/vl: Add video compositor compute shader render

[Liu, Leo]

On 2/12/19 10:35 AM, Zhu, James wrote:
> Add compute shader initilization, assign and cleanup in vl_compositor API.
> Set video compositor compute shader render as default when pipe support it.
>
> Signed-off-by: James Zhu 
> Reviewed-by: Christian König 
> ---
>   src/gallium/auxiliary/vl/vl_compositor.c | 108 
> +++
>   src/gallium/auxiliary/vl/vl_compositor.h |   3 +
>   2 files changed, 83 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
> b/src/gallium/auxiliary/vl/vl_compositor.c
> index 4509913..cd404b9 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
> @@ -28,6 +28,9 @@
>   #include "util/u_sampler.h"
>   
>   #include "vl_compositor_gfx.h"
> +#include "vl_compositor_cs.h"
> +
> +static int pip_compute_supported = 0;

Please rename it to "pipe_xxx" and put it to vl_compositor structure.

Leo


>   
>   static bool
>   init_shaders(struct vl_compositor *c)
> @@ -40,18 +43,6 @@ init_shaders(struct vl_compositor *c)
> return false;
>  }
>   
> -   c->fs_video_buffer = create_frag_shader_video_buffer(c);
> -   if (!c->fs_video_buffer) {
> -  debug_printf("Unable to create YCbCr-to-RGB fragment shader.\n");
> -  return false;
> -   }
> -
> -   c->fs_weave_rgb = create_frag_shader_weave_rgb(c);
> -   if (!c->fs_weave_rgb) {
> -  debug_printf("Unable to create YCbCr-to-RGB weave fragment shader.\n");
> -  return false;
> -   }
> -
>  c->fs_yuv.weave.y = create_frag_shader_deint_yuv(c, true, true);
>  c->fs_yuv.weave.uv = create_frag_shader_deint_yuv(c, false, true);
>  c->fs_yuv.bob.y = create_frag_shader_deint_yuv(c, true, false);
> @@ -74,12 +65,6 @@ init_shaders(struct vl_compositor *c)
> return false;
>  }
>   
> -   c->fs_rgba = create_frag_shader_rgba(c);
> -   if (!c->fs_rgba) {
> -  debug_printf("Unable to create RGB-to-RGB fragment shader.\n");
> -  return false;
> -   }
> -
>  c->fs_rgb_yuv.y = create_frag_shader_rgb_yuv(c, true);
>  c->fs_rgb_yuv.uv = create_frag_shader_rgb_yuv(c, false);
>  if (!c->fs_rgb_yuv.y || !c->fs_rgb_yuv.uv) {
> @@ -87,6 +72,44 @@ init_shaders(struct vl_compositor *c)
> return false;
>  }
>   
> +   if (pip_compute_supported) {
> +  c->cs_video_buffer = vl_compositor_cs_create_shader(c, 
> compute_shader_video_buffer);
> +  if (!c->cs_video_buffer) {
> + debug_printf("Unable to create video_buffer compute shader.\n");
> + return false;
> +  }
> +
> +  c->cs_weave_rgb = vl_compositor_cs_create_shader(c, 
> compute_shader_weave);
> +  if (!c->cs_weave_rgb) {
> + debug_printf("Unable to create weave_rgb compute shader.\n");
> + return false;
> +  }
> +
> +  c->cs_rgba = vl_compositor_cs_create_shader(c, compute_shader_rgba);
> +  if (!c->cs_rgba) {
> + debug_printf("Unable to create RGB-to-RGB compute shader.\n");
> + return false;
> +  }
> +   } else {
> +  c->fs_video_buffer = create_frag_shader_video_buffer(c);
> +  if (!c->fs_video_buffer) {
> + debug_printf("Unable to create YCbCr-to-RGB fragment shader.\n");
> + return false;
> +  }
> +
> +  c->fs_weave_rgb = create_frag_shader_weave_rgb(c);
> +  if (!c->fs_weave_rgb) {
> + debug_printf("Unable to create YCbCr-to-RGB weave fragment 
> shader.\n");
> + return false;
> +  }
> +
> +  c->fs_rgba = create_frag_shader_rgba(c);
> +  if (!c->fs_rgba) {
> + debug_printf("Unable to create RGB-to-RGB fragment shader.\n");
> + return false;
> +  }
> +   }
> +
>  return true;
>   }
>   
> @@ -95,17 +118,24 @@ static void cleanup_shaders(struct vl_compositor *c)
>  assert(c);
>   
>  c->pipe->delete_vs_state(c->pipe, c->vs);
> -   c->pipe->delete_fs_state(c->pipe, c->fs_video_buffer);
> -   c->pipe->delete_fs_state(c->pipe, c->fs_weave_rgb);
>  c->pipe->delete_fs_state(c->pipe, c->fs_yuv.weave.y);
>  c->pipe->delete_fs_state(c->pipe, c->fs_yuv.weave.uv);
>  c->pipe->delete_fs_state(c->pipe, c->fs_yuv.bob.y);
>  c->pipe->delete_fs_state(c->pipe, c->fs_yuv.bob.uv);
>  c->pipe->delete_fs_state(c->pipe, c->fs_palette.yuv);
>  c->pipe->delete_fs_state(c->pipe, c->fs_palette.rgb);
> -   c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
>  c->pipe->delete_fs_state(c->pipe, c->fs_rgb_yuv.y);
>  c->pipe->delete_fs_state(c->pipe, c->fs_rgb_yuv.uv);
> +
> +   if (pip_compute_supported) {
> +  c->pipe->delete_compute_state(c->pipe, c->cs_video_buffer);
> +  c->pipe->delete_compute_state(c->pipe, c->cs_weave_rgb);
> +  c->pipe->delete_compute_state(c->pipe, c->cs_rgba);
> +   } else {
> +  c->pipe->delete_fs_state(c->pipe, c->fs_video_buffer);
> +  c->pipe->delete_fs_state(c->pipe, c->fs_weave_rgb);
> +  c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
> +   }
>   }
>   
>   static bool
> @@ -409,6 +439,7 @@ 

[Mesa-dev] [PATCH 1/2] st/va: fix the incorrect max profiles report

[Liu, Leo]

Add "PIPE_VIDEO_PROFILE_MAX" to enum, so it will make sure here will
be correct when adding more profiles in the future.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109107

Signed-off-by: Leo Liu 
Cc: 19.0 
---
 src/gallium/include/pipe/p_video_enums.h | 3 ++-
 src/gallium/state_trackers/va/context.c  | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_video_enums.h 
b/src/gallium/include/pipe/p_video_enums.h
index b5b8b062285..adbe7858d0f 100644
--- a/src/gallium/include/pipe/p_video_enums.h
+++ b/src/gallium/include/pipe/p_video_enums.h
@@ -70,7 +70,8 @@ enum pipe_video_profile
PIPE_VIDEO_PROFILE_HEVC_MAIN_444,
PIPE_VIDEO_PROFILE_JPEG_BASELINE,
PIPE_VIDEO_PROFILE_VP9_PROFILE0,
-   PIPE_VIDEO_PROFILE_VP9_PROFILE2
+   PIPE_VIDEO_PROFILE_VP9_PROFILE2,
+   PIPE_VIDEO_PROFILE_MAX
 };
 
 /* Video caps, can be different for each codec/profile */
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 14e904ee490..47a5e7be230 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -175,7 +175,7 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
ctx->version_minor = 1;
*ctx->vtable = vtable;
*ctx->vtable_vpp = vtable_vpp;
-   ctx->max_profiles = PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH - 
PIPE_VIDEO_PROFILE_UNKNOWN;
+   ctx->max_profiles = PIPE_VIDEO_PROFILE_MAX - PIPE_VIDEO_PROFILE_UNKNOWN - 1;
ctx->max_entrypoints = 2;
ctx->max_attributes = 1;
ctx->max_image_formats = VL_VA_MAX_IMAGE_FORMATS;
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] st/va/vp9: set max reference as default of VP9 reference number

[Liu, Leo]

If there is no information about number of render targets

Signed-off-by: Leo Liu 
Cc: 19.0 
---
 src/gallium/state_trackers/va/picture_vp9.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_vp9.c 
b/src/gallium/state_trackers/va/picture_vp9.c
index c1ca54cd008..b5aca9a513c 100644
--- a/src/gallium/state_trackers/va/picture_vp9.c
+++ b/src/gallium/state_trackers/va/picture_vp9.c
@@ -28,6 +28,8 @@
 #include "vl/vl_vlc.h"
 #include "va_private.h"
 
+#define NUM_VP9_REFS 8
+
 void vlVaHandlePictureParameterBufferVP9(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
 {
VADecPictureParameterBufferVP9 *vp9 = buf->data;
@@ -79,8 +81,11 @@ void vlVaHandlePictureParameterBufferVP9(vlVaDriver *drv, 
vlVaContext *context,
 
context->desc.vp9.picture_parameter.bit_depth = vp9->bit_depth;
 
-   for (i = 0 ; i < 8 ; i++)
+   for (i = 0 ; i < NUM_VP9_REFS ; i++)
   vlVaGetReferenceFrame(drv, vp9->reference_frames[i], 
>desc.vp9.ref[i]);
+
+   if (!context->decoder && !context->templat.max_references)
+  context->templat.max_references = NUM_VP9_REFS;
 }
 
 void vlVaHandleSliceParameterBufferVP9(vlVaContext *context, vlVaBuffer *buf)
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va:Add support for indirect manner by returning VA_STATUS_ERROR_OPERATION_FAILED

[Liu, Leo]

VA spec regarding VAImage:

This operation is only possible on implementations with
  * direct rendering capabilities and internal surface formats that can be
  * represented with a VAImage. When the operation is not possible this 
interface
  * will return VA_STATUS_ERROR_OPERATION_FAILED. Clients should then 
fall back
  * to using vaCreateImage + vaPutImage to accomplish the same task in an
  * indirect manner.

This is similar to your commit message, so please add it something like 
"based on VA spec..." to your commit message.

With that fixed, the patch is:

Reviewed-by: Leo Liu 

On 2019-02-07 5:09 a.m., Guttula, Suresh wrote:
> This patch will return VA_STATUS_ERROR_OPERATION_FAILED incase vaDeriveImage()
> failed for non-contiguous planes.This error string is required to support
> indirect manner i.e. vaCreateImage()+vaPutImage() incase vaDeriveImage()
> failed with VA_STATUS_ERROR_OPERATION_FAILED.
>
> Signed-off-by: suresh guttula 
> ---
>   src/gallium/state_trackers/va/image.c | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/image.c 
> b/src/gallium/state_trackers/va/image.c
> index 807fc83..f7e0db0 100644
> --- a/src/gallium/state_trackers/va/image.c
> +++ b/src/gallium/state_trackers/va/image.c
> @@ -212,9 +212,12 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID 
> surface, VAImage *image)
>   
>  surf = handle_table_get(drv->htab, surface);
>   
> -   if (!surf || !surf->buffer || surf->buffer->interlaced)
> +   if (!surf || !surf->buffer)
> return VA_STATUS_ERROR_INVALID_SURFACE;
>   
> +   if (surf->buffer->interlaced)
> + return VA_STATUS_ERROR_OPERATION_FAILED;
> +
>  surfaces = surf->buffer->get_surfaces(surf->buffer);
>  if (!surfaces || !surfaces[0]->texture)
> return VA_STATUS_ERROR_ALLOCATION_FAILED;
> @@ -261,7 +264,7 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID 
> surface, VAImage *image)
>  default:
> /* VaDeriveImage is designed for contiguous planes. */
> FREE(img);
> -  return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
> +  return VA_STATUS_ERROR_OPERATION_FAILED;
>  }
>   
>  img_buf = CALLOC(1, sizeof(vlVaBuffer));
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Bug 109107] gallium/st/va: change va max_profiles when using Radeon VCN Hardware

[Liu, Leo]

I'll take a look and update Bugzilla accordingly.

Cheers,

Leo

On 2/1/19 3:59 PM, Mihai wrote:
Hi,

I am not sure if this is related with regards to what is causing hardware 
accelerated decoding on my Raven laptop not to work.

Fedora repos:
che-mesa, rpmfusion, fedora-rawhide-kernel-nodebug
Mesa-git installed is build from: sha 9279a28

chromium-vaapi package from rpmfusion repo, started with the following command:
chromium-vaapi --enable-plugins --enable-extensions --enable-user-scripts 
--enable-printing --enable-accelerated-video --enable-native-gpu-memory-buffers 
--enable-accelerated-mjpeg-decode -nable-gpu-rasterization 
--disable-gpu-driver-bug-workarounds --enable-sync --flag-switches-begin 
--enable-accelerated-mjpeg-decode --enable-accelerated-video --enable-zero-copy 
--ignore-gpu-blacklist --enable-features=VizDisplayCompositor 
--flag-switches-end


chrome://gpu/

Native GpuMemoryBuffers: Hardware accelerated
Hardware Protected Video Decode: Hardware accelerated
Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
-

chrome://media-internals/

video_codec_name vp9
video_dds false
video_decoder VpxVideoDecoder

so, as the VpxVideoDecoder, it means the gpu hardware acceleration is not 
working.

Log:
[18642:18642:0201/223152.683850:ERROR:vaapi_wrapper.cc(568)] : 
vaQueryConfigProfiles returned: 14
[18642:18642:0201/223152.683943:ERROR:vaapi_wrapper.cc(568)] : 
vaQueryConfigProfiles returned: 14
[18642:18642:0201/223152.771320:ERROR:sandbox_linux.cc(364)] : 
InitializeSandbox() called with multiple threads in process gpu-process.
[18642:18642:0201/224233.934476:ERROR:buffer_manager.cc(491)] : 
[GroupMarkerNotSet(crbug.com/242999)!:C0B874BB3939]GL
 ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command

Specs:
I am using HP 15-cp0001na laptop with Ryzen 2700u:

inxi -G
Graphics:  Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega Mobile 
Series] driver: amdgpu v: kernel
Display: x11 server: Fedora Project X.org 1.20.3 driver: amdgpu tty: N/A
OpenGL: renderer: AMD RAVEN (DRM 3.27.0 5.0.0-0.rc4.git0.1.fc30.x86_64 LLVM 
9.0.0) v: 4.5 Mesa 19.1.0-devel
--
dmesg
[3.119158] amdgpu :04:00.0: ring vcn_dec uses VM inv eng 1 on hub 1
[3.119166] amdgpu :04:00.0: ring vcn_enc0 uses VM inv eng 4 on hub 1
[3.119170] amdgpu :04:00.0: ring vcn_enc1 uses VM inv eng 5 on hub 1
[3.119173] amdgpu :04:00.0: ring vcn_jpeg uses VM inv eng 6 on hub 1

vainfo

libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.3 (libva 2.3.0)
vainfo: Driver version: Mesa Gallium driver 19.1.0-devel for AMD RAVEN (DRM 
3.27.0, 5.0.0-0.rc4.git0.1.fc30.x86_64, LLVM 9.0.0)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileVP9Profile0: VAEntrypointVLD
  VAProfileVP9Profile2: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

Possibly related: 
https://sea-region.github.com/saiarcot895/chromium-ubuntu-build/issues/39

Thanks in advance!



On Fri, Dec 21, 2018 at 3:19 AM 
mailto:bugzilla-dae...@freedesktop.org>> wrote:

Comment # 1 on bug 
109107 from 
zhoulei

More details:

In function VASupportedProfiles::GetSupportedVAProfiles,
https://github.com/chromium/chromium/blob/master/media/gpu/vaapi/vaapi_wrapper.cc#L571

const int max_profiles = vaMaxNumProfiles(va_display_);
vaMaxNumProfiles will return (PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH -
PIPE_VIDEO_PROFILE_UNKNOWN) in mesa.

 int num_supported_profiles;
  VAStatus va_res = vaQueryConfigProfiles(va_display_, _profiles[0],
  _supported_profiles);
  VA_SUCCESS_OR_RETURN(va_res, "vaQueryConfigProfiles failed", 

Re: [Mesa-dev] [PATCH 6/6] gallium\auxiliary\vl: Add video compute shader render

[Liu, Leo]

On 2/1/19 11:38 AM, Christian König wrote:
> Am 01.02.19 um 17:28 schrieb Zhu, James:
>> Add video compute shader render. export CS_COMPOSITOR_RENDER=true
>> to enable video compute shader render.
>
> Ok that actually makes more sense, but I would either put everything 
> into one file or cleanly separate between gfx and compute implementation.

Agreed.

Leo


>
> Christian.
>
>>
>> Signed-off-by: James Zhu 
>> ---
>>   src/gallium/auxiliary/vl/vl_compositor.c | 19 +--
>>   1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
>> b/src/gallium/auxiliary/vl/vl_compositor.c
>> index 7ee8402..66a8fc9 100644
>> --- a/src/gallium/auxiliary/vl/vl_compositor.c
>> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
>> @@ -1376,8 +1376,8 @@ vl_compositor_convert_rgb_to_yuv(struct 
>> vl_compositor_state *s,
>>  s->pipe->flush(s->pipe, NULL, 0);
>>   }
>>   -void
>> -vl_compositor_render(struct vl_compositor_state *s,
>> +static void
>> +vl_compositor_gfx_render(struct vl_compositor_state *s,
>>    struct vl_compositor   *c,
>>    struct pipe_surface    *dst_surface,
>>    struct u_rect  *dirty_area,
>> @@ -1419,6 +1419,21 @@ vl_compositor_render(struct 
>> vl_compositor_state *s,
>>  draw_layers(c, s, dirty_area);
>>   }
>>   +void
>> +vl_compositor_render(struct vl_compositor_state *s,
>> + struct vl_compositor   *c,
>> + struct pipe_surface    *dst_surface,
>> + struct u_rect  *dirty_area,
>> + bool    clear_dirty)
>> +{
>> +   assert(s);
>> +
>> +   if (cs_compositor_render_enable && s->layers->cs)
>> +  vl_compositor_cs_render(s, c, dst_surface, dirty_area, 
>> clear_dirty);
>> +   else
>> +  vl_compositor_gfx_render(s, c, dst_surface, dirty_area, 
>> clear_dirty);
>> +}
>> +
>>   bool
>>   vl_compositor_init(struct vl_compositor *c, struct pipe_context *pipe)
>>   {
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

[Liu, Leo]

On 2/1/19 11:28 AM, Zhu, James wrote:
> Add compute shader to support video compositor render.
>
> Signed-off-by: James Zhu 
> ---
>   src/gallium/auxiliary/Makefile.sources  |   2 +
>   src/gallium/auxiliary/meson.build   |   2 +
>   src/gallium/auxiliary/vl/vl_compositor_cs.c | 414 
> 
>   src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
>   4 files changed, 474 insertions(+)
>   create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
>   create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h
>
> diff --git a/src/gallium/auxiliary/Makefile.sources 
> b/src/gallium/auxiliary/Makefile.sources
> index 50e8808..df000f6 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -348,6 +348,8 @@ VL_SOURCES := \
>   vl/vl_bicubic_filter.h \
>   vl/vl_compositor.c \
>   vl/vl_compositor.h \
> + vl/vl_compositor_cs.c \
> + vl/vl_compositor_cs.h \
>   vl/vl_csc.c \
>   vl/vl_csc.h \
>   vl/vl_decoder.c \
> diff --git a/src/gallium/auxiliary/meson.build 
> b/src/gallium/auxiliary/meson.build
> index 57f7e69..74e4b48 100644
> --- a/src/gallium/auxiliary/meson.build
> +++ b/src/gallium/auxiliary/meson.build
> @@ -445,6 +445,8 @@ files_libgalliumvl = files(
> 'vl/vl_bicubic_filter.h',
> 'vl/vl_compositor.c',
> 'vl/vl_compositor.h',
> +  'vl/vl_compositor_cs.c',
> +  'vl/vl_compositor_cs.h',
> 'vl/vl_csc.c',
> 'vl/vl_csc.h',
> 'vl/vl_decoder.c',
> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c 
> b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> new file mode 100644
> index 000..3cd1a76
> --- /dev/null
> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> @@ -0,0 +1,414 @@
> +/**
> + *
> + * Copyright 2019 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: James Zhu 
> + *
> + **/
> +
> +#include 
> +
> +#include "tgsi/tgsi_text.h"
> +#include "vl_compositor_cs.h"
> +
> +struct cs_viewport {
> +   float scale_x;
> +   float scale_y;
> +   int translate_x;
> +   int translate_y;
> +   struct u_rect area;
> +};
> +
> +char *compute_shader_video_buffer =
> +  "COMP\n"
> +  "PROPERTY CS_FIXED_BLOCK_WIDTH 8\n"
> +  "PROPERTY CS_FIXED_BLOCK_HEIGHT 8\n"
> +  "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
> +
> +  "DCL SV[0], THREAD_ID\n"
> +  "DCL SV[1], BLOCK_ID\n"
> +
> +  "DCL CONST[0..5]\n"
> +  "DCL SVIEW[0..2], RECT, FLOAT\n"
> +  "DCL SAMP[0..2]\n"
> +
> +  "DCL IMAGE[0], 2D, WR\n"
> +  "DCL TEMP[0..7]\n"
> +
> +  "IMM[0] UINT32 { 8, 8, 1, 0}\n"
> +  "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
> +
> +  "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
> +
> +  /* Drawn area check */
> +  "USGE TEMP[1].xy, TEMP[0].xyxy, CONST[4].xyxy\n"
> +  "USLT TEMP[1].zw, TEMP[0].xyxy, CONST[4].zwzw\n"
> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
> +
> +  "UIF TEMP[1]\n"
> + /* Translate */
> + "UADD TEMP[2].xy, TEMP[0], -CONST[5].xyxy\n"
> + "U2F TEMP[2], TEMP[2]\n"
> + "DIV TEMP[3], TEMP[2], IMM[1].\n"
> +
> + /* Scale */
> + "DIV TEMP[2], TEMP[2], CONST[3].zwzw\n"
> + "DIV TEMP[3], TEMP[3], CONST[3].zwzw\n"
> +
> + /* Fetch texels */
> + "TEX_LZ TEMP[4].x, TEMP[2], SAMP[0], RECT\n"
> + "TEX_LZ TEMP[4].y, TEMP[3], SAMP[1], RECT\n"
> + "TEX_LZ TEMP[4].z, TEMP[3], SAMP[2], RECT\n"
> +
> + "MOV TEMP[4].w, IMM[1].\n"
> +
> + /* Color Space Conversion */
> + "DP4 

Re: [Mesa-dev] st/va: Return correct status from vlVaQuerySurfaceStatus

[Liu, Leo]

Please add some commit messages. With that, the patch is

Reviewed-by: Leo Liu 

On 1/3/19 5:20 AM, Das, Indrajit-kumar wrote:
> From: Indrajit Das 
> Date: Thu, 3 Jan 2019 14:36:33 +0530
> Subject: [PATCH] st/va: Return correct status from vlVaQuerySurfaceStatus
>
> Signed-off-by: Indrajit Das 
> ---
>   src/gallium/state_trackers/va/surface.c | 31 +
>   1 file changed, 31 insertions(+)
>
> diff --git a/src/gallium/state_trackers/va/surface.c 
> b/src/gallium/state_trackers/va/surface.c
> index cc26efe..e7ed64b 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -146,9 +146,40 @@ vlVaSyncSurface(VADriverContextP ctx, VASurfaceID 
> render_target)
>   VAStatus
>   vlVaQuerySurfaceStatus(VADriverContextP ctx, VASurfaceID render_target, 
> VASurfaceStatus *status)
>   {
> +   vlVaDriver *drv;
> +   vlVaSurface *surf;
> +   vlVaContext *context;
> +
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> +   drv = VL_VA_DRIVER(ctx);
> +   if (!drv)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> +   mtx_lock(>mutex);
> +
> +   surf = handle_table_get(drv->htab, render_target);
> +   if (!surf || !surf->buffer) {
> +  mtx_unlock(>mutex);
> +  return VA_STATUS_ERROR_INVALID_SURFACE;
> +   }
> +
> +   context = handle_table_get(drv->htab, surf->ctx);
> +   if (!context) {
> +  mtx_unlock(>mutex);
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +   }
> +
> +   if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
> +  if(surf->feedback == NULL)
> + *status=VASurfaceReady;
> +  else
> + *status=VASurfaceRendering;
> +   }
> +
> +   mtx_unlock(>mutex);
> +
>  return VA_STATUS_SUCCESS;
>   }
>   
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pci_ids: add new VegaM pci id

[Liu, Leo]

Reviewed-by: Leo Liu 

On 12/21/18 11:36 AM, Alex Deucher wrote:
> Ping?
>
> On Thu, Dec 20, 2018 at 10:13 AM Alex Deucher  wrote:
>> Signed-off-by: Alex Deucher 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>   include/pci_ids/radeonsi_pci_ids.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
>> b/include/pci_ids/radeonsi_pci_ids.h
>> index a2bc9213207..75ac7761bb4 100644
>> --- a/include/pci_ids/radeonsi_pci_ids.h
>> +++ b/include/pci_ids/radeonsi_pci_ids.h
>> @@ -219,6 +219,7 @@ CHIPSET(0x699F, POLARIS12)
>>
>>   CHIPSET(0x694C, VEGAM)
>>   CHIPSET(0x694E, VEGAM)
>> +CHIPSET(0x694F, VEGAM)
>>
>>   CHIPSET(0x6860, VEGA10)
>>   CHIPSET(0x6861, VEGA10)
>> --
>> 2.13.6
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix video APIs on Raven2

[Liu, Leo]

Reviewed-by: Leo Liu 

On 11/13/18 6:51 PM, Marek Olšák wrote:
> From: Marek Olšák 
>
> This was missed when I added the new enum.
>
> Cc: 18.3 
> ---
>   src/gallium/drivers/radeonsi/si_get.c | 9 ++---
>   src/gallium/drivers/radeonsi/si_uvd.c | 3 ++-
>   2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index b440230d227..91f38329d59 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -573,24 +573,26 @@ static int si_get_video_param(struct pipe_screen 
> *screen,
> enum pipe_video_cap param)
>   {
>   struct si_screen *sscreen = (struct si_screen *)screen;
>   enum pipe_video_format codec = u_reduce_video_profile(profile);
>   
>   if (entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
>   switch (param) {
>   case PIPE_VIDEO_CAP_SUPPORTED:
>   return (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC &&
>   (si_vce_is_fw_version_supported(sscreen) ||
> - sscreen->info.family == CHIP_RAVEN)) ||
> +  sscreen->info.family == CHIP_RAVEN ||
> +  sscreen->info.family == CHIP_RAVEN2)) ||
>   (profile == PIPE_VIDEO_PROFILE_HEVC_MAIN &&
>   (sscreen->info.family == CHIP_RAVEN ||
> - si_radeon_uvd_enc_supported(sscreen)));
> +  sscreen->info.family == CHIP_RAVEN2 ||
> +  si_radeon_uvd_enc_supported(sscreen)));
>   case PIPE_VIDEO_CAP_NPOT_TEXTURES:
>   return 1;
>   case PIPE_VIDEO_CAP_MAX_WIDTH:
>   return (sscreen->info.family < CHIP_TONGA) ? 2048 : 
> 4096;
>   case PIPE_VIDEO_CAP_MAX_HEIGHT:
>   return (sscreen->info.family < CHIP_TONGA) ? 1152 : 
> 2304;
>   case PIPE_VIDEO_CAP_PREFERED_FORMAT:
>   return PIPE_FORMAT_NV12;
>   case PIPE_VIDEO_CAP_PREFERS_INTERLACED:
>   return false;
> @@ -624,21 +626,22 @@ static int si_get_video_param(struct pipe_screen 
> *screen,
>   return true;
>   case PIPE_VIDEO_FORMAT_HEVC:
>   /* Carrizo only supports HEVC Main */
>   if (sscreen->info.family >= CHIP_STONEY)
>   return (profile == PIPE_VIDEO_PROFILE_HEVC_MAIN 
> ||
>   profile == 
> PIPE_VIDEO_PROFILE_HEVC_MAIN_10);
>   else if (sscreen->info.family >= CHIP_CARRIZO)
>   return profile == PIPE_VIDEO_PROFILE_HEVC_MAIN;
>   return false;
>   case PIPE_VIDEO_FORMAT_JPEG:
> - if (sscreen->info.family == CHIP_RAVEN)
> + if (sscreen->info.family == CHIP_RAVEN ||
> + sscreen->info.family == CHIP_RAVEN2)
>   return true;
>   if (sscreen->info.family < CHIP_CARRIZO || 
> sscreen->info.family >= CHIP_VEGA10)
>   return false;
>   if (!(sscreen->info.drm_major == 3 && 
> sscreen->info.drm_minor >= 19)) {
>   RVID_ERR("No MJPEG support for the kernel 
> version\n");
>   return false;
>   }
>   return true;
>   case PIPE_VIDEO_FORMAT_VP9:
>   if (sscreen->info.family < CHIP_RAVEN)
> diff --git a/src/gallium/drivers/radeonsi/si_uvd.c 
> b/src/gallium/drivers/radeonsi/si_uvd.c
> index 1a9d8f8d9fa..8c9553acbf3 100644
> --- a/src/gallium/drivers/radeonsi/si_uvd.c
> +++ b/src/gallium/drivers/radeonsi/si_uvd.c
> @@ -139,21 +139,22 @@ static void si_vce_get_buffer(struct pipe_resource 
> *resource,
>   *surface = >surface;
>   }
>   
>   /**
>* creates an UVD compatible decoder
>*/
>   struct pipe_video_codec *si_uvd_create_decoder(struct pipe_context *context,
>  const struct pipe_video_codec 
> *templ)
>   {
>   struct si_context *ctx = (struct si_context *)context;
> - bool vcn = (ctx->family == CHIP_RAVEN) ? true : false;
> + bool vcn = ctx->family == CHIP_RAVEN ||
> +ctx->family == CHIP_RAVEN2;
>   
>   if (templ->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
>   if (vcn) {
>   return radeon_create_encoder(context, templ, ctx->ws, 
> si_vce_get_buffer);
>   } else {
>   if (u_reduce_video_profile(templ->profile) == 
> PIPE_VIDEO_FORMAT_HEVC)
>   return radeon_uvd_create_encoder(context, 
> templ, ctx->ws, si_vce_get_buffer);
> 

[Mesa-dev] [PATCH] amd/common: check DRM version 3.27 for JPEG decode

[Liu, Leo]

JPEG was added after DRM version 3.26

Signed-off-by: Leo Liu 
Fixes: 4558758c51749(amd/common: add vcn jpeg ip info query)
Cc: Boyuan Zhang 
Cc: Alex Smith 
---
 src/amd/common/ac_gpu_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index ed08b500c63..2c70fb2c721 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -186,7 +186,7 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
}
}
 
-   if (info->drm_major == 3 && info->drm_minor >= 17) {
+   if (info->drm_major == 3 && info->drm_minor >= 27) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_JPEG, 0, 
_jpeg);
if (r) {
fprintf(stderr, "amdgpu: 
amdgpu_query_hw_ip_info(vcn_jpeg) failed.\n");
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/15] meson: update required amdgpu version to 2.4.95

[Liu, Leo]

On 2018-10-17 3:03 p.m., boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang 
>
> VCN jpeg requires new hw ip

Patch 1 & 2 are:

Reviewed-by: Leo Liu 

>
> Signed-off-by: Boyuan Zhang 
> ---
>   meson.build | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 002ce35a60..35e3e934a3 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1108,7 +1108,7 @@ dep_libdrm_etnaviv = null_dep
>   dep_libdrm_freedreno = null_dep
>   dep_libdrm_intel = null_dep
>   
> -_drm_amdgpu_ver = '2.4.93'
> +_drm_amdgpu_ver = '2.4.95'
>   _drm_radeon_ver = '2.4.71'
>   _drm_nouveau_ver = '2.4.66'
>   _drm_etnaviv_ver = '2.4.89'
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: use provided sizes and coords for getimage

[Liu, Leo]

Reviewed-by: Leo Liu 

-Original Message-
From: Zhang, Boyuan 
Sent: Friday, October 05, 2018 12:01 PM
To: mesa-dev@lists.freedesktop.org
Cc: Liu, Leo ; imir...@alum.mit.edu; 
ckoenig.leichtzumer...@gmail.com; Zhang, Boyuan 
Subject: [PATCH] st/va: use provided sizes and coords for getimage

From: Boyuan Zhang 

vlVaGetImage should respect the width, height, and coordinates x and y that 
passed in. Therefore, pipe_box should be created with the passed in values 
instead of surface width/height. 

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/image.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 3f892c9..c9f6f18 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -400,11 +400,14 @@ vlVaGetImage(VADriverContextP ctx, VASurfaceID surface, 
int x, int y,
}
 
for (i = 0; i < vaimage->num_planes; i++) {
-  unsigned width, height;
+  unsigned w = align(width, 2);
+  unsigned h = align(height, 2);
   if (!views[i]) continue;
-  vlVaVideoSurfaceSize(surf, i, , );
+  vl_video_buffer_adjust_size(, , i,
+  surf->templat.chroma_format,
+  surf->templat.interlaced);
   for (j = 0; j < views[i]->texture->array_size; ++j) {
- struct pipe_box box = {0, 0, j, width, height, 1};
+ struct pipe_box box = {x, y, j, w, h, 1};
  struct pipe_transfer *transfer;
  uint8_t *map;
  map = drv->pipe->transfer_map(drv->pipe, views[i]->texture, 0,
--
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] st/omx: add support for nouveau / interlaced

[Liu, Leo]

Hi Julien and Christian,


I got a patch attached to fix the "fillout" problem, and please review.


But we still need to fix transcoding issue with interlaced as true. Our 
transcode support tunneling, basic the decode buffer will be used directly for 
encode.


Thanks,

Leo




From: Julien Isorce <julien.iso...@gmail.com>
Sent: June 27, 2016 4:54:07 PM
To: Liu, Leo
Cc: ML mesa-dev; Gurkirpal Singh; Koenig, Christian
Subject: Re: [Mesa-dev] [PATCH 2/3] st/omx: add support for nouveau / interlaced

Hi Leo,

Sorry for the inconvenience, could you let me know how to reproduce the problem 
?
I have been playing with some gst pipelines and they all work but I can only 
test with nouveau driver.

Cheers
Julien


On 27 June 2016 at 21:35, Leo Liu <leo@amd.com<mailto:leo@amd.com>> 
wrote:
This patch break omx decode to file, it got seg fault. Will take look further.

Regards,
Leo



On 06/27/2016 04:16 AM, Julien Isorce wrote:
Signed-off-by: Julien Isorce <j.iso...@samsung.com<mailto:j.iso...@samsung.com>>
---
  src/gallium/state_trackers/omx/vid_dec.c | 51 
  1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/src/gallium/state_trackers/omx/vid_dec.c 
b/src/gallium/state_trackers/omx/vid_dec.c
index 564ca2f..85ffb88 100644
--- a/src/gallium/state_trackers/omx/vid_dec.c
+++ b/src/gallium/state_trackers/omx/vid_dec.c
@@ -48,6 +48,7 @@
  #include "pipe/p_video_codec.h"
  #include "util/u_memory.h"
  #include "util/u_surface.h"
+#include "vl/vl_video_buffer.h"
  #include "vl/vl_vlc.h"
#include "entrypoint.h"
@@ -515,34 +516,34 @@ static void vid_dec_FillOutput(vid_dec_PrivateType *priv, 
struct pipe_video_buff
 OMX_VIDEO_PORTDEFINITIONTYPE *def = >sPortParam.format.video;
   struct pipe_sampler_view **views;
-   struct pipe_transfer *transfer;
-   struct pipe_box box = { };
-   uint8_t *src, *dst;
+   unsigned i, j;
+   unsigned width, height;
   views = buf->get_sampler_view_planes(buf);
  -   dst = output->pBuffer;
-
-   box.width = def->nFrameWidth;
-   box.height = def->nFrameHeight;
-   box.depth = 1;
-
-   src = priv->pipe->transfer_map(priv->pipe, views[0]->texture, 0,
-  PIPE_TRANSFER_READ, , );
-   util_copy_rect(dst, views[0]->texture->format, def->nStride, 0, 0,
-  box.width, box.height, src, transfer->stride, 0, 0);
-   pipe_transfer_unmap(priv->pipe, transfer);
-
-   dst = ((uint8_t*)output->pBuffer) + (def->nStride * box.height);
-
-   box.width = def->nFrameWidth / 2;
-   box.height = def->nFrameHeight / 2;
-
-   src = priv->pipe->transfer_map(priv->pipe, views[1]->texture, 0,
-  PIPE_TRANSFER_READ, , );
-   util_copy_rect(dst, views[1]->texture->format, def->nStride, 0, 0,
-  box.width, box.height, src, transfer->stride, 0, 0);
-   pipe_transfer_unmap(priv->pipe, transfer);
+   for (i = 0; i < 2 /* NV12 */; i++) {
+  if (!views[i]) continue;
+  width = buf->width;
+  height = buf->height;
+  vl_video_buffer_adjust_size(, , i, buf->interlaced, 
buf->chroma_format);
+  for (j = 0; j < views[i]->texture->array_size; ++j) {
+ struct pipe_box box = {0, 0, j, width, height, 1};
+ struct pipe_transfer *transfer;
+ uint8_t *map, *dst;
+ map = priv->pipe->transfer_map(priv->pipe, views[i]->texture, 0,
+  PIPE_TRANSFER_READ, , );
+ if (!map)
+return;
+
+ dst = ((uint8_t*)output->pBuffer + output->nOffset) + j * 
def->nStride + i * buf->width * buf->height;
+ util_copy_rect(dst,
+views[i]->texture->format,
+def->nStride * views[i]->texture->array_size, 0, 0,
+box.width, box.height, map, transfer->stride, 0, 0);
+
+     pipe_transfer_unmap(priv->pipe, transfer);
+  }
+   }
  }
static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp, 
OMX_BUFFERHEADERTYPE* input,


From 8c06114545d63cd435834b1f7664e68bc0189a77 Mon Sep 17 00:00:00 2001
From: Leo Liu <leo@amd.com>
Date: Mon, 27 Jun 2016 20:40:30 -0400
Subject: [PATCH] st/omx: fix decoder fillout for the OMX result buffer

The call for vl_video_buffer_adjust_size is with wrong order of
arguments, apparently it will have problem when interlaced false;

The size of OMX result buffer depends on real size of clips, vl buffer
dimension is aligned with 16, so 1080p(1920*1080) video will overflow
the OMX buffer

Signed-off-by: Leo Liu <leo@amd.com>
---
 src/gallium/state_trackers/omx/vid_dec.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/omx/vid_dec.c b/src/gallium/state_trackers/omx/vid_dec

Re: [Mesa-dev] [PATCH] st/omx: straighten get/put_screen

[Liu, Leo]

>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Monday, November 09, 2015 1:34 PM
>To: Liu, Leo
>Cc: mesa-dev@lists.freedesktop.org
>Subject: Re: [PATCH] st/omx: straighten get/put_screen
>
>On 9 November 2015 at 15:22, Liu, Leo <leo@amd.com> wrote:
>>>-Original Message-
>>>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>>>Sent: Monday, November 09, 2015 8:17 AM
>>>To: mesa-dev@lists.freedesktop.org
>>>Cc: emil.l.veli...@gmail.com; Liu, Leo
>>>Subject: [PATCH] st/omx: straighten get/put_screen
>>>
>>>The current code is busted in a number of ways.
>>>
>>> - initially checks for omx_display (rather than omx_screen), which
>>>may or may not be around.
>>> - blindly feeds the empty env variable string to loader_open_device()
>>
>> Should be treating empty string as one of incorrect string, which result in 
>> failing
>open.
>> Because user's intention is to use to env, if they put the empty string, here
>should be getting failed.
>>
>I was leaning that the "check for empty string" approach was "the gallium way".
>Although on second look the opposite seems to be more common, so consider it
>gone.
>
Sound good.

>Btw. did any of the issues outlined became obvious with my previous comments
>or am I too subtle ? Or you did not consider them something worth the hassle ?
>
I am with you. Perfection is always better.

Thanks,
Leo

>Thanks
>Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx: straighten get/put_screen

[Liu, Leo]

>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Monday, November 09, 2015 8:17 AM
>To: mesa-dev@lists.freedesktop.org
>Cc: emil.l.veli...@gmail.com; Liu, Leo
>Subject: [PATCH] st/omx: straighten get/put_screen
>
>The current code is busted in a number of ways.
>
> - initially checks for omx_display (rather than omx_screen), which may or may
>not be around.
> - blindly feeds the empty env variable string to loader_open_device()

Should be treating empty string as one of incorrect string, which result in 
failing open.
Because user's intention is to use to env, if they put the empty string, here 
should be getting failed.

Either way:
Reviewed-by: Leo Liu <leo@amd.com>

Regards,
Leo

> - reads the env variable every time get_screen is called
> - the latter manifests into memory leaks, and other issues as one sets the
>variable between two get_screen calls.
>
>Additionally it cleans up a couple of extra bits
> - drops unneeded set/check of omx_display.
> - make the teardown (put_screen) order was not symmetrical to the setup
>(get_screen)
>
>Cc: Leo Liu <leo@amd.com>
>Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>
>---
>
>Leo, feel free to point out if I'm loosing the plot and some of these don't 
>hold
>true.
>
>-Emil
>
> src/gallium/state_trackers/omx/entrypoint.c | 35 -
> 1 file changed, 19 insertions(+), 16 deletions(-)
>
>diff --git a/src/gallium/state_trackers/omx/entrypoint.c
>b/src/gallium/state_trackers/omx/entrypoint.c
>index 7df90b1..f99a620 100644
>--- a/src/gallium/state_trackers/omx/entrypoint.c
>+++ b/src/gallium/state_trackers/omx/entrypoint.c
>@@ -33,6 +33,7 @@
>
> #include 
> #include 
>+#include 
>
> #include 
>
>@@ -73,28 +74,32 @@ int
>omx_component_library_Setup(stLoaderComponentType **stComponents)
>
> struct vl_screen *omx_get_screen(void)
> {
>+   static bool first_time = true;
>pipe_mutex_lock(omx_lock);
>
>-   if (!omx_display) {
>-  omx_render_node = debug_get_option("OMX_RENDER_NODE", NULL);
>-  if (!omx_render_node) {
>- omx_display = XOpenDisplay(NULL);
>- if (!omx_display)
>-goto error;
>-  }
>-   }
>-
>if (!omx_screen) {
>+  if (first_time) {
>+ omx_render_node = debug_get_option("OMX_RENDER_NODE", NULL);
>+ if (omx_render_node && *omx_render_node == '\0')
>+omx_render_node = NULL;
>+
>+ first_time = false;
>+  }
>   if (omx_render_node) {
>  drm_fd = loader_open_device(omx_render_node);
>  if (drm_fd < 0)
> goto error;
>+
>  omx_screen = vl_drm_screen_create(drm_fd);
>  if (!omx_screen) {
> close(drm_fd);
> goto error;
>  }
>   } else {
>+ omx_display = XOpenDisplay(NULL);
>+ if (!omx_display)
>+goto error;
>+
>  omx_screen = vl_screen_create(omx_display, 0);
>  if (!omx_screen) {
> XCloseDisplay(omx_display); @@ -117,16 +122,14 @@ void
>omx_put_screen(void)  {
>pipe_mutex_lock(omx_lock);
>if ((--omx_usecount) == 0) {
>-  if (!omx_render_node) {
>- vl_screen_destroy(omx_screen);
>- if (omx_display)
>-XCloseDisplay(omx_display);
>-  } else {
>- close(drm_fd);
>+  if (omx_render_node) {
>  vl_drm_screen_destroy(omx_screen);
>+ close(drm_fd);
>+  } else {
>+ vl_screen_destroy(omx_screen);
>+ XCloseDisplay(omx_display);
>   }
>   omx_screen = NULL;
>-  omx_display = NULL;
>}
>pipe_mutex_unlock(omx_lock);
> }
>--
>2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] st/omx: add headless support

[Liu, Leo]

Hi Emil,

>Shorten the variable name - OMX_RENDER_NODE ? debug_get_option is only
>available on debug builds so better use getenv.
>

The debug_get_*_option() functions are used all around mesa, and functions are 
explicitly preferred to working with getenv() directly.

Regards,
Leo


>omx_render_node can be an empty string so we should check for that.
>
>>omx_display = XOpenDisplay(NULL);
>>if (!omx_display) {
>> - pipe_mutex_unlock(omx_lock);
>> - return NULL;
>> -  }
>> + if (!omx_render_node)
>> +goto error;
>> +  } else
>> + omx_render_node = NULL;
>The following will honour the env override, without attempting to connect to X.
>
>if (!omx_render_node && omx_render_node != "") {
>  int fd = loader_open_device()
>  vl_drm_screen_create()
>} else {
>  omx_display = XOpenDisplay()
>  vl_screen_create()
>}
>
>
>
>> }
>>
>> if (!omx_screen) {
>> -  omx_screen = vl_screen_create(omx_display, 0);
>> -  if (!omx_screen) {
>> - pipe_mutex_unlock(omx_lock);
>> - return NULL;
>> -  }
>> +  if (omx_render_node) {
>> + int fd = open(omx_render_node, O_RDWR);
>Use loader_open_device(), it gives you free C_CLOEXEC handling.
>
>As you send v2 of the series feel free to squash patches 2 and 3.
>
>Thanks
>Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] vl: add drm support for vl_screen

[Liu, Leo]

>> +#if GALLIUM_STATIC_TARGETS
>> +   vscreen->pscreen = dd_create_screen(fd);
>> +#else
>> +   if (pipe_loader_drm_probe_fd(>dev, fd)) {
>Add a dup() in the above. So that it reads
>
>if (pipe_loader_drm_probe_fd(>dev, dup(fd))) {
>

The dup is handled is in st/va/context.c before calling vl_drm_screen_create

Regards,
Leo

>Thanks
>Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: add mpeg4 startcode workaround

[Liu, Leo]

+Boyuan, forgot to Cc him when I sent.

Regards,
Leo


>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Thursday, November 05, 2015 7:00 PM
>To: Liu, Leo
>Cc: ML mesa-dev
>Subject: Re: [Mesa-dev] [PATCH] st/va: add mpeg4 startcode workaround
>
>On 5 November 2015 at 21:00, Leo Liu <leo@amd.com> wrote:
>> From: Boyuan Zhang <boyuan.zh...@amd.com>
>>
>> Signed-off-by: Boyuan Zhang <boyuan.zh...@amd.com>
>> Reviewed-by: Christian König <christian.koe...@amd.com>
>> ---
>>  src/gallium/state_trackers/va/buffer.c |  24 +-
>>  src/gallium/state_trackers/va/context.c|   7 ++
>>  src/gallium/state_trackers/va/picture.c| 117 
>> +
>>  src/gallium/state_trackers/va/va_private.h |   3 +
>>  4 files changed, 102 insertions(+), 49 deletions(-)
>>
>Guys can get some commit message please ? What is the workaround why is it
>needed ?
>
>It's a bit sad that one has to ask for such a thing.
>
>
>> @@ -59,8 +70,17 @@ vlVaCreateBuffer(VADriverContextP ctx, VAContextID
>context, VABufferType type,
>>return VA_STATUS_ERROR_ALLOCATION_FAILED;
>> }
>>
>> -   if (data)
>> -  memcpy(buf->data, data, size * num_elements);
>> +   uint8_t* pExternalData = (uint8_t*) data;
>> +   if (data) {
>> +  if ((u_reduce_video_profile(pContext->desc.base.profile) ==
>PIPE_VIDEO_FORMAT_MPEG4)
>> +&& (pContext->mpeg4.vaapi_mpeg4_workaround == true)
>> +&& (buf->type == VASliceDataBufferType)) {
>Please follow st/va coding style - drop the explicit comparison against true, 
>&&
>should be at the end of the line.
>
>
>> --- a/src/gallium/state_trackers/va/context.c
>> +++ b/src/gallium/state_trackers/va/context.c
>> @@ -35,6 +35,8 @@
>>
>>  #include "va_private.h"
>>
>> +DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_WORKAROUND",
>FALSE);
>> +
>You do realise that defined as it, one can only use VAAPI_MPEG4_WORKAROUND
>on debug mesa builds ?
>
>
>> @@ -275,6 +277,11 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
>config_id, int picture_width,
>>  return VA_STATUS_ERROR_ALLOCATION_FAILED;
>>   }
>>}
>> +
>> +  if (u_reduce_video_profile(context->decoder->profile) ==
>> +PIPE_VIDEO_FORMAT_MPEG4) {
>u_reduce_video_profile() is called three times already. Stash it into a local
>variable and keep the comparison on a single line ?
>
>
>> --- a/src/gallium/state_trackers/va/picture.c
>> +++ b/src/gallium/state_trackers/va/picture.c
>> @@ -584,60 +584,83 @@ vlVaDecoderFixMPEG4Startcode(vlVaContext
>> *context)
>
>> +  for (int i = 0 ; i < VL_VA_MPEG4_BYTES_FOR_LOOKUP ; i++) {
>> + if (memcmp (p, start_code, sizeof(start_code)) == 0) {
>> +found = true;
>Just use startcode_available directly ?
>
>> +break;
>> + }
>> + p += 1;
>> + extraSize += 1;
>> +  }
>> +  if (found) {
>> + startcode_available = true;
>
>
>-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] st/omx: add headless support

[Liu, Leo]

>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Thursday, November 05, 2015 6:30 PM
>To: Liu, Leo
>Cc: ML mesa-dev
>Subject: Re: [Mesa-dev] [PATCH 4/4] st/omx: add headless support
>
>On 5 November 2015 at 18:47, Leo Liu <leo@amd.com> wrote:
>> This will allow dec/enc/transcode without X
>>
>Are we talking about multi GPU setup where X is running on one, and OMX on
>another, or a true "without X" case ?

Only one.

> I'm leaning that the latter isn't really
>possible, yet.

Why?

Regards,
Leo

>

>> Signed-off-by: Leo Liu <leo@amd.com>
>> ---
>>  src/gallium/state_trackers/omx/entrypoint.c | 39
>> +
>>  1 file changed, 29 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/omx/entrypoint.c
>> b/src/gallium/state_trackers/omx/entrypoint.c
>> index a765666..a6a1279 100644
>> --- a/src/gallium/state_trackers/omx/entrypoint.c
>> +++ b/src/gallium/state_trackers/omx/entrypoint.c
>> @@ -33,6 +33,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>
>> @@ -47,6 +48,7 @@ pipe_static_mutex(omx_lock);  static Display
>> *omx_display = NULL;  static struct vl_screen *omx_screen = NULL;
>> static unsigned omx_usecount = 0;
>> +static const char *omx_render_node = NULL;
>>
>>  int omx_component_library_Setup(stLoaderComponentType **stComponents)
>> { @@ -73,33 +75,50 @@ struct vl_screen *omx_get_screen(void)
>> pipe_mutex_lock(omx_lock);
>>
>> if (!omx_display) {
>> +  omx_render_node = debug_get_option("OMX_DRM_RENDER_NODES",
>> + NULL);
>Shorten the variable name - OMX_RENDER_NODE ? debug_get_option is only
>available on debug builds so better use getenv.
>
>omx_render_node can be an empty string so we should check for that.
>
>>omx_display = XOpenDisplay(NULL);
>>if (!omx_display) {
>> - pipe_mutex_unlock(omx_lock);
>> - return NULL;
>> -  }
>> + if (!omx_render_node)
>> +goto error;
>> +  } else
>> + omx_render_node = NULL;
>The following will honour the env override, without attempting to connect to X.
>
>if (!omx_render_node && omx_render_node != "") {
>  int fd = loader_open_device()
>  vl_drm_screen_create()
>} else {
>  omx_display = XOpenDisplay()
>  vl_screen_create()
>}
>
>
>
>> }
>>
>> if (!omx_screen) {
>> -  omx_screen = vl_screen_create(omx_display, 0);
>> -  if (!omx_screen) {
>> - pipe_mutex_unlock(omx_lock);
>> - return NULL;
>> -  }
>> +  if (omx_render_node) {
>> + int fd = open(omx_render_node, O_RDWR);
>Use loader_open_device(), it gives you free C_CLOEXEC handling.
>
>As you send v2 of the series feel free to squash patches 2 and 3.
>
>Thanks
>Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx/dec/h264: fix field picture type 0 poc disorder

[Liu, Leo]

Ping...

>-Original Message-
>From: Liu, Leo
>Sent: Wednesday, October 14, 2015 2:49 PM
>To: mesa-dev@lists.freedesktop.org
>Cc: Liu, Leo; 10.6 11.0
>Subject: [PATCH] st/omx/dec/h264: fix field picture type 0 poc disorder
>
>Signed-off-by: Leo Liu <leo@amd.com>
>Cc: "10.6 11.0" <mesa-sta...@lists.freedesktop.org>
>---
> src/gallium/state_trackers/omx/vid_dec_h264.c | 12 
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
>diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c
>b/src/gallium/state_trackers/omx/vid_dec_h264.c
>index 18d8803..f66ed89 100644
>--- a/src/gallium/state_trackers/omx/vid_dec_h264.c
>+++ b/src/gallium/state_trackers/omx/vid_dec_h264.c
>@@ -753,10 +753,14 @@ static void slice_header(vid_dec_PrivateType *priv,
>struct vl_rbsp *rbsp,
>  priv->codec_data.h264.delta_pic_order_cnt_bottom =
>delta_pic_order_cnt_bottom;
>   }
>
>-  priv->picture.h264.field_order_cnt[0] = pic_order_cnt_msb +
>pic_order_cnt_lsb;
>-  priv->picture.h264.field_order_cnt[1] = pic_order_cnt_msb +
>pic_order_cnt_lsb;
>-  if (!priv->picture.h264.field_pic_flag)
>- priv->picture.h264.field_order_cnt[1] += priv-
>>codec_data.h264.delta_pic_order_cnt_bottom;
>+  if (!priv->picture.h264.field_pic_flag) {
>+ priv->picture.h264.field_order_cnt[0] = pic_order_cnt_msb +
>pic_order_cnt_lsb;
>+ priv->picture.h264.field_order_cnt[1] = 
>priv->picture.h264.field_order_cnt
>[0] +
>+  
>priv->codec_data.h264.delta_pic_order_cnt_bottom;
>+  } else if (!priv->picture.h264.bottom_field_flag)
>+ priv->picture.h264.field_order_cnt[0] = pic_order_cnt_msb +
>pic_order_cnt_lsb;
>+  else
>+ priv->picture.h264.field_order_cnt[1] = pic_order_cnt_msb +
>pic_order_cnt_lsb;
>
>} else if (sps->pic_order_cnt_type == 1) {
>   unsigned MaxFrameNum = 1 << (sps->log2_max_frame_num_minus4 + 4);
>--
>1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state tracker

[Liu, Leo]

Hi Emil,

Any comments on V4

Thanks,
Leo


-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
Liu, Leo
Sent: Monday, September 29, 2014 12:30 PM
To: Emil Velikov
Cc: mesa-dev@lists.freedesktop.org; Koenig, Christian
Subject: Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state tracker

Hi Emil,

Thanks for the explanation.
V4 has been sent, please review.

Thanks,
Leo

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Monday, September 29, 2014 12:27 PM
To: Liu, Leo
Cc: mesa-dev@lists.freedesktop.org; Koenig, Christian
Subject: Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state
tracker

Hi Leo,

[...]
It seems that you've dropped the sym file. Is that intentional, can
we get it back please ?

 I will get it back.
 What's the purpose of this sym file? Thanks.

It can be used for two purposes - version/tag exported symbols, manager
exported/private symbols.
We use the latter, otherwise our libraries will export functions which
they should not. Mostly llvm symbols plus a few other which cannot be easily
fixed otherwise.

 +dnl Directory for VA libs
 +
 +AC_ARG_WITH([va-libdir],
 +[AS_HELP_STRING([--with-va-libdir=DIR],
 +[directory for the VA libraries @:@default=`pkg-config
 +libva --
variable=driverdir`@:@])],
 +[VA_LIB_INSTALL_DIR=$withval],
 +[VA_LIB_INSTALL_DIR=`pkg-config libva --variable=driverdir`])
 +AC_SUBST([VA_LIB_INSTALL_DIR])
 +
The above hunk has silently changed since v2 and I'm not sure this
one is
better.
Also there is a discussion about mesa's use of the above pkg-config
to set the destination/install dir. I'll amend mesa at a later stage
once a decision is made :)

 So, Can I just keep it like this for now?

I meant the complete opposite, but don't bother. Most likely I'll redo
this in a day or so.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state tracker

[Liu, Leo]

Hi Emil,

Thanks for the explanation.
V4 has been sent, please review.

Thanks,
Leo

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Monday, September 29, 2014 12:27 PM
To: Liu, Leo
Cc: mesa-dev@lists.freedesktop.org; Koenig, Christian
Subject: Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state tracker

Hi Leo,

[...]
It seems that you've dropped the sym file. Is that intentional, can we
get it back please ?

 I will get it back.
 What's the purpose of this sym file? Thanks.

It can be used for two purposes - version/tag exported symbols, manager
exported/private symbols.
We use the latter, otherwise our libraries will export functions which they 
should
not. Mostly llvm symbols plus a few other which cannot be easily fixed 
otherwise.

 +dnl Directory for VA libs
 +
 +AC_ARG_WITH([va-libdir],
 +[AS_HELP_STRING([--with-va-libdir=DIR],
 +[directory for the VA libraries @:@default=`pkg-config
 +libva --
variable=driverdir`@:@])],
 +[VA_LIB_INSTALL_DIR=$withval],
 +[VA_LIB_INSTALL_DIR=`pkg-config libva --variable=driverdir`])
 +AC_SUBST([VA_LIB_INSTALL_DIR])
 +
The above hunk has silently changed since v2 and I'm not sure this one is
better.
Also there is a discussion about mesa's use of the above pkg-config to
set the destination/install dir. I'll amend mesa at a later stage once
a decision is made :)

 So, Can I just keep it like this for now?

I meant the complete opposite, but don't bother. Most likely I'll redo this in 
a day
or so.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state tracker

[Liu, Leo]

Hi Emil,

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Sunday, September 28, 2014 4:43 PM
To: Liu, Leo; mesa-dev@lists.freedesktop.org
Cc: emil.l.veli...@gmail.com; Koenig, Christian
Subject: Re: [Mesa-dev] [PATCH v3 2/6] st/va: skeleton VAAPI state tracker

Hi Leo,

On 26/09/14 21:13, Leo Liu wrote:
 From: Christian König christian.koe...@amd.com

 This patch adds a skeleton VA-API state tracker, which is filled with
 live in the subsequent patches.

 v2: fixes in configure.ac and va state_tracker Makefile.am
s/state_tracker Makefile.am/target Makefile.am/

 v3: configure.ac:
generate a marco for link to xcb
auto-dectecting VA version
rebase with upstream changes
 state-trackers/va/Makefile.am:
pass symbol for auto-detecting VA version
 targets/va/Makefile.am
rebase with omx/Makefile.am
 use macro VA_DRIVER_INIT_FUNC for auto-detect

The changelog is rather difficult to read. Can I suggest something like
 - Do not link against libva.
 - Detect libva version, and correctly set driver entrypoint name.
 - Rebase(cleanup) targets/va/Makefile.am

This's better.

Rather than setting up the whole function name in configure.ac can't we just 
pass
the version number ? VDPAU is doing it and seems to be what Gwenole was
suggesting.

This also makes sense.

It seems that you've dropped the sym file. Is that intentional, can we get it 
back
please ?

I will get it back.
What's the purpose of this sym file? Thanks.

 +dnl Directory for VA libs
 +
 +AC_ARG_WITH([va-libdir],
 +[AS_HELP_STRING([--with-va-libdir=DIR],
 +[directory for the VA libraries @:@default=`pkg-config libva --
variable=driverdir`@:@])],
 +[VA_LIB_INSTALL_DIR=$withval],
 +[VA_LIB_INSTALL_DIR=`pkg-config libva --variable=driverdir`])
 +AC_SUBST([VA_LIB_INSTALL_DIR])
 +
The above hunk has silently changed since v2 and I'm not sure this one is 
better.
Also there is a discussion about mesa's use of the above pkg-config to set the
destination/install dir. I'll amend mesa at a later stage once a decision is 
made :)

So, Can I just keep it like this for now?

 diff --git a/src/gallium/state_trackers/va/Makefile.am
 b/src/gallium/state_trackers/va/Makefile.am
 new file mode 100644
 index 000..b6d3f9a
 --- /dev/null
 +++ b/src/gallium/state_trackers/va/Makefile.am
[...]
 +AM_CFLAGS = \
 +$(GALLIUM_CFLAGS) \
 +$(VISIBILITY_CFLAGS) \
 +$(VA_CFLAGS)
 +AM_CFLAGS += -DVA_DRIVER_INIT_FUNC=$(VA_DRIVER_INIT_FUNC)
 +
Just merge the two ?

Sure.

Thanks,
Leo

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/6] st/va: implement vlVa(Query|Create|Get|Put|Destroy)Image

[Liu, Leo]

Hi Ilia,

-Original Message-
From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia Mirkin
Sent: Friday, September 26, 2014 4:37 PM
To: Liu, Leo
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH v2 6/6] st/va: implement
vlVa(Query|Create|Get|Put|Destroy)Image

[]

 +   case VA_FOURCC('U','Y','V','Y'):
 +   case VA_FOURCC('Y','U','Y','V'):
 +  image-num_planes = 1;
 +  image-pitches[0] = w * 4;
 +  image-offsets[0] = 0;
 +  image-data_size  = w * h * 4;

Is this right? YUYV/UYVY stores 2 pixels in 4 bytes, so it should be * 2, no? 
Also,
for this case, h probably doesn't need to be even, although it may still be a 
good
idea...

You are right. I will fix it . 

Thanks,
Leo


 +  break;
 +
 +   default:
return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
 +   }

 -   return VA_STATUS_ERROR_UNIMPLEMENTED;
 +   return vlVaCreateBuffer(ctx, 0, VAImageBufferType,
 +   align(image-data_size, 16),
 +   1, NULL, image-buf);
  }

  VAStatus
 @@ -69,10 +162,16 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID
 surface, VAImage *image)  VAStatus  vlVaDestroyImage(VADriverContextP
 ctx, VAImageID image)  {
 +   VAImage  *vaimage;
 +
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;

 -   return VA_STATUS_ERROR_UNIMPLEMENTED;
 +   vaimage = handle_table_get(VL_VA_DRIVER(ctx)-htab, image);
 +   if (!vaimage)
 +  return VA_STATUS_ERROR_INVALID_IMAGE;
 +
 +   return vlVaDestroyBuffer(ctx, vaimage-buf);
  }

  VAStatus
 @@ -88,10 +187,87 @@ VAStatus
  vlVaGetImage(VADriverContextP ctx, VASurfaceID surface, int x, int y,
   unsigned int width, unsigned int height, VAImageID
 image)  {
 +   vlVaDriver *drv;
 +   vlVaSurface *surf;
 +   vlVaBuffer *img_buf;
 +   VAImage *vaimage;
 +   struct pipe_sampler_view **views;
 +   enum pipe_format format;
 +   void *data[3];
 +   bool convert = false;
 +   unsigned i, j;
 +
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;

 -   return VA_STATUS_ERROR_UNIMPLEMENTED;
 +   drv = VL_VA_DRIVER(ctx);
 +
 +   surf = handle_table_get(drv-htab, surface);
 +   if (!surf || !surf-buffer)
 +  return VA_STATUS_ERROR_INVALID_SURFACE;
 +
 +   vaimage = handle_table_get(drv-htab, image);
 +   if (!vaimage)
 +  return VA_STATUS_ERROR_INVALID_IMAGE;
 +
 +   img_buf = handle_table_get(drv-htab, vaimage-buf);
 +   if (!img_buf)
 +  return VA_STATUS_ERROR_INVALID_BUFFER;
 +
 +   format = YCbCrToPipe(vaimage-format.fourcc);
 +   if (format == PIPE_FORMAT_NONE)
 +  return VA_STATUS_ERROR_OPERATION_FAILED;
 +
 +   if (format != surf-buffer-buffer_format) {
 +  /* support NV12 to YV12 conversion now only */
 +  if (format == PIPE_FORMAT_YV12 
 +  surf-buffer-buffer_format == PIPE_FORMAT_NV12)
 + convert = true;
 +  else
 + return VA_STATUS_ERROR_OPERATION_FAILED;
 +   }
 +
 +   views = surf-buffer-get_sampler_view_planes(surf-buffer);
 +   if (!views)
 +  return VA_STATUS_ERROR_OPERATION_FAILED;
 +
 +   for (i = 0; i  vaimage-num_planes; i++)
 +  data[i] = img_buf-data + vaimage-offsets[i];
 +   if (vaimage-format.fourcc == VA_FOURCC('I','4','2','0')) {
 +  void *tmp = data[1];
 +  data[1] = data[2];
 +  data[2] = tmp;
 +   }
 +
 +   for (i = 0; i  vaimage-num_planes; i++) {
 +  unsigned width, height;
 +  if (!views[i]) continue;
 +  data[i] = img_buf-data + vaimage-offsets[i];
 +  vlVaVideoSurfaceSize(surf, i, width, height);
 +  for (j = 0; j  views[i]-texture-array_size; ++j) {
 + struct pipe_box box = {0, 0, j, width, height, 1};
 + struct pipe_transfer *transfer;
 + uint8_t *map;
 + map = drv-pipe-transfer_map(drv-pipe, views[i]-texture, 0,
 +  PIPE_TRANSFER_READ, box, transfer);
 + if (!map)
 +return VA_STATUS_ERROR_OPERATION_FAILED;
 +
 + if (i == 1  convert) {
 +u_copy_nv12_to_yv12(data, vaimage-pitches,
 +   i, j, transfer-stride, views[i]-texture-array_size,
 +   map, box.width, box.height);
 + } else {
 +util_copy_rect(data[i] + vaimage-pitches[i] * j,
 +   views[i]-texture-format,
 +   vaimage-pitches[i] * views[i]-texture-array_size, 0, 0,
 +   box.width, box.height, map, transfer-stride, 0, 0);
 + }
 + pipe_transfer_unmap(drv-pipe, transfer);
 +  }
 +   }
 +
 +   return VA_STATUS_SUCCESS;
  }

  VAStatus
 @@ -99,8 +275,70 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID
surface, VAImageID image,
   int src_x, int src_y, unsigned int src_width, unsigned int 
 src_height,
   int dest_x, int dest_y, unsigned int dest_width,
 unsigned int dest_height)  {
 +   vlVaDriver *drv;
 +   vlVaSurface *surf;
 +   vlVaBuffer *img_buf;
 +   VAImage *vaimage;
 +   struct pipe_sampler_view **views;
 +   enum pipe_format format;
 +   void *data[3

Re: [Mesa-dev] [PATCH 6/6] st/va: implement vlVa(Query|Create|Get|Put|Destroy)Image

[Liu, Leo]

Hi Emil,

Sorry for that.

Get incorrect after some rebase for patch 2 context.c

+   ctx-max_image_formats = 1;

That should be 4

Thanks,
Leo


-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Thursday, September 25, 2014 8:29 AM
To: Liu, Leo; mesa-dev@lists.freedesktop.org
Cc: emil.l.veli...@gmail.com
Subject: Re: [Mesa-dev] [PATCH 6/6] st/va: implement
vlVa(Query|Create|Get|Put|Destroy)Image

Hi Leo,

On 23/09/14 17:44, Leo Liu wrote:
 This patch implements functions for images support, which basically
 supports copy data between video surface and user buffers, in this
 case supports SW decode, and other video output

You've increased the image formats to 4, yet the driver reports only 1.
Causing a nice crash :(

And after fixing it now nouveau crashes... fun times.

Thanks
Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] st/va: skeleton VAAPI state tracker

[Liu, Leo]

Hi Gwenole and Emil,

 +gallium_drv_video_la_LIBADD = \
 +   $(top_builddir)/src/gallium/state_trackers/va/libvatracker.la \
 +   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
 +   $(top_builddir)/src/util/libmesautil.la \
 +   $(LIBVA_LIBS) \
 Unless I've missed something this link should not be needed. If in
 doubt just omit it, and let the _compiler_ shout about undefined
 symbols :)


 If you talk about $(LIBVA_LIBS), we probably need it.
 Why do you insist on guessing when there is someone (normally the
 linker but in this case me) else to check for you :'(

Agreed with Emil, you will hardly have to depend on libva symbols from a VA
driver perspective. i.e. that should be omitted, only the headers are useful.


the reason for $(LIBVA_LIBS) is for xcb lib, from configure.ac
+PKG_CHECK_MODULES([LIBVA], [libva = 0.35.0 x11-xcb xcb-dri2 = 
$XCBDRI2_REQUIRED])

I will separate them, and remove libva for link.

Thanks,
Leo



This holds to the Intel VA driver too, so I will have to apply Emil's patch. :)

 $ ldd -r -u gallium_drv_video.so
 Unused direct dependencies:
 /usr/lib/libva.so.1


 Don't mean to come as rude, but did you even build the series ? It
 seems to be failing on my system.


 On 24/09/14 18:46, Leo Liu wrote:
 From: Christian König christian.koe...@amd.com

 This patch adds a skeleton VA-API state tracker, which is filled with
 live in the subsequent patches.

 v2: fixes in configure.ac and va state_tracker Makefile.am

 va target Makefile.am to reflect reality :)

 Signed-off-by: Christian König christian.koe...@amd.com
 Signed-off-by: Leo Liu leo@amd.com

 diff --git a/configure.ac b/configure.ac index 87c616b..5d363d7
 100644
 --- a/configure.ac
 +++ b/configure.ac
 [...]
 +AC_ARG_WITH([va-libdir],
 +[AS_HELP_STRING([--with-va-libdir=DIR],
 +[directory for the VA libraries])],
 [directory for the VA libraries @:@default=`pkg-config libva
 --variable=driverdir`@:@])],


 [...]
 --- /dev/null
 +++ b/src/gallium/targets/va/Makefile.am
 [...]
 +gallium_drv_video_la_LIBADD = \
 + $(top_builddir)/src/gallium/state_trackers/va/libvatracker.la \
 + $(top_builddir)/src/gallium/auxiliary/libgallium.la \
 + $(top_builddir)/src/util/libmesautil.la \
 + $(VA_LIBS)
 +
 Apart from removing VA_LIBS above you'll need to add a library or two.
 The compiler/linker will nicely point out what is needed as it builds.


 The if branch of the following conditional can be rewritten in 5 lines.
 Check out the omx target for an example.

 +if HAVE_GALLIUM_STATIC_TARGETS
 +
 +MEGADRIVERS =
 +STATIC_TARGET_CPPFLAGS = -DGALLIUM_STATIC_TARGETS=1
 +STATIC_TARGET_LIB_DEPS = \
 + $(top_builddir)/src/loader/libloader.la
 +
 +if HAVE_GALLIUM_R600
 +STATIC_TARGET_LIB_DEPS += \
 +
 +$(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la
 +else
 +if HAVE_GALLIUM_RADEONSI
 +STATIC_TARGET_LIB_DEPS += \
 +
 +$(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la
 +endif
 +endif
 +
 ...


 Now let see how well it works with nouveau :P

 Cheers,
 Emil

 I will fix the rest in the v2.

 Thanks,
 Leo


 Cheers,
 Emil

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] st/va: implement vlVa(Query|Create|Get|Put|Destroy)Image

[Liu, Leo]

Hi Gwenole,


-Original Message-
From: Gwenole Beauchesne [mailto:gb.de...@gmail.com]
Sent: Thursday, September 25, 2014 7:41 AM
To: Liu, Leo
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 6/6] st/va: implement
vlVa(Query|Create|Get|Put|Destroy)Image

Hi,

2014-09-23 18:44 GMT+02:00 Leo Liu leo@amd.com:
 This patch implements functions for images support, which basically
 supports copy data between video surface and user buffers, in this
 case supports SW decode, and other video output

My quick comments on this:
- Be careful of allocations of chroma planes for odd-sized images ;

Right, width and height should align with 2 before divide by 2, thanks. 

- I'd suggest you to expose I420 instead of YV12, even though that's just an 
U/V
plane swap.

May I know the reason? 

Thanks,
Leo

 Signed-off-by: Leo Liu leo@amd.com
 ---
  src/gallium/state_trackers/va/image.c  | 233
-
  src/gallium/state_trackers/va/va_private.h |  20 +++
  2 files changed, 245 insertions(+), 8 deletions(-)

 diff --git a/src/gallium/state_trackers/va/image.c
 b/src/gallium/state_trackers/va/image.c
 index 8aaa29c..8a7d226 100644
 --- a/src/gallium/state_trackers/va/image.c
 +++ b/src/gallium/state_trackers/va/image.c
 @@ -26,18 +26,65 @@
   *


**

 /

 +#include pipe/p_screen.h
 +
 +#include util/u_memory.h
 +#include util/u_handle_table.h
 +#include util/u_surface.h
 +#include util/u_video.h
 +
 +#include vl/vl_winsys.h
 +
  #include va_private.h

 +static const VAImageFormat formats[VL_VA_MAX_IMAGE_FORMATS] = {
 +   {VA_FOURCC('N','V','1','2')},
 +   {VA_FOURCC('Y','V','1','2')},
 +   {VA_FOURCC('Y','U','Y','V')},
 +   {VA_FOURCC('U','Y','V','Y')},
 +};
 +
 +static void
 +vlVaVideoSurfaceSize(vlVaSurface *p_surf, int component,
 + unsigned *width, unsigned *height) {
 +   *width = p_surf-templat.width;
 +   *height = p_surf-templat.height;
 +
 +   if (component  0) {
 +  if (p_surf-templat.chroma_format ==
PIPE_VIDEO_CHROMA_FORMAT_420) {
 + *width /= 2;
 + *height /= 2;
 +  } else if (p_surf-templat.chroma_format ==
PIPE_VIDEO_CHROMA_FORMAT_422)
 + *width /= 2;
 +   }
 +   if (p_surf-templat.interlaced)
 +  *height /= 2;
 +}
 +
  VAStatus
  vlVaQueryImageFormats(VADriverContextP ctx, VAImageFormat
 *format_list, int *num_formats)  {
 +   struct pipe_screen *pscreen;
 +   enum pipe_format format;
 +   int i;
 +
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;

 if (!(format_list  num_formats))
 -  return VA_STATUS_ERROR_UNKNOWN;
 +  return VA_STATUS_ERROR_INVALID_PARAMETER;

 *num_formats = 0;
 +   pscreen = VL_VA_PSCREEN(ctx);
 +   for (i = 0; i  sizeof(formats) / sizeof(formats[0]); ++i) {
 +  format = YCbCrToPipe(formats[i].fourcc);
 +  if (pscreen-is_video_format_supported(pscreen, format,
 +  PIPE_VIDEO_PROFILE_UNKNOWN,
 +  PIPE_VIDEO_ENTRYPOINT_BITSTREAM))
 + format_list[(*num_formats)++] = formats[i];
 +   }

 return VA_STATUS_SUCCESS;
  }
 @@ -45,16 +92,57 @@ vlVaQueryImageFormats(VADriverContextP ctx,
 VAImageFormat *format_list, int *num  VAStatus
 vlVaCreateImage(VADriverContextP ctx, VAImageFormat *format, int
 width, int height, VAImage *image)  {
 +   vlVaDriver *drv;
 +
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;

 -   if(!format)
 -  return VA_STATUS_ERROR_UNKNOWN;
 +   if (!(format  image  width  height))
 +  return VA_STATUS_ERROR_INVALID_PARAMETER;

 -   if (!(width  height))
 +   drv = VL_VA_DRIVER(ctx);
 +
 +   image-image_id = handle_table_add(drv-htab, image);
 +   image-format = *format;
 +   image-width = width;
 +   image-height = height;
 +
 +   switch (format-fourcc) {
 +   case VA_FOURCC('N','V','1','2'):
 +  image-num_planes = 2;
 +  image-pitches[0] = width;
 +  image-offsets[0] = 0;
 +  image-pitches[1] = width;
 +  image-offsets[1] = width * height;
 +  image-data_size  = width * height * 3 / 2;
 +  break;
 +
 +   case VA_FOURCC('Y','V','1','2'):
 +  image-num_planes = 3;
 +  image-pitches[0] = width;
 +  image-offsets[0] = 0;
 +  image-pitches[1] = width / 2;
 +  image-offsets[1] = width * height;
 +  image-pitches[2] = width / 2;
 +  image-offsets[2] = width * height * 5 / 4;
 +  image-data_size  = width * height * 3 / 2;
 +  break;
 +
 +   case VA_FOURCC('U','Y','V','Y'):
 +   case VA_FOURCC('Y','U','Y','V'):
 +  image-num_planes = 1;
 +  image-pitches[0] = width * 4;
 +  image-offsets[0] = 0;
 +  image-data_size  = width * height * 4;
 +  break;
 +
 +   default:
return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
 +   }

 -   return VA_STATUS_ERROR_UNIMPLEMENTED;
 +   return vlVaCreateBuffer(ctx, 0, VAImageBufferType,
 +   align(image-data_size, 16),
 +   1, NULL, image-buf

Re: [Mesa-dev] [PATCH 2/6] st/va: skeleton VAAPI state tracker

[Liu, Leo]

Hi Emil,


-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Tuesday, September 23, 2014 3:49 PM
To: Liu, Leo; mesa-dev@lists.freedesktop.org
Cc: emil.l.veli...@gmail.com; Koenig, Christian
Subject: Re: [Mesa-dev] [PATCH 2/6] st/va: skeleton VAAPI state tracker


..
 +
 +gallium_drv_video_la_LIBADD = \
 +$(top_builddir)/src/gallium/state_trackers/va/libvatracker.la \
 +$(top_builddir)/src/gallium/auxiliary/libgallium.la \
 +$(top_builddir)/src/util/libmesautil.la \
 +$(LIBVA_LIBS) \
Unless I've missed something this link should not be needed. If in doubt just 
omit
it, and let the _compiler_ shout about undefined symbols :)


If you talk about $(LIBVA_LIBS), we probably need it.
+PKG_CHECK_MODULES([LIBVA], [libva = 0.35.0 x11-xcb xcb-dri2 = 
$XCBDRI2_REQUIRED])
Maybe I need change the name of LIBVA to VA

I will fix the rest in the v2.

Thanks,
Leo


Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] radeon/vce: set number of cpbs based on level

[Liu, Leo]

Fixed. Thanks for the review.
My account is still not activated.

Leo

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Thursday, June 12, 2014 12:35 PM
To: Liu, Leo; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 5/5] radeon/vce: set number of cpbs based on
level

Am 12.06.2014 18:27, schrieb Leo Liu:
 Signed-off-by: Leo Liu leo@amd.com
 ---
   src/gallium/drivers/radeon/radeon_vce.c | 60
+++--
   src/gallium/drivers/radeon/radeon_vce.h |  3 +-
   2 files changed, 58 insertions(+), 5 deletions(-)

 diff --git a/src/gallium/drivers/radeon/radeon_vce.c
 b/src/gallium/drivers/radeon/radeon_vce.c
 index 81e62d3..353f3b0 100644
 --- a/src/gallium/drivers/radeon/radeon_vce.c
 +++ b/src/gallium/drivers/radeon/radeon_vce.c
 @@ -87,7 +87,7 @@ static void reset_cpb(struct rvce_encoder *enc)
  unsigned i;

  LIST_INITHEAD(enc-cpb_slots);
 -for (i = 0; i  RVCE_NUM_CPB_FRAMES; ++i) {
 +for (i = 0; i  enc-cpb_num; ++i) {
  struct rvce_cpb_slot *slot = enc-cpb_array[i];
  slot-index = i;
  slot-picture_type = PIPE_H264_ENC_PICTURE_TYPE_SKIP; @@
-131,6
 +131,59 @@ static void sort_cpb(struct rvce_encoder *enc)
   }

   /**
 + * get number of cpbs based on dpb
 + */
 +static unsigned get_cpb_num(struct rvce_encoder *enc) {
 +unsigned w = align(enc-base.width, 16) / 16;
 +unsigned h = align(enc-base.height, 16) / 16;
 +unsigned dpb;
 +
 +switch (enc-base.level) {
 +case 10:
 +dpb = 396;
 +break;
 +case 11:
 +dpb = 900;
 +break;
 +case 12:
 +case 13:
 +case 20:
 +dpb = 2376;
 +break;
 +case 21:
 +dpb = 4752;
 +break;
 +case 22:
 +case 30:
 +dpb = 8100;
 +break;
 +case 31:
 +dpb = 18000;
 +break;
 +case 32:
 +dpb = 20480;
 +break;
 +case 40:
 +case 41:
 +dpb = 32768;
 +break;
 +default:
 +case 42:
 +dpb = 34816;
 +break;
 +case 50:
 +dpb = 110400;
 +break;
 +case 51:
 +dpb = 184320;
 +break;
 +}
 +
 +return MIN2(dpb / (w * h), 16);
 +}
 +
 +/**
* destroy this video encoder
*/
   static void rvce_destroy(struct pipe_video_codec *encoder) @@
 -327,18 +380,19 @@ struct pipe_video_codec *rvce_create_encoder(struct
pipe_context *context,
  goto error;
  }

 +enc-cpb_num = get_cpb_num(enc);

Please add an error check here that we don't have zero CPBs, that can happen if
the user specifies an invalid level for the given resolution.
In this case a goto error should probably be sufficient.

With that fixed the series is Reviewed-by: Christian König
christian.koe...@amd.com

Leave me a note if your account is already activated or if I should commit 
them,
Christian.

  get_buffer(((struct vl_video_buffer *)tmp_buf)-resources[0], NULL,
tmp_surf);
  cpb_size = align(tmp_surf-level[0].pitch_bytes, 128);
  cpb_size = cpb_size * align(tmp_surf-npix_y, 16);
  cpb_size = cpb_size * 3 / 2;
 -cpb_size = cpb_size * RVCE_NUM_CPB_FRAMES;
 +cpb_size = cpb_size * enc-cpb_num;
  tmp_buf-destroy(tmp_buf);
  if (!rvid_create_buffer(enc-ws, enc-cpb, cpb_size,
RADEON_DOMAIN_VRAM)) {
  RVID_ERR(Can't create CPB buffer.\n);
  goto error;
  }

 -enc-cpb_array = CALLOC(RVCE_NUM_CPB_FRAMES, sizeof(struct
rvce_cpb_slot));
 +enc-cpb_array = CALLOC(enc-cpb_num, sizeof(struct rvce_cpb_slot));
  if (!enc-cpb_array)
  goto error;

 diff --git a/src/gallium/drivers/radeon/radeon_vce.h
 b/src/gallium/drivers/radeon/radeon_vce.h
 index 7cc87be..f1dea8a 100644
 --- a/src/gallium/drivers/radeon/radeon_vce.h
 +++ b/src/gallium/drivers/radeon/radeon_vce.h
 @@ -45,8 +45,6 @@
   #define RVCE_READWRITE(buf, domain) RVCE_CS(RVCE_RELOC(buf,
RADEON_USAGE_READWRITE, domain) * 4)
   #define RVCE_END() *begin = (enc-cs-buf[enc-cs-cdw] - begin) *
 4; }

 -#define RVCE_NUM_CPB_FRAMES 3
 -
   struct r600_common_screen;

   /* driver dependent callback */
 @@ -96,6 +94,7 @@ struct rvce_encoder {

  struct rvce_cpb_slot*cpb_array;
  struct list_headcpb_slots;
 +unsignedcpb_num;

  struct rvid_buffer  *fb;
  struct rvid_buffer  cpb;

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all

[Liu, Leo]

Okay. with PIPE_TRANSFER_MAP_DIRECTLY, the regression can be fixed too.
Going to resend patch for this approach.

Leo


-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
Christian König
Sent: Wednesday, April 02, 2014 9:43 AM
To: Marek Olšák; Alex Deucher
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at
all

I've applied the original patch because the same thing for reading textures
speeded up the decoding case with UVD quite significantly.

For VCE it reduced the CPU load as well, but I didn't checked if the encoding 
time
stayed the same (which isn't the case). I think the problem is that VCE needs 
to
wait for the DMA or 3D engine to complete the upload before it can proceed and
because of this becomes idle, gets clocked down etc... When the frame has
finished uploading we clock VCE up and get it running again and this needs 
time.

Anyway I've added the patch specially for VCE, so just disabling it for VCE 
doesn't
make much sense.

Christian.

Am 02.04.2014 15:34, schrieb Marek Olšák:
 Also, the VCE code could use PIPE_TRANSFER_MAP_DIRECTLY to avoid the
 blit and this patch wouldn't be needed.

 Marek

 On Wed, Apr 2, 2014 at 3:30 PM, Alex Deucher alexdeuc...@gmail.com
wrote:
 On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu leo@amd.com wrote:
 From: Leo Liu leo@amd.com

 This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
 In the case of VCE encoding with raw YUV file, CPU load directly to
 VRAM is faster than combination of CPU writing to GTT and then blit
 to VRAM with GPU.
 Why was the original patch applied?  I just want to make sure it
 wasn't a bug fix for avoiding a sigbus or something similar if we ran
 out of cpu visible vram.

 Alex

 ---
   src/gallium/drivers/radeon/r600_texture.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/drivers/radeon/r600_texture.c
 b/src/gallium/drivers/radeon/r600_texture.c
 index 45a9508..3dfddca 100644
 --- a/src/gallium/drivers/radeon/r600_texture.c
 +++ b/src/gallium/drivers/radeon/r600_texture.c
 @@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct
pipe_context *ctx,
  if (rtex-surface.level[level].mode = RADEON_SURF_MODE_1D)
  use_staging_texture = TRUE;

 -   /* Untiled buffers in VRAM, which is slow for CPU reads and writes 
 */
 -   if (!(usage  PIPE_TRANSFER_MAP_DIRECTLY) 
 +   /* Untiled buffers in VRAM, which is slow for CPU reads */
 +   if ((usage  PIPE_TRANSFER_READ)  !(usage 
 + PIPE_TRANSFER_MAP_DIRECTLY) 
  (rtex-resource.domains == RADEON_DOMAIN_VRAM)) {
  use_staging_texture = TRUE;
  }
 --
 1.8.1.2


 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx: always advertise all components

[Liu, Leo]

-Original Message-
From: mesa-dev-boun...@lists.freedesktop.org [mailto:mesa-dev-
boun...@lists.freedesktop.org] On Behalf Of Christian König
Sent: Saturday, March 01, 2014 7:11 AM
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] [PATCH] st/omx: always advertise all components

From: Christian König christian.koe...@amd.com


Reviewed-by: Leo Liu leo@amd.com

omx_component_library_Setup should return all entrypoints the library
implements, independent of what is available on the current hardware.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74944

Signed-off-by: Christian König christian.koe...@amd.com
---
 src/gallium/state_trackers/omx/entrypoint.c | 15 ++-
 src/gallium/state_trackers/omx/vid_enc.c| 41 +++--
 2 files changed, 23 insertions(+), 33 deletions(-)

diff --git a/src/gallium/state_trackers/omx/entrypoint.c
b/src/gallium/state_trackers/omx/entrypoint.c
index 52b2495..d6f149e 100644
--- a/src/gallium/state_trackers/omx/entrypoint.c
+++ b/src/gallium/state_trackers/omx/entrypoint.c
@@ -51,21 +51,22 @@ static unsigned omx_usecount = 0;  int
omx_component_library_Setup(stLoaderComponentType **stComponents)  {
OMX_ERRORTYPE r;
+   unsigned i = 0;

if (stComponents == NULL)
   return 2;

/* component 0 - video decoder */
-   r = vid_dec_LoaderComponent(stComponents[0]);
-   if (r != OMX_ErrorNone)
-  return r;
+   r = vid_dec_LoaderComponent(stComponents[i]);
+   if (r == OMX_ErrorNone)
+  ++i;

/* component 1 - video encoder */
-   r = vid_enc_LoaderComponent(stComponents[1]);
-   if (r != OMX_ErrorNone)
-  return r;
+   r = vid_enc_LoaderComponent(stComponents[i]);
+   if (r == OMX_ErrorNone)
+  ++i;

-   return 2;
+   return i;
 }

 struct vl_screen *omx_get_screen(void)
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index 3f1d01c..993ff57 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -95,53 +95,38 @@ static void vid_enc_name_avc(char
str[OMX_MAX_STRINGNAME_SIZE])

 OMX_ERRORTYPE vid_enc_LoaderComponent(stLoaderComponentType *comp)
{
-   struct vl_screen *vscreen = omx_get_screen();
-   struct pipe_screen *screen = vscreen ? vscreen-pscreen : NULL;
-
-   if (!screen)
-  return OMX_ErrorInsufficientResources;
-
comp-componentVersion.s.nVersionMajor = 0;
comp-componentVersion.s.nVersionMinor = 0;
comp-componentVersion.s.nRevision = 0;
comp-componentVersion.s.nStep = 1;
+   comp-name_specific_length = 1;
comp-constructor = vid_enc_Constructor;

-   if (screen-get_video_param(screen,
PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
- PIPE_VIDEO_ENTRYPOINT_ENCODE,
PIPE_VIDEO_CAP_SUPPORTED))
-  comp-name_specific_length = 1;
-   else
-  comp-name_specific_length = 0;
-
-   omx_put_screen();
-
comp-name = CALLOC(1, OMX_MAX_STRINGNAME_SIZE);
if (!comp-name)
   return OMX_ErrorInsufficientResources;

vid_enc_name(comp-name);

-   comp-name_specific = CALLOC(comp-name_specific_length, sizeof(char *));
+   comp-name_specific = CALLOC(1, sizeof(char *));
if (!comp-name_specific)
   goto error_arrays;

-   comp-role_specific = CALLOC(comp-name_specific_length, sizeof(char *));
+   comp-role_specific = CALLOC(1, sizeof(char *));
if (!comp-role_specific)
   goto error_arrays;

-   if (comp-name_specific_length) {
-  comp-name_specific[0] = CALLOC(1, OMX_MAX_STRINGNAME_SIZE);
-  if (!comp-name_specific[0])
- goto error_specific;
+   comp-name_specific[0] = CALLOC(1, OMX_MAX_STRINGNAME_SIZE);
+   if (!comp-name_specific[0])
+  goto error_specific;

-  vid_enc_name_avc(comp-name_specific[0]);
+   vid_enc_name_avc(comp-name_specific[0]);

-  comp-role_specific[0] = CALLOC(1, OMX_MAX_STRINGNAME_SIZE);
-  if (!comp-role_specific[0])
- goto error_specific;
+   comp-role_specific[0] = CALLOC(1, OMX_MAX_STRINGNAME_SIZE);
+   if (!comp-role_specific[0])
+  goto error_specific;

-  strcpy(comp-role_specific[0], OMX_VID_ENC_AVC_ROLE);
-   }
+   strcpy(comp-role_specific[0], OMX_VID_ENC_AVC_ROLE);

return OMX_ErrorNone;

@@ -189,6 +174,10 @@ static OMX_ERRORTYPE
vid_enc_Constructor(OMX_COMPONENTTYPE *comp, OMX_STRING nam
   return OMX_ErrorInsufficientResources;

screen = priv-screen-pscreen;
+   if (!screen-get_video_param(screen,
PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
+PIPE_VIDEO_ENTRYPOINT_ENCODE,
PIPE_VIDEO_CAP_SUPPORTED))
+  return OMX_ErrorBadParameter;
+
priv-s_pipe = screen-context_create(screen, priv-screen);
if (!priv-s_pipe)
   return OMX_ErrorInsufficientResources;
--
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev