Re: [Mesa-dev] [PATCH] egl/dri2: move wayland header inclusion where applicable

[Andy Furniss]

Emil Velikov wrote:

From: Emil Velikov <emil.veli...@collabora.com>

Instead of indirectly pulling the wayland headers everywhere, use
forward declarations and #include only as needed.

Should effectively fix build errors like the following:

make[5]: Entering directory
'/.../src/gallium/state_trackers/omx/tizonia'
CC   h264dprc.lo
In file included from h264dprc.c:45:0:
.../src/egl/drivers/dri2/egl_dri2.h:47:10: fatal error:
wayland/wayland-egl/wayland-egl-backend.h: No such file or directory
   #include "wayland/wayland-egl/wayland-egl-backend.h"

Cc: Andy Furniss <adf.li...@gmail.com>
Cc: Dylan Baker <dy...@pnwbakers.com>
Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
---
Dylan had epiphany a minute after I hit Send. Sorry about that.

Gents this should remove the need of any the following patches.
Please you give them a try, manually reverting the meson fix.


Autotools build is good for me with this patch.



Thanks!

https://patchwork.freedesktop.org/patch/208770/
https://patchwork.freedesktop.org/patch/208306/
https://patchwork.freedesktop.org/patch/208322/
---
  src/egl/drivers/dri2/egl_dri2.c |  1 +
  src/egl/drivers/dri2/egl_dri2.h | 12 +---
  src/egl/drivers/dri2/platform_wayland.c |  2 ++
  3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 864f7eb0c68..535806e4bfe 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -48,6 +48,7 @@
  #include 
  
  #ifdef HAVE_WAYLAND_PLATFORM

+#include 
  #include "wayland-drm.h"
  #include "wayland-drm-client-protocol.h"
  #include "linux-dmabuf-unstable-v1-client-protocol.h"
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index bd637f73c9d..adabc527f85 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -43,9 +43,15 @@
  #endif
  
  #ifdef HAVE_WAYLAND_PLATFORM

-#include 
-#include "wayland/wayland-egl/wayland-egl-backend.h"
-/* forward declarations of protocol elements */
+/* forward declarations to avoid pulling wayland headers everywhere */
+struct wl_egl_window;
+struct wl_event_queue;
+struct wl_callback;
+struct wl_display;
+struct wl_drm;
+struct wl_registry;
+struct wl_shm;
+struct wl_surface;
  struct zwp_linux_dmabuf_v1;
  #endif
  
diff --git a/src/egl/drivers/dri2/platform_wayland.c b/src/egl/drivers/dri2/platform_wayland.c

index 877f7933b9a..94f7defa657 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -49,6 +49,8 @@
  #include "wayland-drm-client-protocol.h"
  #include "linux-dmabuf-unstable-v1-client-protocol.h"
  
+#include "wayland/wayland-egl/wayland-egl-backend.h"

+
  #ifndef DRM_FORMAT_MOD_INVALID
  #define DRM_FORMAT_MOD_INVALID ((1ULL << 56) - 1)
  #endif



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

Re: [Mesa-dev] tizonia egl build fail

[Andy Furniss]

Dylan Baker wrote:

Quoting Andy Furniss (2018-03-06 15:12:37)

make[5]: Entering directory
'/mnt/sdc1/Gits/mesa/src/gallium/state_trackers/omx/tizonia'
CC   h264dprc.lo
In file included from h264dprc.c:45:0:
../../../../../src/egl/drivers/dri2/egl_dri2.h:47:10: fatal error:
wayland/wayland-egl/wayland-egl-backend.h: No such file or directory
   #include "wayland/wayland-egl/wayland-egl-backend.h"
^~~
compilation terminated.


below will fix the build - no idea if it breaks anything else/is sane.

diff --git a/src/egl/drivers/dri2/egl_dri2.h
b/src/egl/drivers/dri2/egl_dri2.h
index d36d02c3c4..3459216917 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -44,7 +44,7 @@

   #ifdef HAVE_WAYLAND_PLATFORM
   #include 
-#include "wayland/wayland-egl/wayland-egl-backend.h"
+#include "egl/wayland/wayland-egl/wayland-egl-backend.h"
   /* forward declarations of protocol elements */
   struct zwp_linux_dmabuf_v1;
   #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


I sent a patch to fix this for meson as well, but I just added -I/src/egl. It
would be better if we picked one way and did that.


As "just a user" I have no opinion/preference.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] tizonia egl build fail

[Andy Furniss]

make[5]: Entering directory 
'/mnt/sdc1/Gits/mesa/src/gallium/state_trackers/omx/tizonia'

  CC   h264dprc.lo
In file included from h264dprc.c:45:0:
../../../../../src/egl/drivers/dri2/egl_dri2.h:47:10: fatal error: 
wayland/wayland-egl/wayland-egl-backend.h: No such file or directory

 #include "wayland/wayland-egl/wayland-egl-backend.h"
  ^~~
compilation terminated.


below will fix the build - no idea if it breaks anything else/is sane.

diff --git a/src/egl/drivers/dri2/egl_dri2.h 
b/src/egl/drivers/dri2/egl_dri2.h

index d36d02c3c4..3459216917 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -44,7 +44,7 @@

 #ifdef HAVE_WAYLAND_PLATFORM
 #include 
-#include "wayland/wayland-egl/wayland-egl-backend.h"
+#include "egl/wayland/wayland-egl/wayland-egl-backend.h"
 /* forward declarations of protocol elements */
 struct zwp_linux_dmabuf_v1;
 #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Andy Furniss]

Zhang, Boyuan wrote:

Zhang, Boyuan wrote:


On 14/11/17 10:53, Andy Furniss wrote:

Zhang, Boyuan wrote:



-Original Message-
From: Zhang, Boyuan
Sent: November-13-17 11:41 AM
To: Andy Furniss; Koenig, Christian; Mark Thompson;
mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header
implementations

Zhang, Boyuan wrote:


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 5170c67..c6dc420 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -362,6 +362,233 @@ static void radeon_enc_quality_params(struct 
radeon_encoder *enc)
  RADEON_ENC_END();
  }
  +static void radeon_enc_nalu_sps(struct radeon_encoder
*enc) {
+RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
+RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
+uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
+radeon_enc_reset(enc);
+radeon_enc_set_emulation_prevention(enc, false);
+radeon_enc_code_fixed_bits(enc, 0x0001, 32);
+radeon_enc_code_fixed_bits(enc, 0x67, 8);
+radeon_enc_byte_align(enc);
+radeon_enc_set_emulation_prevention(enc, true);
+radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
+radeon_enc_code_fixed_bits(enc, 0x04, 8);

Please always set constraint_set1_flag when profile_idc is 66.  There are 
enough actually-constrained-baseline-but-not-marked-as-such streams in the 
world already to catch out decoders without full baseline support (that is, all 
of them).

Also, "constraint_set5_flag shall be equal to 0 when profile_idc is not equal to 77, 
88, 100, or 118".



[Boyuan] Thanks for pointing out. I modified the value to be 0x44 in the new 
patch (set1=1, and set5=1) since we only support constrained baseline for now.


It's not really with cabac though. I know there was a patch to turn it off - but 
that would have been wasteful and make linux < windows.

Why not use 77 if cabac is on + not set constrained bits, windows seems to set 
main.

Currently with vce trying to set main manually from ffmeg/gst in order to get something 
"correct" still sets flags = something that's not seen as main (but works).


Yes, but still the problem is cabac is not allowed for baseline profile and we 
only support baseline for now. I'm not quite sure about windows test you 
mentioned, I'm just guessing that we might have some main profile features 
support in some closed test environment on windows side, but definitely not all 
main profile features, no b frame support.
On linux side, we only support baseline profile for this vcn enc.
(fixed a typo)


   Yea, it's tricky, FWIW windows does not use b-frames for the test I've done 
(re-live turned up high = 50mbit 60fps).


I can get B-frames from AMF with a GCN 2 card on Windows.


Yes, we used to support b-frame for GCN2 (e.g. like Bonaire, Kabini, etc...) 
cards. But for later Asics, we dropped the b-frame support. Including this 
raven vcn encode, b-frame is still not supported according to our firmware team.
- Boyuan




It is flagged as main and uses cabac.
I guess main is the "correct" way to describe constrained baseline + cabac even 
if there are no other main features like b-frames.


Yes, I agree, that's the correct way in that case. However, we can't advertise 
main profile since we don't have b-frame support. It would cause serious 
problem if player tries to use b-frame when seeing that main profile is 
supported.


I guess you mean encoder rather than player - I don't think a player should 
care if there are no b-frames in main.

FWIW vainfo does currently advertise main/high support, IIRC it was mentioned 
in the past but lost in a long thread with many other issues in it.


I remember there was a discussion before about this, I will double check it and 
will probably make a patch to disable them if not yet disabled.



  So as explained before, we only support constrained baseline profile for this 
raven vcn encode now. And as a result, cabac is forced to be off in this 
bring-up patch.

Maybe advertise constrained baseline as encode + expose cabac switch that's in 
the vaapi spec and let the user/app decide to force that.

If cabac is on then flag the output as main.

Thanks for this idea, I could raise this in our meeting to discuss the possibility of doing this. Currently, 
"advertising constrained baseline only"  + "enabling cabac" at the same time doesn't sound like a 
"correct"/"perfect" way to me, I need more discussions with my team about this. Therefore, I will 
push the current patches, e.g. keep cabac disabled for now, to bring up this vcn encode if you are OK with it.
- Boyuan


Yea, fine, I am just discussing rather than trying to block - I don't 
even have a vcn card.



__

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Andy Furniss]

Zhang, Boyuan wrote:


On 14/11/17 10:53, Andy Furniss wrote:

Zhang, Boyuan wrote:



-Original Message-
From: Zhang, Boyuan
Sent: November-13-17 11:41 AM
To: Andy Furniss; Koenig, Christian; Mark Thompson; 
mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header 
implementations

Zhang, Boyuan wrote:


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 5170c67..c6dc420 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -362,6 +362,233 @@ static void radeon_enc_quality_params(struct 
radeon_encoder *enc)
 RADEON_ENC_END();
 }
 +static void radeon_enc_nalu_sps(struct radeon_encoder *enc) {
+RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
+RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
+uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
+radeon_enc_reset(enc);
+radeon_enc_set_emulation_prevention(enc, false);
+radeon_enc_code_fixed_bits(enc, 0x0001, 32);
+radeon_enc_code_fixed_bits(enc, 0x67, 8);
+radeon_enc_byte_align(enc);
+radeon_enc_set_emulation_prevention(enc, true);
+radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
+radeon_enc_code_fixed_bits(enc, 0x04, 8);

Please always set constraint_set1_flag when profile_idc is 66.  There are 
enough actually-constrained-baseline-but-not-marked-as-such streams in the 
world already to catch out decoders without full baseline support (that is, all 
of them).

Also, "constraint_set5_flag shall be equal to 0 when profile_idc is not equal to 77, 
88, 100, or 118".


[Boyuan] Thanks for pointing out. I modified the value to be 0x44 in the new 
patch (set1=1, and set5=1) since we only support constrained baseline for now.


It's not really with cabac though. I know there was a patch to turn it off - but 
that would have been wasteful and make linux < windows.

Why not use 77 if cabac is on + not set constrained bits, windows seems to set 
main.

Currently with vce trying to set main manually from ffmeg/gst in order to get something 
"correct" still sets flags = something that's not seen as main (but works).


Yes, but still the problem is cabac is not allowed for baseline profile and we 
only support baseline for now. I'm not quite sure about windows test you 
mentioned, I'm just guessing that we might have some main profile features 
support in some closed test environment on windows side, but definitely not all 
main profile features, no b frame support.
On linux side, we only support baseline profile for this vcn enc.
(fixed a typo)


  Yea, it's tricky, FWIW windows does not use b-frames for the test I've done 
(re-live turned up high = 50mbit 60fps).


I can get B-frames from AMF with a GCN 2 card on Windows.


Yes, we used to support b-frame for GCN2 (e.g. like Bonaire, Kabini, etc...) 
cards. But for later Asics, we dropped the b-frame support. Including this 
raven vcn encode, b-frame is still not supported according to our firmware team.
- Boyuan




It is flagged as main and uses cabac.
I guess main is the "correct" way to describe constrained baseline + cabac even 
if there are no other main features like b-frames.


Yes, I agree, that's the correct way in that case. However, we can't advertise 
main profile since we don't have b-frame support. It would cause serious 
problem if player tries to use b-frame when seeing that main profile is 
supported.


I guess you mean encoder rather than player - I don't think a player 
should care if there are no b-frames in main.


FWIW vainfo does currently advertise main/high support, IIRC it was 
mentioned in the past but lost in a long thread with many other issues 
in it.


 So as explained before, we only support constrained baseline profile 
for this raven vcn encode now. And as a result, cabac is forced to be 
off in this bring-up patch.


Maybe advertise constrained baseline as encode + expose cabac switch 
that's in the vaapi spec and let the user/app decide to force that.

If cabac is on then flag the output as main.

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

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Andy Furniss]

Mark Thompson wrote:

On 14/11/17 10:53, Andy Furniss wrote:

Zhang, Boyuan wrote:



-Original Message-
From: Zhang, Boyuan
Sent: November-13-17 11:41 AM
To: Andy Furniss; Koenig, Christian; Mark Thompson; 
mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header 
implementations

Zhang, Boyuan wrote:


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 5170c67..c6dc420 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -362,6 +362,233 @@ static void radeon_enc_quality_params(struct 
radeon_encoder *enc)
 RADEON_ENC_END();
 }
 +static void radeon_enc_nalu_sps(struct radeon_encoder *enc) {
+RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
+RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
+uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
+radeon_enc_reset(enc);
+radeon_enc_set_emulation_prevention(enc, false);
+radeon_enc_code_fixed_bits(enc, 0x0001, 32);
+radeon_enc_code_fixed_bits(enc, 0x67, 8);
+radeon_enc_byte_align(enc);
+radeon_enc_set_emulation_prevention(enc, true);
+radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
+radeon_enc_code_fixed_bits(enc, 0x04, 8);

Please always set constraint_set1_flag when profile_idc is 66.  There are 
enough actually-constrained-baseline-but-not-marked-as-such streams in the 
world already to catch out decoders without full baseline support (that is, all 
of them).

Also, "constraint_set5_flag shall be equal to 0 when profile_idc is not equal to 77, 
88, 100, or 118".


[Boyuan] Thanks for pointing out. I modified the value to be 0x44 in the new 
patch (set1=1, and set5=1) since we only support constrained baseline for now.


It's not really with cabac though. I know there was a patch to turn it off - but 
that would have been wasteful and make linux < windows.

Why not use 77 if cabac is on + not set constrained bits, windows seems to set 
main.

Currently with vce trying to set main manually from ffmeg/gst in order to get something 
"correct" still sets flags = something that's not seen as main (but works).


Yes, but still the problem is cabac is not allowed for baseline profile and we 
only support baseline for now. I'm not quite sure about windows test you 
mentioned, I'm just guessing that we might have some main profile features 
support in some closed test environment on windows side, but definitely not all 
main profile features, no b frame support.
On linux side, we only support baseline profile for this vcn enc.
(fixed a typo)


Yea, it's tricky, FWIW windows does not use b-frames for the test I've done 
(re-live turned up high = 50mbit 60fps).


I can get B-frames from AMF with a GCN 2 card on Windows.


Oh good, there is hope for newer cards at least, IIRC in the ffmpeg AMF 
thread, linux support for the future was mentioned.


I was just looking at what relive game recording did, I never tried/know 
how to use AMF.





It is flagged as main and uses cabac.
I guess main is the "correct" way to describe constrained baseline + cabac even 
if there are no other main features like b-frames.


Yes, it must be flagged as main in this case.


OK, thanks for the conformation.

FWIW I recorded xonotic big-key-bench demo at 60fps -qp 28, with and 
without cabac.
The cavlc version was 15% bigger than cabac, so it would be a shame to 
loose it.



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

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Andy Furniss]

Zhang, Boyuan wrote:



-Original Message-
From: Zhang, Boyuan
Sent: November-13-17 11:41 AM
To: Andy Furniss; Koenig, Christian; Mark Thompson; 
mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header 
implementations

Zhang, Boyuan wrote:


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 5170c67..c6dc420 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -362,6 +362,233 @@ static void radeon_enc_quality_params(struct 
radeon_encoder *enc)
RADEON_ENC_END();
}

+static void radeon_enc_nalu_sps(struct radeon_encoder *enc) {

+   RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
+   RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
+   uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
+   radeon_enc_reset(enc);
+   radeon_enc_set_emulation_prevention(enc, false);
+   radeon_enc_code_fixed_bits(enc, 0x0001, 32);
+   radeon_enc_code_fixed_bits(enc, 0x67, 8);
+   radeon_enc_byte_align(enc);
+   radeon_enc_set_emulation_prevention(enc, true);
+   radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
+   radeon_enc_code_fixed_bits(enc, 0x04, 8);

Please always set constraint_set1_flag when profile_idc is 66.  There are 
enough actually-constrained-baseline-but-not-marked-as-such streams in the 
world already to catch out decoders without full baseline support (that is, all 
of them).

Also, "constraint_set5_flag shall be equal to 0 when profile_idc is not equal to 77, 
88, 100, or 118".


[Boyuan] Thanks for pointing out. I modified the value to be 0x44 in the new 
patch (set1=1, and set5=1) since we only support constrained baseline for now.


It's not really with cabac though. I know there was a patch to turn it off - but 
that would have been wasteful and make linux < windows.

Why not use 77 if cabac is on + not set constrained bits, windows seems to set 
main.

Currently with vce trying to set main manually from ffmeg/gst in order to get something 
"correct" still sets flags = something that's not seen as main (but works).


Yes, but still the problem is cabac is not allowed for baseline profile and we 
only support baseline for now. I'm not quite sure about windows test you 
mentioned, I'm just guessing that we might have some main profile features 
support in some closed test environment on windows side, but definitely not all 
main profile features, no b frame support.
On linux side, we only support baseline profile for this vcn enc.
(fixed a typo)


Yea, it's tricky, FWIW windows does not use b-frames for the test I've 
done (re-live turned up high = 50mbit 60fps).

It is flagged as main and uses cabac.
I guess main is the "correct" way to describe constrained baseline + 
cabac even if there are no other main features like b-frames.



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

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Andy Furniss]

Zhang, Boyuan wrote:


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 5170c67..c6dc420 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -362,6 +362,233 @@ static void radeon_enc_quality_params(struct 
radeon_encoder *enc)
RADEON_ENC_END();
   }
   
+static void radeon_enc_nalu_sps(struct radeon_encoder *enc) {

+   RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
+   RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
+   uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
+   radeon_enc_reset(enc);
+   radeon_enc_set_emulation_prevention(enc, false);
+   radeon_enc_code_fixed_bits(enc, 0x0001, 32);
+   radeon_enc_code_fixed_bits(enc, 0x67, 8);
+   radeon_enc_byte_align(enc);
+   radeon_enc_set_emulation_prevention(enc, true);
+   radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
+   radeon_enc_code_fixed_bits(enc, 0x04, 8);

Please always set constraint_set1_flag when profile_idc is 66.  There are 
enough actually-constrained-baseline-but-not-marked-as-such streams in the 
world already to catch out decoders without full baseline support (that is, all 
of them).

Also, "constraint_set5_flag shall be equal to 0 when profile_idc is not equal to 77, 
88, 100, or 118".


[Boyuan] Thanks for pointing out. I modified the value to be 0x44 in the new 
patch (set1=1, and set5=1) since we only support constrained baseline for now.


It's not really with cabac though. I know there was a patch to turn it 
off - but that would have been wasteful and make linux < windows.


Why not use 77 if cabac is on + not set constrained bits, windows seems 
to set main.


Currently with vce trying to set main manually from ffmeg/gst in order 
to get something "correct" still sets flags = something that's not seen 
as main (but works).

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

Re: [Mesa-dev] mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!

[Andy Furniss]

Emil Velikov wrote:

On 7 November 2017 at 10:58, Andy Furniss <adf.li...@gmail.com> wrote:

IIRC this got (mostly) fixed up in the past and disappeared.

I don't know whether it counts as mesa's fault in all cases but kodi has
started provoking it again.

The kodi commit that it starts at is -

53b30b8a9dbb89573171c5827fbceb92ea255221
x11: factor out glx support

https://github.com/xbmc/xbmc/commit/53b30b8a9dbb89573171c5827fbceb92ea255221


The "mostly" above refers to ffmpeg compiled with opencl which will cause it
when using hwaccel like -

ffmpeg -hwaccel vdpau -i some-h264-vid 

opencl in ffmpeg is IIRC limited (de-shake?) and needs image anyway, so is
not actually useful.


To double-check - do you see behavioural changes, or it's simply the
annoyance of the line showing up?


Behavior is OK - just the message.


Does building Mesa with static LLVM (./configure ...
--disable-llvm-shared-libs ...) help?


Yes, both cases have no message with that.

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

Re: [Mesa-dev] mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!

[Andy Furniss]

Michel Dänzer wrote:

On 07/11/17 11:58 AM, Andy Furniss wrote:

IIRC this got (mostly) fixed up in the past and disappeared.

I don't know whether it counts as mesa's fault in all cases but kodi has
started provoking it again.

The kodi commit that it starts at is -

53b30b8a9dbb89573171c5827fbceb92ea255221
x11: factor out glx support

https://github.com/xbmc/xbmc/commit/53b30b8a9dbb89573171c5827fbceb92ea255221



The "mostly" above refers to ffmpeg compiled with opencl which will
cause it when using hwaccel like -

ffmpeg -hwaccel vdpau -i some-h264-vid 

opencl in ffmpeg is IIRC limited (de-shake?) and needs image anyway, so
is not actually useful.


This kind of error usually happens when a process ends up linking
multiple versions of LLVM. Maybe OpenGL and OpenCL link against
different versions of LLVM?


ldd /usr/lib/libOpenCL.so.1.0.0

libLLVM-6.0svn.so => /usr/lib/../lib64/libLLVM-6.0svn.so

glxinfo shows mesa is using 6.0.0

ldd on ffmpeg contains both libOpenCL.so.1 and libLLVM-6.0svn.so

ffmpeg is a side issue though - far more will see kodi (unless it's just 
me!)


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

[Mesa-dev] mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!

[Andy Furniss]

IIRC this got (mostly) fixed up in the past and disappeared.

I don't know whether it counts as mesa's fault in all cases but kodi has 
started provoking it again.


The kodi commit that it starts at is -

53b30b8a9dbb89573171c5827fbceb92ea255221
x11: factor out glx support

https://github.com/xbmc/xbmc/commit/53b30b8a9dbb89573171c5827fbceb92ea255221


The "mostly" above refers to ffmpeg compiled with opencl which will 
cause it when using hwaccel like -


ffmpeg -hwaccel vdpau -i some-h264-vid 

opencl in ffmpeg is IIRC limited (de-shake?) and needs image anyway, so 
is not actually useful.

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

Re: [Mesa-dev] Build fail since configure.ac: rework llvm libs handling for 3.9+

[Andy Furniss]

Michel Dänzer wrote:

On 18/10/17 05:41 PM, Emil Velikov wrote:

On 17 October 2017 at 15:39, Andy Furniss <adf.li...@gmail.com>
wrote:

Emil Velikov wrote:


On a "bad" build (-DLLVM_BUILD_LLVM_DYLIB=ON) I get

andy [~]$ llvm-config --link-shared --libs bitwriter 
llvm-config: error: missing: /usr/lib/libLLVMDemangle.so 
llvm-config: error: missing: /usr/lib/libLLVMSupport.so 
llvm-config: error: missing:

/usr/lib/libLLVMBinaryFormat.so llvm-config: error:
missing: /usr/lib/libLLVMCore.so llvm-config: error:
missing: /usr/lib/libLLVMBitReader.so llvm-config: error:
missing: /usr/lib/libLLVMMC.so llvm-config: error: missing:
/usr/lib/libLLVMMCParser.so llvm-config: error: missing:
/usr/lib/libLLVMObject.so llvm-config: error: missing:
/usr/lib/libLLVMProfileData.so llvm-config: error: missing:
/usr/lib/libLLVMAnalysis.so llvm-config: error: missing:
/usr/lib/libLLVMBitWriter.so



These here indicate that something in LLVM broke. Please report
it ASAP so that we don't get a LLVM release with this bug.



https://bugs.llvm.org/show_bug.cgi?id=34977


Great, thank you. In the interim please use the
LLVM_LINK_LLVM_DYLIB workaround. Just checked LLVM 5.0 w/o
LLVM_LINK_LLVM_DYLIB - seems to also be broken in the same way.

Considering distributions (checked Fedora, Arch, Ubuntu and
Debian) toggle both BUILD and LINK together, I'm inclined to keep
things as-is.


Right, I'd recommend enabling LLVM_LINK_LLVM_DYLIB anyway when 
LLVM_BUILD_LLVM_DYLIB is enabled. Is there any particular reason for 
enabling the latter but not the former?


No idea from a technical POV.

As a user, when cmake became mandatory, looking at the cmake docs
there is option BUILD_SHARED_LIBS - but it is noted not to use this

"BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If
you want to build LLVM as a shared library, you should use the
LLVM_BUILD_LLVM_DYLIB option."

I also notice that blfs use LLVM_BUILD_LLVM_DYLIB

http://www.linuxfromscratch.org/blfs/view/systemd/general/llvm.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Build fail since configure.ac: rework llvm libs handling for 3.9+

[Andy Furniss]

Emil Velikov wrote:

On 17 October 2017 at 13:40, Emil Velikov  wrote:


With both:
-DLLVM_BUILD_LLVM_DYLIB=ON and -DLLVM_LINK_LLVM_DYLIB=ON


Something's a bit strange:


... setting -DLLVM_LINK_LLVM_DYLIB=ON should also set
-DLLVM_BUILD_LLVM_DYLIB=ON [1].

If that's not the case please report it to the LLVM devs.


Seems OK, I only set -DLLVM_LINK_LLVM_DYLIB=ON to get working (had 
already seen that it auto enables the other).


Dieter specified both and got the same result = OK (unless I mis-read?)



Thanks
Emil

[1] https://llvm.org/docs/CMake.html



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

Re: [Mesa-dev] Build fail since configure.ac: rework llvm libs handling for 3.9+

[Andy Furniss]

Emil Velikov wrote:


On a "bad" build (-DLLVM_BUILD_LLVM_DYLIB=ON) I get

andy [~]$ llvm-config --link-shared --libs bitwriter
llvm-config: error: missing: /usr/lib/libLLVMDemangle.so
llvm-config: error: missing: /usr/lib/libLLVMSupport.so
llvm-config: error: missing: /usr/lib/libLLVMBinaryFormat.so
llvm-config: error: missing: /usr/lib/libLLVMCore.so
llvm-config: error: missing: /usr/lib/libLLVMBitReader.so
llvm-config: error: missing: /usr/lib/libLLVMMC.so
llvm-config: error: missing: /usr/lib/libLLVMMCParser.so
llvm-config: error: missing: /usr/lib/libLLVMObject.so
llvm-config: error: missing: /usr/lib/libLLVMProfileData.so
llvm-config: error: missing: /usr/lib/libLLVMAnalysis.so
llvm-config: error: missing: /usr/lib/libLLVMBitWriter.so


These here indicate that something in LLVM broke. Please report it
ASAP so that we don't get a LLVM release with this bug.


https://bugs.llvm.org/show_bug.cgi?id=34977

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

Re: [Mesa-dev] Build fail since configure.ac: rework llvm libs handling for 3.9+

[Andy Furniss]

Emil Velikov wrote:

On 16 October 2017 at 03:22, Jan Vesely <jan.ves...@rutgers.edu> wrote:

On Sun, 2017-10-15 at 00:00 +0100, Andy Furniss wrote:

Andy Furniss wrote:

Since

commit 13a53c4f5cdd664fd155c9e78fb46a4387af006c
Author: Emil Velikov <emil.veli...@collabora.com>
Date:   Thu Oct 5 11:19:05 2017 +0100

  configure.ac: rework llvm libs handling for 3.9+

I am getting 00s of

 /mesa/src/amd/common/. undefined reference to LLVM..

Using git llvm have tried with -DLLVM_APPEND_VC_REV=OFF

My llvm config =

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_BUILD_LLVM_DYLIB=ON


Build is OK with llvm built with -DLLVM_LINK_LLVM_DYLIB=ON


THis is weird. that option should only set whether llvm executables are
dynamically linked. is the llvm-config output different when you toggle
this setting?


Precisely what I was wondering as well.

Andy can you please share the output of the following commands across
your build combinations:
llvm-config --link-shared --libs bitwriter
llvm-config --link-static --libs bitwriter
llvm-config --link-static --system-libs


On a "bad" build (-DLLVM_BUILD_LLVM_DYLIB=ON) I get

andy [~]$ llvm-config --link-shared --libs bitwriter
llvm-config: error: missing: /usr/lib/libLLVMDemangle.so
llvm-config: error: missing: /usr/lib/libLLVMSupport.so
llvm-config: error: missing: /usr/lib/libLLVMBinaryFormat.so
llvm-config: error: missing: /usr/lib/libLLVMCore.so
llvm-config: error: missing: /usr/lib/libLLVMBitReader.so
llvm-config: error: missing: /usr/lib/libLLVMMC.so
llvm-config: error: missing: /usr/lib/libLLVMMCParser.so
llvm-config: error: missing: /usr/lib/libLLVMObject.so
llvm-config: error: missing: /usr/lib/libLLVMProfileData.so
llvm-config: error: missing: /usr/lib/libLLVMAnalysis.so
llvm-config: error: missing: /usr/lib/libLLVMBitWriter.so
andy [~]$
andy [~]$ llvm-config --link-static --libs bitwriter
-lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject 
-lLLVMMCParser -lLLVMMC -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat 
-lLLVMSupport -lLLVMDemangle

andy [~]$
andy [~]$ llvm-config --link-static --system-libs
-lrt -ldl -lcurses -lpthread -lz -lm

On a "good" (-DLLVM_LINK_LLVM_DYLIB=ON) I get

andy [~]$ llvm-config --link-shared --libs bitwriter
-lLLVM-6.0svn
andy [~]$ llvm-config --link-static --libs bitwriter
-lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject 
-lLLVMMCParser -lLLVMMC -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat 
-lLLVMSupport -lLLVMDemangle

andy [~]$ llvm-config --link-static --system-libs
-lrt -ldl -lcurses -lpthread -lz -lm
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Build fail since configure.ac: rework llvm libs handling for 3.9+

[Andy Furniss]

Andy Furniss wrote:

Since

commit 13a53c4f5cdd664fd155c9e78fb46a4387af006c
Author: Emil Velikov <emil.veli...@collabora.com>
Date:   Thu Oct 5 11:19:05 2017 +0100

 configure.ac: rework llvm libs handling for 3.9+

I am getting 00s of

 /mesa/src/amd/common/. undefined reference to LLVM..

Using git llvm have tried with -DLLVM_APPEND_VC_REV=OFF

My llvm config =

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_BUILD_LLVM_DYLIB=ON


Build is OK with llvm built with -DLLVM_LINK_LLVM_DYLIB=ON

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

[Mesa-dev] Build fail since configure.ac: rework llvm libs handling for 3.9+

[Andy Furniss]

Since

commit 13a53c4f5cdd664fd155c9e78fb46a4387af006c
Author: Emil Velikov 
Date:   Thu Oct 5 11:19:05 2017 +0100

configure.ac: rework llvm libs handling for 3.9+

I am getting 00s of

 /mesa/src/amd/common/. undefined reference to LLVM..

Using git llvm have tried with -DLLVM_APPEND_VC_REV=OFF

My llvm config =

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_BUILD_LLVM_DYLIB=ON


Mesa config

./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float 
--enable-opencl --with-egl-platforms=x11,drm,wayland 
--with-gallium-drivers=radeonsi,swrast --with-vulkan-drivers=radeon 
--enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers=


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

Re: [Mesa-dev] [PATCH 3/3] st/va: add RGB support to vlVaPutSurface

[Andy Furniss]

Tested-by: Andy Furniss <adf.li...@gmail.com>

Leo Liu wrote:

---
  src/gallium/state_trackers/va/surface.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 643cdcd54a..4c2f4b5452 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -280,6 +280,7 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID 
surface_id, void* draw, short s
 struct vl_screen *vscreen;
 struct u_rect src_rect, *dirty_area;
 struct u_rect dst_rect = {destx, destx + destw, desty, desty + desth};
+   enum pipe_format format;
 VAStatus status;
  
 if (!ctx)

@@ -318,8 +319,19 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID 
surface_id, void* draw, short s
 src_rect.x1 = srcw + srcx;
 src_rect.y1 = srch + srcy;
  
+   format = surf->buffer->buffer_format;

+
 vl_compositor_clear_layers(>cstate);
-   vl_compositor_set_buffer_layer(>cstate, >compositor, 0, surf->buffer, 
_rect, NULL, VL_COMPOSITOR_WEAVE);
+
+   if (format == PIPE_FORMAT_B8G8R8A8_UNORM || format == 
PIPE_FORMAT_B8G8R8X8_UNORM ||
+   format == PIPE_FORMAT_R8G8B8A8_UNORM || format == 
PIPE_FORMAT_R8G8B8X8_UNORM) {
+  struct pipe_sampler_view **views;
+
+  views = surf->buffer->get_sampler_view_planes(surf->buffer);
+  vl_compositor_set_rgba_layer(>cstate, >compositor, 0, views[0], 
_rect, NULL, NULL);
+   } else
+  vl_compositor_set_buffer_layer(>cstate, >compositor, 0, 
surf->buffer, _rect, NULL, VL_COMPOSITOR_WEAVE);
+
 vl_compositor_set_layer_dst_area(>cstate, 0, _rect);
 vl_compositor_render(>cstate, >compositor, surf_draw, 
dirty_area, true);
  



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

Re: [Mesa-dev] [PATCH v2 1/2] egl/wayland: Check queryImage return for wl_buffer

[Andy Furniss]

These are still a regression for me over git revert a65db0ad1c

weston-simple-egl works as does mpv opengl windowed.

The issue is that kodi or fullscreen mpv is mostly junk, IIRC from an 
old bug this is to do with direct scan out and tiling.


Daniel Stone wrote:

When creating a wl_buffer from a DRIImage, we extract all the DRIImage
information via queryImage. Check whether or not it actually succeeds,
either bailing out if the query was critical, or providing sensible
fallbacks for information which was not available in older DRIImage
versions.

Fixes: a65db0ad1c ("st/dri: don't expose modifiers in EGL if the driver doesn't 
implement them")
Fixes: 02cc359372 ("egl/wayland: Use linux-dmabuf interface for buffers")
Reported-by: Andy Furniss <adf.li...@gmail.com>
Cc: Marek Olšák <marek.ol...@amd.com>
Signed-off-by: Daniel Stone <dani...@collabora.com>
---
  src/egl/drivers/dri2/platform_wayland.c | 56 -
  1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 011dddfabf..04c04cc304 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -678,23 +678,37 @@ create_wl_buffer(struct dri2_egl_display *dri2_dpy,
   __DRIimage *image)
  {
 struct wl_buffer *ret;
+   EGLBoolean query;
 int width, height, fourcc, num_planes;
  
-   dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_WIDTH, );

-   dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_HEIGHT, );
-   dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_FOURCC, );
-   dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_NUM_PLANES,
-   _planes);
+   query = dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_WIDTH, 
);
+   query &= dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_HEIGHT,
+);
+   query &= dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_FOURCC,
+);
+   if (!query)
+  return NULL;
+
+   query = dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_NUM_PLANES,
+   _planes);
+   if (!query)
+  num_planes = 1;
  
 if (dri2_dpy->wl_dmabuf && dri2_dpy->image->base.version >= 15) {

struct zwp_linux_buffer_params_v1 *params;
int mod_hi, mod_lo;
int i;
  
-  dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_MODIFIER_UPPER,

-  _hi);
-  dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_MODIFIER_LOWER,
-  _lo);
+  query = dri2_dpy->image->queryImage(image,
+  __DRI_IMAGE_ATTRIB_MODIFIER_UPPER,
+  _hi);
+  query &= dri2_dpy->image->queryImage(image,
+   __DRI_IMAGE_ATTRIB_MODIFIER_LOWER,
+   _lo);
+  if (!query) {
+ mod_hi = DRM_FORMAT_MOD_INVALID >> 32;
+ mod_lo = DRM_FORMAT_MOD_INVALID & 0x;
+  }
  
/* We don't need a wrapper for wl_dmabuf objects, because we have to

 * create the intermediate params object; we can set the queue on this,
@@ -705,7 +719,8 @@ create_wl_buffer(struct dri2_egl_display *dri2_dpy,
  
for (i = 0; i < num_planes; i++) {

   __DRIimage *p_image;
- int stride, offset, fd;
+ int stride, offset;
+ int fd = -1;
  
   if (i == 0)

  p_image = image;
@@ -716,14 +731,25 @@ create_wl_buffer(struct dri2_egl_display *dri2_dpy,
  return NULL;
   }
  
- dri2_dpy->image->queryImage(p_image, __DRI_IMAGE_ATTRIB_FD, );

- dri2_dpy->image->queryImage(p_image, __DRI_IMAGE_ATTRIB_STRIDE,
- );
- dri2_dpy->image->queryImage(p_image, __DRI_IMAGE_ATTRIB_OFFSET,
- );
+ query = dri2_dpy->image->queryImage(p_image,
+ __DRI_IMAGE_ATTRIB_FD,
+ );
+ query &= dri2_dpy->image->queryImage(p_image,
+  __DRI_IMAGE_ATTRIB_STRIDE,
+  );
+ query &= dri2_dpy->image->queryImage(p_image,
+  __DRI_IMAGE_ATTRIB_OFFSET,
+  );
   if (image != p_image)
  dri2_dpy->image->destroyImage(p_image);
  
+ if (!query) {

+if (fd >= 0)
+   close(fd);
+zwp_l

Re: [Mesa-dev] [PATCH 1/2] st/va: don't re-allocate interlaced buffer with pakced YUV format

[Andy Furniss]

Hmm, maybe this could be extended to allow bgrx which works with vdpau 
but not -


mpv --vo=vaapi lines-576.png

Andy Furniss wrote:

Tested-by: Andy Furniss <adf.li...@gmail.com>

Leo Liu wrote:

It caused corruption, when vlVaPutImage putting YUV to the fields

Cc: mesa-sta...@lists.freedesktop.org
Cc: Andy Furniss <adf.li...@gmail.com>
---
  src/gallium/state_trackers/va/image.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c

index f87de8e5c4..84990d8a3d 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -487,10 +487,11 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID 
surface, VAImageID image,
   ((format != PIPE_FORMAT_YV12) || 
(surf->buffer->buffer_format != PIPE_FORMAT_NV12)) &&
   ((format != PIPE_FORMAT_IYUV) || 
(surf->buffer->buffer_format != PIPE_FORMAT_NV12))) {

struct pipe_video_buffer *tmp_buf;
-  struct pipe_video_buffer templat = surf->templat;
-  templat.buffer_format = format;
-  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, );
+  surf->templat.buffer_format = format;
+  if (format == PIPE_FORMAT_YUYV || format == PIPE_FORMAT_UYVY)
+ surf->templat.interlaced = false;
+  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, 
>templat);

if (!tmp_buf) {
   mtx_unlock(>mutex);
@@ -499,7 +500,6 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID 
surface, VAImageID image,

surf->buffer->destroy(surf->buffer);
surf->buffer = tmp_buf;
-  surf->templat.buffer_format = format;
 }
 views = surf->buffer->get_sampler_view_planes(surf->buffer);





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

Re: [Mesa-dev] [PATCH 1/2] st/va: don't re-allocate interlaced buffer with pakced YUV format

[Andy Furniss]

Tested-by: Andy Furniss <adf.li...@gmail.com>

Leo Liu wrote:

It caused corruption, when vlVaPutImage putting YUV to the fields

Cc: mesa-sta...@lists.freedesktop.org
Cc: Andy Furniss <adf.li...@gmail.com>
---
  src/gallium/state_trackers/va/image.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index f87de8e5c4..84990d8a3d 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -487,10 +487,11 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
   ((format != PIPE_FORMAT_YV12) || (surf->buffer->buffer_format != 
PIPE_FORMAT_NV12)) &&
   ((format != PIPE_FORMAT_IYUV) || (surf->buffer->buffer_format != 
PIPE_FORMAT_NV12))) {
struct pipe_video_buffer *tmp_buf;
-  struct pipe_video_buffer templat = surf->templat;
  
-  templat.buffer_format = format;

-  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, );
+  surf->templat.buffer_format = format;
+  if (format == PIPE_FORMAT_YUYV || format == PIPE_FORMAT_UYVY)
+ surf->templat.interlaced = false;
+  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, >templat);
  
if (!tmp_buf) {

   mtx_unlock(>mutex);
@@ -499,7 +500,6 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
  
surf->buffer->destroy(surf->buffer);

surf->buffer = tmp_buf;
-  surf->templat.buffer_format = format;
 }
  
 views = surf->buffer->get_sampler_view_planes(surf->buffer);




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

Re: [Mesa-dev] [PATCH 2/2] st/vdpau: don't re-allocate interlaced buffer with packed YUV format

[Andy Furniss]

Tested-by: Andy Furniss <adf.li...@gmail.com>

Leo Liu wrote:

It caused corruption, when vlVdpVideoSurfacePutBitsYCbCr putting YUV to the 
fields

Cc: mesa-sta...@lists.freedesktop.org
Cc: Andy Furniss <adf.li...@gmail.com>
---
  src/gallium/state_trackers/vdpau/surface.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/gallium/state_trackers/vdpau/surface.c 
b/src/gallium/state_trackers/vdpau/surface.c
index 884ae30831..c678eb7037 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -350,6 +350,8 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
  
   /* adjust the template parameters */

   p_surf->templat.buffer_format = nformat;
+ if (nformat == PIPE_FORMAT_YUYV || nformat == PIPE_FORMAT_UYVY)
+p_surf->templat.interlaced = false;
  
   /* and try to create the video buffer with the new format */

   p_surf->video_buffer = pipe->create_video_buffer(pipe, 
_surf->templat);



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

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

[Andy Furniss]

Marek Olšák wrote:

Can you test this?


My mpv test case is fixed by

radeonsi/uvd: fix planar formats broken since f70f6baaa3bb0f8b280ac2eaea69bb



Thanks,
Marek

On Fri, Sep 29, 2017 at 1:51 AM, Andy Furniss <adf.li...@gmail.com> wrote:

Mark Thompson wrote:


This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840.



I just bisected to this as it also breaks

mpv --hwdec=vdpau --vo=opengl

amdgpu: The CS has been rejected, see dmesg for more information (-22).
amdgpu: The CS has been cancelled because the context is lost.

[drm:amdgpu_uvd_cs_pass2 [amdgpu]] *ERROR* buffer (2) to small (8355840 /
12441600)!




---
This commit broke VAAPI surface export (found by bisection).  I think the
observed behaviour with playback is consistent with surfaces not being
updated some of the time, so something to do with sharing?  I tried setting
PIPE_BIND_SHARED on the surfaces explicitly, but that didn't help so I'm
somewhat unclear what's going on exactly.

I've included this patch in the series as a revert because it makes it
testable for other people, but it would be better if someone who understands
how these interact could have a look and decide how to fix it properly.

Thanks,

- Mark


   src/gallium/drivers/radeon/r600_buffer_common.c | 13 +
   src/gallium/drivers/radeon/r600_texture.c   |  4 
   2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index b3e60a46e4..706c7485c3 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -167,10 +167,12 @@ void si_init_resource_fields(struct
r600_common_screen *rscreen,
  RADEON_FLAG_GTT_WC;
 }
   - /* Displayable and shareable surfaces are not suballocated. */
-   if (res->b.b.bind & (PIPE_BIND_SHARED | PIPE_BIND_SCANOUT))
-   res->flags |= RADEON_FLAG_NO_SUBALLOC; /* shareable */
-   else
+   /* Only displayable single-sample textures can be shared between
+* processes. */
+   if (!(res->b.b.bind & (PIPE_BIND_SHARED | PIPE_BIND_SCANOUT)) &&
+   (res->b.b.target == PIPE_BUFFER ||
+res->b.b.nr_samples >= 2 ||
+rtex->surface.micro_tile_mode != RADEON_MICRO_MODE_DISPLAY))
 res->flags |= RADEON_FLAG_NO_INTERPROCESS_SHARING;
 /* If VRAM is just stolen system memory, allow both VRAM and
@@ -190,6 +192,9 @@ void si_init_resource_fields(struct r600_common_screen
*rscreen,
 if (rscreen->debug_flags & DBG_NO_WC)
 res->flags &= ~RADEON_FLAG_GTT_WC;
   + if (res->b.b.bind & PIPE_BIND_SHARED)
+   res->flags |= RADEON_FLAG_NO_SUBALLOC;
+
 /* Set expected VRAM and GART usage for the buffer. */
 res->vram_usage = 0;
 res->gart_usage = 0;
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index a9a1b2627e..829d105827 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -1219,6 +1219,10 @@ r600_texture_create_object(struct pipe_screen
*screen,
 si_init_resource_fields(rscreen, resource, rtex->size,
   rtex->surface.surf_alignment);
   + /* Displayable surfaces are not suballocated. */
+   if (resource->b.b.bind & PIPE_BIND_SCANOUT)
+   resource->flags |= RADEON_FLAG_NO_SUBALLOC;
+
 if (!si_alloc_resource(rscreen, resource)) {
 FREE(rtex);
 return NULL;



___
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] st/va: add dst rect to avoid scale on deint

[Andy Furniss]

Leo Liu wrote:



On 09/29/2017 07:40 AM, Andy Furniss wrote:

Leo Liu wrote:



On 2017-09-29 06:04 AM, Andy Furniss wrote:

Leo Liu wrote:
For 1080p video transcode, the height will be scaled to 1088 when 
deint

to progressive buffer. Set dst rect to make sure no scale.

Fixes: 3ad8687 "st/va: use new vl_compositor_yuv_deint_full() to 
deint"


Probably my test cases are lacking, but I can't see and difference 
with this. Do you have an example?

something like below, only transcode without postproc case.

`ffmpeg -y -vaapi_device /dev/dri/card0  -i 1080_in.mp4 -frames 100 
-an -vf 'format=nv12|vaapi,hwupload'  -c:v h264_vaapi -profile:v 578 
-bf 0 1080_out.mkv`


Ahh, software decode, I did check that but I was looking for a 
permanent thing - the first 2 frames swdec are 1088 with ffmpeg - 
quite hard to see.



Yes. Indeed.

Gstreamer must use more buffers or something as when it does this it 
bounces up and down over more frames before settling, so is more obvious.
Maybe that's how it manages to get dual instance speed, where ffmpeg 
only seems to get single instance speed.

Normally, we need more buffers to queue up if the engine is fast enough.

Can I have your RB or AB for the fix?


Seems good testing wise.

Acked-by: Andy Furniss adf.li...@gmail.com



Thanks,
Leo




With both it doesn't show with hardware decode.





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

Re: [Mesa-dev] [PATCH] st/va: add dst rect to avoid scale on deint

[Andy Furniss]

Leo Liu wrote:



On 2017-09-29 06:04 AM, Andy Furniss wrote:

Leo Liu wrote:

For 1080p video transcode, the height will be scaled to 1088 when deint
to progressive buffer. Set dst rect to make sure no scale.

Fixes: 3ad8687 "st/va: use new vl_compositor_yuv_deint_full() to deint"


Probably my test cases are lacking, but I can't see and difference 
with this. Do you have an example?

something like below, only transcode without postproc case.

`ffmpeg -y -vaapi_device /dev/dri/card0  -i 1080_in.mp4 -frames 100 -an 
-vf 'format=nv12|vaapi,hwupload'  -c:v h264_vaapi -profile:v 578 -bf 0 
1080_out.mkv`


Ahh, software decode, I did check that but I was looking for a permanent 
thing - the first 2 frames swdec are 1088 with ffmpeg - quite hard to see.


Gstreamer must use more buffers or something as when it does this it 
bounces up and down over more frames before settling, so is more obvious.
Maybe that's how it manages to get dual instance speed, where ffmpeg 
only seems to get single instance speed.


With both it doesn't show with hardware decode.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: add dst rect to avoid scale on deint

[Andy Furniss]

Andy Furniss wrote:

Leo Liu wrote:

For 1080p video transcode, the height will be scaled to 1088 when deint
to progressive buffer. Set dst rect to make sure no scale.

Fixes: 3ad8687 "st/va: use new vl_compositor_yuv_deint_full() to deint"


Probably my test cases are lacking, but I can't see and difference with 
this. Do you have an example?


I found a 1080i gstreamer case where this patch helps by avoiding some 
first frames bounce with it's "auto" (invoked by scale) bob deint.


Couldn't find anything with ffmpeg or 1080p gst transcode.

It does help gstreamer raw 1080 input, which also had some first frame 
issues, that I was soon going to report - most previous testing being 
with ffmpeg as gstreamer seemed to be all over the place to start with.






Signed-off-by: Leo Liu <leo@amd.com>
---
  src/gallium/state_trackers/va/picture.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c

index 5e794652a6..7427b98688 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -669,15 +669,15 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
if (context->decoder->entrypoint == 
PIPE_VIDEO_ENTRYPOINT_ENCODE) {

   if (old_buf->interlaced) {
-struct u_rect src_rect;
+struct u_rect src_rect, dst_rect;
-src_rect.x0 = 0;
-src_rect.y0 = 0;
-src_rect.x1 = surf->templat.width;
-src_rect.y1 = surf->templat.height;
+dst_rect.x0 = src_rect.x0 = 0;
+dst_rect.y0 = src_rect.y0 = 0;
+dst_rect.x1 = src_rect.x1 = surf->templat.width;
+dst_rect.y1 = src_rect.y1 = surf->templat.height;
  vl_compositor_yuv_deint_full(>cstate, 
>compositor,

   old_buf, surf->buffer,
- _rect, NULL, 
VL_COMPOSITOR_WEAVE);
+ _rect, _rect, 
VL_COMPOSITOR_WEAVE);

   } else
  /* Can't convert from progressive to interlaced yet */
  return VA_STATUS_ERROR_INVALID_SURFACE;





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

Re: [Mesa-dev] [PATCH] st/va: add dst rect to avoid scale on deint

[Andy Furniss]

Leo Liu wrote:

For 1080p video transcode, the height will be scaled to 1088 when deint
to progressive buffer. Set dst rect to make sure no scale.

Fixes: 3ad8687 "st/va: use new vl_compositor_yuv_deint_full() to deint"


Probably my test cases are lacking, but I can't see and difference with 
this. Do you have an example?




Signed-off-by: Leo Liu 
---
  src/gallium/state_trackers/va/picture.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 5e794652a6..7427b98688 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -669,15 +669,15 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
  
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {

   if (old_buf->interlaced) {
-struct u_rect src_rect;
+struct u_rect src_rect, dst_rect;
  
-src_rect.x0 = 0;

-src_rect.y0 = 0;
-src_rect.x1 = surf->templat.width;
-src_rect.y1 = surf->templat.height;
+dst_rect.x0 = src_rect.x0 = 0;
+dst_rect.y0 = src_rect.y0 = 0;
+dst_rect.x1 = src_rect.x1 = surf->templat.width;
+dst_rect.y1 = src_rect.y1 = surf->templat.height;
  vl_compositor_yuv_deint_full(>cstate, >compositor,
   old_buf, surf->buffer,
- _rect, NULL, VL_COMPOSITOR_WEAVE);
+ _rect, _rect, 
VL_COMPOSITOR_WEAVE);
   } else
  /* Can't convert from progressive to interlaced yet */
  return VA_STATUS_ERROR_INVALID_SURFACE;



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

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

[Andy Furniss]

Mark Thompson wrote:

This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840.


I just bisected to this as it also breaks

mpv --hwdec=vdpau --vo=opengl

amdgpu: The CS has been rejected, see dmesg for more information (-22).
amdgpu: The CS has been cancelled because the context is lost.

[drm:amdgpu_uvd_cs_pass2 [amdgpu]] *ERROR* buffer (2) to small (8355840 
/ 12441600)!




---
This commit broke VAAPI surface export (found by bisection).  I think the 
observed behaviour with playback is consistent with surfaces not being updated 
some of the time, so something to do with sharing?  I tried setting 
PIPE_BIND_SHARED on the surfaces explicitly, but that didn't help so I'm 
somewhat unclear what's going on exactly.

I've included this patch in the series as a revert because it makes it testable 
for other people, but it would be better if someone who understands how these 
interact could have a look and decide how to fix it properly.

Thanks,

- Mark


  src/gallium/drivers/radeon/r600_buffer_common.c | 13 +
  src/gallium/drivers/radeon/r600_texture.c   |  4 
  2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index b3e60a46e4..706c7485c3 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -167,10 +167,12 @@ void si_init_resource_fields(struct r600_common_screen 
*rscreen,
 RADEON_FLAG_GTT_WC;
}
  
-	/* Displayable and shareable surfaces are not suballocated. */

-   if (res->b.b.bind & (PIPE_BIND_SHARED | PIPE_BIND_SCANOUT))
-   res->flags |= RADEON_FLAG_NO_SUBALLOC; /* shareable */
-   else
+   /* Only displayable single-sample textures can be shared between
+* processes. */
+   if (!(res->b.b.bind & (PIPE_BIND_SHARED | PIPE_BIND_SCANOUT)) &&
+   (res->b.b.target == PIPE_BUFFER ||
+res->b.b.nr_samples >= 2 ||
+rtex->surface.micro_tile_mode != RADEON_MICRO_MODE_DISPLAY))
res->flags |= RADEON_FLAG_NO_INTERPROCESS_SHARING;
  
  	/* If VRAM is just stolen system memory, allow both VRAM and

@@ -190,6 +192,9 @@ void si_init_resource_fields(struct r600_common_screen 
*rscreen,
if (rscreen->debug_flags & DBG_NO_WC)
res->flags &= ~RADEON_FLAG_GTT_WC;
  
+	if (res->b.b.bind & PIPE_BIND_SHARED)

+   res->flags |= RADEON_FLAG_NO_SUBALLOC;
+
/* Set expected VRAM and GART usage for the buffer. */
res->vram_usage = 0;
res->gart_usage = 0;
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index a9a1b2627e..829d105827 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -1219,6 +1219,10 @@ r600_texture_create_object(struct pipe_screen *screen,
si_init_resource_fields(rscreen, resource, rtex->size,
  rtex->surface.surf_alignment);
  
+		/* Displayable surfaces are not suballocated. */

+   if (resource->b.b.bind & PIPE_BIND_SCANOUT)
+   resource->flags |= RADEON_FLAG_NO_SUBALLOC;
+
if (!si_alloc_resource(rscreen, resource)) {
FREE(rtex);
return NULL;



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

Re: [Mesa-dev] [PATCH] st/dri: don't expose modifiers in EGL if the driver doesn't implement them

[Andy Furniss]

Marek Olšák wrote:


Sorry too late, I pushed it.

I don't know if stable is affected.


It regresses things starting on radeonsi using weston eg.

mpv -

[vo/opengl/wayland] error occurred on the display fd: closing file 
descriptor


kodi -

terminate called after throwing an instance of 'std::system_error'
  what():  wl_display_dispatch_pending: Protocol error

weston-simple-egl -

[destroyed object]: error 7: importing the supplied dmabufs failed
Error sending request: Broken pipe
has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: move YUV content to deinterlaced buffer when reallocated for encoder

[Andy Furniss]

Leo Liu wrote:




+  }


Should we bail out with an error here when it's the other
way around?
Although I cannot think of any of case that to get buffer 
Interlaced now, It's still a good idea to bail out here

when it happnens Will add it in v4.


It's not a error when case like buffer is deinterlaced, and 
interlaced result from query. What we need to do is to do

nothing, just ignores. I have sent out v4, please ignore it,
it won't work.


Well that's not correct either.

When the buffer is allocated as progressive and the codec
doesn't supports that we should certainly do something.

Either bail out as an error when we encode because we can't
convert progressive->interlaced (just the other way around)
and/or reallocate for decoding.

Here is current situation for  transcode

Decoder allocate I buffers as preferred, then encoder prefers as
P buffers , so re-allocated them to P buffers. and then next
frame, decoder take P buffer, but not as preferred.

3 possible ways for decoder to go:

1. ignores the the Preferred, and keep buffer as P, and pipe
goes. V3 2. go for Preferred, and then do endless alloc/dealloc
frame by frame. V2 3. Bailout as error, the pipeline stops. V4


Won't have time to test till tomorrow but just getting one of the
cases I thought may work with this, that couldn't work with the
env, out.

ffmpeg can (in theory anyway) do -

hwdec -> hw deinterlace -> hw encode.

Possible?


Not sure about FFMpeg. Have you tried that before? I always use 
gstreamer for encode/transcode.


The env existed before ffmpeg vaapi could do it, so I expected and got
failiure.

IIRC with the env = 0 hwdec -> hw deint -> copy back raw nv12 worked,
but trying to get encode failed as expected without env = 1. It was a
while ago I tried, IIRC it was possible to hang GPU. I guess the deint

I don't know how, so haven't tried a gstreamer command that would do the
same.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: move YUV content to deinterlaced buffer when reallocated for encoder

[Andy Furniss]

Leo Liu wrote:



On 08/25/2017 03:16 PM, Christian König wrote:

Am 25.08.2017 um 17:15 schrieb Leo Liu:



On 08/25/2017 10:53 AM, Leo Liu wrote:



On 08/25/2017 02:57 AM, Christian König wrote:

Am 24.08.2017 um 20:49 schrieb Leo Liu:

v2: use deinterlace common function
v3: make sure deinterlace only

Signed-off-by: Leo Liu 
---
  src/gallium/state_trackers/va/picture.c | 22 --
  1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c

index 6c3c4fe..aa4062d 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -613,17 +613,22 @@ vlVaEndPicture(VADriverContextP ctx, 
VAContextID context_id)

 mtx_lock(>mutex);
 surf = handle_table_get(drv->htab, context->target_id);
 context->mpeg4.frame_num++;
-
 screen = context->decoder->context->screen;
 interlaced = screen->get_video_param(screen, 
context->decoder->profile,

context->decoder->entrypoint,
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
   if (surf->buffer->interlaced != interlaced) {
-  surf->templat.interlaced = screen->get_video_param(screen, 
context->decoder->profile,

- PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
- PIPE_VIDEO_CAP_PREFERS_INTERLACED);
-  realloc = true;
+  interlaced = screen->get_video_param(screen, 
context->decoder->profile,

+ context->decoder->entrypoint,
+ PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+  if (!interlaced) {
+ /* The current cases for buffer reallocation are
+all from the interlaced to the deinterlaced,
+and there is no case for the other way around */
+ surf->templat.interlaced = false;
+ realloc = true;
+  }


Should we bail out with an error here when it's the other way around?
Although I cannot think of any of case that to get buffer Interlaced 
now, It's still a good idea to bail out here when it happnens

Will add it in v4.


It's not a error when case like buffer is deinterlaced, and 
interlaced result from query. What we need to do is to do nothing, 
just ignores.

I have sent out v4, please ignore it, it won't work.


Well that's not correct either.

When the buffer is allocated as progressive and the codec doesn't 
supports that we should certainly do something.


Either bail out as an error when we encode because we can't convert 
progressive->interlaced (just the other way around) and/or reallocate 
for decoding.

Here is current situation for  transcode

Decoder allocate I buffers as preferred, then encoder prefers as P 
buffers , so re-allocated them to P buffers.

and then next frame, decoder take P buffer, but not as preferred.

3 possible ways for decoder to go:

1. ignores the the Preferred, and keep buffer as P, and pipe goes. V3
2. go for Preferred, and then do endless alloc/dealloc frame by frame. V2
3. Bailout as error, the pipeline stops. V4


Won't have time to test till tomorrow but just getting one of the cases
I thought may work with this, that couldn't work with the env, out.

ffmpeg can (in theory anyway) do -

hwdec -> hw deinterlace -> hw encode.

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

Re: [Mesa-dev] [PATCH] st/va: move YUV content to deinterlaced buffer when reallocated for encoder

[Andy Furniss]

Leo Liu wrote:

v2: use deinterlace common function
v3: make sure deinterlace only


Doesn't apply to master with git.

patch was less fussy

patch -p 1  < ~/Leo-va-interl-patches/02-3
patching file src/gallium/state_trackers/va/picture.c
Hunk #1 succeeded at 619 with fuzz 1 (offset 6 lines).
Hunk #2 succeeded at 662 (offset 17 lines).


Signed-off-by: Leo Liu 
---
  src/gallium/state_trackers/va/picture.c | 22 --
  1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 6c3c4fe..aa4062d 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -613,17 +613,22 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
 mtx_lock(>mutex);
 surf = handle_table_get(drv->htab, context->target_id);
 context->mpeg4.frame_num++;
-
 screen = context->decoder->context->screen;
 interlaced = screen->get_video_param(screen, context->decoder->profile,
  context->decoder->entrypoint,
  PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
  
 if (surf->buffer->interlaced != interlaced) {

-  surf->templat.interlaced = screen->get_video_param(screen, 
context->decoder->profile,
- 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
- 
PIPE_VIDEO_CAP_PREFERS_INTERLACED);
-  realloc = true;
+  interlaced = screen->get_video_param(screen, context->decoder->profile,
+   context->decoder->entrypoint,
+   PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+  if (!interlaced) {
+ /* The current cases for buffer reallocation are
+all from the interlaced to the deinterlaced,
+and there is no case for the other way around */
+ surf->templat.interlaced = false;
+ realloc = true;
+  }
 }
  
 if (u_reduce_video_profile(context->templat.profile) == PIPE_VIDEO_FORMAT_JPEG &&

@@ -640,13 +645,18 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
 }
  
 if (realloc) {

-  surf->buffer->destroy(surf->buffer);
+  struct pipe_video_buffer *old_buf = surf->buffer;
  
if (vlVaHandleSurfaceAllocate(ctx, surf, >templat) != VA_STATUS_SUCCESS) {

+ old_buf->destroy(old_buf);
   mtx_unlock(>mutex);
   return VA_STATUS_ERROR_ALLOCATION_FAILED;
}
  
+  if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE)

+ vl_compositor_yuv_deint(>cstate, >compositor, old_buf, 
surf->buffer);
+
+  old_buf->destroy(old_buf);
context->target = surf->buffer;
 }
  



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

Re: [Mesa-dev] [PATCH 1/3] st/omx: move YUV deinterlace function to common

[Andy Furniss]

Christian König wrote:

Am 24.08.2017 um 17:11 schrieb Leo Liu:

Signed-off-by: Leo Liu 


Reviewed-by: Christian König  for the series.

Andy do you want to test this? Should make VA-API transcoding simpler to 
use.


Oh, nice it will be great to loose that env.

I started testing before mention of v3 patch - but one thing they seem 
to have fixed is the


[drm:amdgpu_vce_cs_reloc [amdgpu]] *ERROR* BO to small for addr 
0x01000a 48 47


that I had with 2160p raw vid enc since

st/va: clear the video surface on allocation

:-)

I'll try with the latest version tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VDPAU issues in 17.2 and master, and a test request

[Andy Furniss]

Ilia Mirkin wrote:

On Mon, Aug 21, 2017 at 5:54 PM, Andy Furniss <adf.li...@gmail.com>
wrote:

Ilia Mirkin wrote:

As I don't have the hardware myself, I was hoping someone could 
confirm that this is a nouveau issue and not a more general one. 
Ideally this would be done by testing VDPAU on both radeonsi and

r600, as well as both the DRI3 and the DRI2 paths. Please use
mplayer for this, not mpv or mplayer2 or anything else -- all
those have various differences in how the rendering is done from
mplayer, which could account for a different final result.



Current svn mplayer + git ffmpeg, vdpau vo is OK for me on
radeonsi. Option "DRI3" "off" in amdgpu.conf for ddx is also OK.


Thanks, Andy. What version of mesa was this with?


This is with current git.

vdpau is the default (for me) with mplayer, and I have used it with git
mesas for a long time. Until yesterday I hadn't updated mplayer its self
for several months.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VDPAU issues in 17.2 and master, and a test request

[Andy Furniss]

Ilia Mirkin wrote:


As I don't have the hardware myself, I was hoping someone could
confirm that this is a nouveau issue and not a more general one.
Ideally this would be done by testing VDPAU on both radeonsi and r600,
as well as both the DRI3 and the DRI2 paths. Please use mplayer for
this, not mpv or mplayer2 or anything else -- all those have various
differences in how the rendering is done from mplayer, which could
account for a different final result.


Current svn mplayer + git ffmpeg, vdpau vo is OK for me on radeonsi.
Option "DRI3" "off" in amdgpu.conf for ddx is also OK.



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

Re: [Mesa-dev] [PATCH 1/2] st/omx_tizonia: add --enable-omx-tizonia flag and build files

[Andy Furniss]

Ahh, I didn't let it error out so didn't see it listed in the error message.
Though I've built tizonia I haven't installed yet because I wanted to remind
myself where bellagio is speed/function wise.
I am now a bit sidetracked with a couple of issues I found but will try 
it soon.


I did do a ./configure --help and it doesn't show up like that, which is 
why I asked.


Gurkirpal Singh wrote:

Hi,

The target tizonia is available with gst-omx on current git
https://cgit.freedesktop.org/gstreamer/gst-omx/commit/?id=ae14bb362a26bb1b48f7f99c7fc2350e0fa50ffa
The option --with-omx-target=tizonia should work.

Cheers

On Thu, Aug 17, 2017 at 4:39 AM, Andy Furniss <adf.li...@gmail.com> wrote:



One more question - WRT gst-omx, what target should I build -
generic or is something else/patch needed? I don't see tizonia with
current git.

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

Re: [Mesa-dev] [PATCH 1/2] st/omx_tizonia: add --enable-omx-tizonia flag and build files

[Andy Furniss]

Thanks, I'll try something similar.

One more question - WRT gst-omx, what target should I build -
generic or is something else/patch needed? I don't see tizonia with
current git.

Gurkirpal Singh wrote:

Hi,

It is a known issue that the player is hard to build. Juan suggested to
remove it from the build files
https://github.com/tizonia/tizonia-openmax-il/issues/248#issuecomment-232406388

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

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Andy Furniss]

Michel Dänzer wrote:

On 11/08/17 01:45 AM, Emil Velikov wrote:

On 9 August 2017 at 02:00, Michel Dänzer  wrote:

On 09/08/17 03:24 AM, Emil Velikov wrote:


I think we'd want to keep the best of both - just not sure how to
exactly do that.
--libs/--libfiles was completely busted with LLVM 3.9 and is back to
normal with 4.0.

Could we use that somehow?


This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
something else, please be more specific.


That's the thing - in some versions --libs is busted while for others
--libs/--libfiles.


Do you have any specific information about --libs being broken with
recent versions of LLVM? I though that was fixed long ago.



That said, patch does exactly what it says on the
Reviewed-by: Emil Velikov 


Thanks, pushed.


Don't know if this is expected or not, but llvm built like -

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON


now fails to build mesa (I also tried without vulkan and it still fails 
raseonsi IIRC).


 CXXLDlibvulkan_radeon.la
/usr/lib/libLLVMSupport.a(Process.cpp.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d): 
undefined reference to `setupterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78): 
undefined reference to `tigetnum'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81): 
undefined reference to `set_curterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89): 
undefined reference to `del_curterm'

collect2: error: ld returned 1 exit status

Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds 
OK with this commit reverted.


My mesa config =

./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float 
--enable-opencl --enable-omx --with-egl-platforms=x11,drm,wayland 
--with-gallium-drivers=radeonsi,swrast --with-vulkan-drivers=radeon 
--enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers=


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

Re: [Mesa-dev] [PATCH v2] pipe-loader: fix build of dynamic pipe-drivers

[Andy Furniss]

The v4 version of the patch that was committed still has regressed build 
for me.


Reverting and applying v2 still builds OK.

I now get -

Making all in targets/opencl
make[4]: Entering directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/opencl'
  CXXLDlibOpenCL.la
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driParseOptionInfo':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:719: multiple definition of 
`driParseOptionInfo'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:719: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driParseConfigFiles':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:990: multiple definition of 
`driParseConfigFiles'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:990: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driDestroyOptionCache':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1056: multiple definition of 
`driDestroyOptionCache'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1056: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driDestroyOptionInfo':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1040: multiple definition of 
`driDestroyOptionInfo'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1040: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driCheckOption':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1070: multiple definition of 
`driCheckOption'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1070: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driQueryOptionb':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1077: multiple definition of 
`driQueryOptionb'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1077: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driQueryOptioni':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1087: multiple definition of 
`driQueryOptioni'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1087: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driQueryOptionf':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1097: multiple definition of 
`driQueryOptionf'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1097: 
first defined here
../../../../src/util/.libs/libxmlconfig.a(libxmlconfig_la-xmlconfig.o): 
In function `driQueryOptionstr':
/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1107: multiple definition of 
`driQueryOptionstr'
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_dynamic.a(libxmlconfig_la-xmlconfig.o):/mnt/sdb1/Gits/mesa/src/util/xmlconfig.c:1107: 
first defined here

collect2: error: ld returned 1 exit status
Makefile:686: recipe for target 'libOpenCL.la' failed



Nicolai Hähnle wrote:

Thanks! I'll take that as a Tested-by.

On 02.08.2017 18:43, Andy Furniss wrote:

Building OK with this.


Nicolai Hähnle wrote:

From: Nicolai Hähnle <nicolai.haeh...@amd.com>

v2: add libxmlconfig.la to the dynamic pipe_radeonsi driver

Fixes: bc7f41e11d3 ("gallium: add pipe_screen_config to screen_create 
functions")

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102014
--
I believe this is the right place to add it; the error reported by
Andy was missing driQueryOptionb, which makes sense since this is now
used in si_pipe.c.
---
  src/gallium/targets/pipe-loader/Makefile.am | 1 +
  src/gallium/targets/pipe-loader/pipe_r300.c | 2 +-
  src/gallium/targets/pipe-loader/pipe_r600.c | 2 +-
  src/gallium/targets/pipe-loader/pipe_radeonsi.c | 4 ++--
  4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am

index 400b198..db492c5 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -146,6 +146,7 @@ pipe_radeonsi_la_LIBADD = \
  $(top_builddir)/src/gallium/drivers/radeon/libradeon.la \
  $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \
  $(top_b

Re: [Mesa-dev] [PATCH v2] pipe-loader: fix build of dynamic pipe-drivers

[Andy Furniss]

Hmm, been AFK, but now have actually installed as well as just testing 
build.


Testing with this and the patch that avoids segfaults for cl.

I am getting segfaults when using vdpau for video, so maybe that needs 
something similar.


Jan Vesely wrote:

The patch still causes segfaults because you pass NULL at
core/device.cpp:45
yet unconditionally access the pointer at pipe_loader.c:130

Jan

On Wed, 2017-08-02 at 18:44 +0200, Nicolai Hähnle wrote:

Thanks! I'll take that as a Tested-by.

On 02.08.2017 18:43, Andy Furniss wrote:

Building OK with this.

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

Re: [Mesa-dev] [PATCH v2] pipe-loader: fix build of dynamic pipe-drivers

[Andy Furniss]

Building OK with this.


Nicolai Hähnle wrote:

From: Nicolai Hähnle 

v2: add libxmlconfig.la to the dynamic pipe_radeonsi driver

Fixes: bc7f41e11d3 ("gallium: add pipe_screen_config to screen_create 
functions")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102014
--
I believe this is the right place to add it; the error reported by
Andy was missing driQueryOptionb, which makes sense since this is now
used in si_pipe.c.
---
  src/gallium/targets/pipe-loader/Makefile.am | 1 +
  src/gallium/targets/pipe-loader/pipe_r300.c | 2 +-
  src/gallium/targets/pipe-loader/pipe_r600.c | 2 +-
  src/gallium/targets/pipe-loader/pipe_radeonsi.c | 4 ++--
  4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am
index 400b198..db492c5 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -146,6 +146,7 @@ pipe_radeonsi_la_LIBADD = \
$(top_builddir)/src/gallium/drivers/radeon/libradeon.la \
$(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \
$(top_builddir)/src/amd/common/libamd_common.la \
+   $(top_builddir)/src/util/libxmlconfig.la \
$(LIBDRM_LIBS) \
$(RADEON_LIBS) \
$(AMDGPU_LIBS)
diff --git a/src/gallium/targets/pipe-loader/pipe_r300.c 
b/src/gallium/targets/pipe-loader/pipe_r300.c
index 0dcc019..8aa1ba8 100644
--- a/src/gallium/targets/pipe-loader/pipe_r300.c
+++ b/src/gallium/targets/pipe-loader/pipe_r300.c
@@ -9,7 +9,7 @@ create_screen(int fd, const struct pipe_screen_config *config)
  {
 struct radeon_winsys *sws;
  
-   sws = radeon_drm_winsys_create(fd, flags, r300_screen_create);

+   sws = radeon_drm_winsys_create(fd, config, r300_screen_create);
 return sws ? debug_screen_wrap(sws->screen) : NULL;
  }
  
diff --git a/src/gallium/targets/pipe-loader/pipe_r600.c b/src/gallium/targets/pipe-loader/pipe_r600.c

index 0eedde7..a6051aa 100644
--- a/src/gallium/targets/pipe-loader/pipe_r600.c
+++ b/src/gallium/targets/pipe-loader/pipe_r600.c
@@ -9,7 +9,7 @@ create_screen(int fd, const struct pipe_screen_config *config)
  {
 struct radeon_winsys *rw;
  
-   rw = radeon_drm_winsys_create(fd, flags, r600_screen_create);

+   rw = radeon_drm_winsys_create(fd, config, r600_screen_create);
 return rw ? debug_screen_wrap(rw->screen) : NULL;
  }
  
diff --git a/src/gallium/targets/pipe-loader/pipe_radeonsi.c b/src/gallium/targets/pipe-loader/pipe_radeonsi.c

index 2d33d0e..2defc52 100644
--- a/src/gallium/targets/pipe-loader/pipe_radeonsi.c
+++ b/src/gallium/targets/pipe-loader/pipe_radeonsi.c
@@ -12,10 +12,10 @@ create_screen(int fd, const struct pipe_screen_config 
*config)
 struct radeon_winsys *rw;
  
 /* First, try amdgpu. */

-   rw = amdgpu_winsys_create(fd, flags, radeonsi_screen_create);
+   rw = amdgpu_winsys_create(fd, config, radeonsi_screen_create);
  
 if (!rw)

-  rw = radeon_drm_winsys_create(fd, flags, radeonsi_screen_create);
+  rw = radeon_drm_winsys_create(fd, config, radeonsi_screen_create);
  
 return rw ? debug_screen_wrap(rw->screen) : NULL;

  }



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

Re: [Mesa-dev] Build error since gallium: add pipe_screen_config to screen_create functions

[Andy Furniss]

Never mind, I see this is already reported on dri-devel

Andy Furniss wrote:
make[4]: Entering directory 
'/mnt/sdb1/Gits/mesa/src/gallium/targets/pipe-loader'

   CC   pipe_radeonsi.lo
pipe_radeonsi.c: In function ‘create_screen’:
pipe_radeonsi.c:15:34: error: ‘flags’ undeclared (first use in this 
function)

 rw = amdgpu_winsys_create(fd, flags, radeonsi_screen_create);
   ^
pipe_radeonsi.c:15:34: note: each undeclared identifier is reported only 
once for each function it appears in

Makefile:991: recipe for target 'pipe_radeonsi.lo' failed


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

[Mesa-dev] Build error since gallium: add pipe_screen_config to screen_create functions

[Andy Furniss]

make[4]: Entering directory 
'/mnt/sdb1/Gits/mesa/src/gallium/targets/pipe-loader'

  CC   pipe_radeonsi.lo
pipe_radeonsi.c: In function ‘create_screen’:
pipe_radeonsi.c:15:34: error: ‘flags’ undeclared (first use in this 
function)

rw = amdgpu_winsys_create(fd, flags, radeonsi_screen_create);
  ^
pipe_radeonsi.c:15:34: note: each undeclared identifier is reported only 
once for each function it appears in

Makefile:991: recipe for target 'pipe_radeonsi.lo' failed
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: change frame_idx from array to hash table

[Andy Furniss]

Christian König wrote:

Leo and Boyuan can you take a quick look as well? On first glance looks 
totally sane to me.


This reminds me .

I don't know what's special about my setup, but I haven't been able to 
use gst + vce properly since March.


As I said at the time -

https://lists.freedesktop.org/archives/mesa-dev/2017-March/148216.html

I did ping as well, but never quite got round to doing a bug.

I guess devs who tests vce with gstreamer don't see this?

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

Re: [Mesa-dev] [PATCH] st/mesa: add a winsys buffers list in st_context

[Andy Furniss]

OK, thanks, I missed that.

Brian Paul wrote:
A patch to fix this was already posted and reviewed.  I'll push it soon 
since I think Michel is off-line this time of day.


-Brian

On 07/13/2017 09:17 AM, Andy Furniss wrote:

This breaks startx on radeonsi for me on a R9 285.

[  5297.130] (II) glamor: OpenGL accelerated X.org driver based.
[  5297.132] (II) glamor: EGL version 1.5 (DRI2):
[  5297.133] (EE)
[  5297.133] (EE) Backtrace:
[  5297.151] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x584069]
[  5297.164] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f667a45768f]
[  5297.165] (EE) 2: /usr/lib/dri/radeonsi_dri.so
(st_framebuffer_reuse_or_create.isra.8+0x19a) [0x7f6673aa441a]
[  5297.166] (EE) 3: /usr/lib/dri/radeonsi_dri.so
(st_api_make_current+0x2e) [0x7f6673aa463e]
[  5297.168] (EE) 4: /usr/lib/dri/radeonsi_dri.so (driBindContext+0x36)
[0x7f6673bdfdd6]
[  5297.168] (EE) 5: /usr/lib/../lib64/libEGL.so.1
(dri2_make_current+0x113) [0x7f666bb23c23]
[  5297.168] (EE) 6: /usr/lib/../lib64/libEGL.so.1
(eglMakeCurrent+0x2a3) [0x7f666bb15123]
[  5297.181] (EE) 7: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_init+0x2c9) [0x7f666c03c8a9]
[  5297.189] (EE) 8: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(amdgpu_glamor_pre_init+0x4f) [0x7f667524266f]
[  5297.190] (EE) 9: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(AMDGPUPreInit_KMS+0x70d) [0x7f667523aa7d]
[  5297.191] (EE) 10: /usr/libexec/Xorg (InitOutput+0xa9b) [0x477f1b]
[  5297.192] (EE) 11: /usr/libexec/Xorg (dix_main+0x1c6) [0x439106]
[  5297.194] (EE) 12: /lib/libc.so.6 (__libc_start_main+0xf0)
[0x7f667a4445e0]
[  5297.194] (EE) 13: /usr/libexec/Xorg (_start+0x29) [0x424649]
[  5297.194] (EE)
[  5297.194] (EE) Segmentation fault at address 0x490
[  5297.195] (EE)
Fatal server error:
[  5297.195] (EE) Caught signal 11 (Segmentation fault). Server aborting

Charmaine Lee wrote:

Commit a5e733c6b52e93de3000647d075f5ca2f55fcb71 fixes the dangling
framebuffer object by unreferencing the window system draw/read buffers
when context is released. However this can prematurely destroy the
resources associated with these window system buffers. The problem is
reproducible with Turbine Demo running with VMware driver. In this case,
the depth buffer content was lost when the context is rebound to a
drawable.

To prevent premature destroy of the resources associated with
window system buffers, this patch maintains a list of these buffers in
the context, making sure the reference counts of these buffers will not
reach zero until the associated framebuffer interface objects no
longer exist. This also helps to avoid unnecessary destruction and
re-construction of the resources associated with the framebuffer.

Fixes VMware bug 1909807.
---
  src/gallium/include/state_tracker/st_api.h|  5 +++
  src/gallium/state_trackers/dri/dri_drawable.c |  4 ++
  src/gallium/state_trackers/wgl/stw_st.c   |  4 +-
  src/mesa/state_tracker/st_context.c   | 22 ++
  src/mesa/state_tracker/st_context.h   |  7 
  src/mesa/state_tracker/st_manager.c   | 59
++-
  src/mesa/state_tracker/st_manager.h   |  4 ++
  7 files changed, 94 insertions(+), 11 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h
b/src/gallium/include/state_tracker/st_api.h
index d641092..3fd5f01 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -311,6 +311,11 @@ struct st_framebuffer_iface
 int32_t stamp;
 /**
+* Identifier that uniquely identifies the framebuffer interface
object.
+*/
+   uint32_t ID;
+
+   /**
  * Available for the state tracker manager to use.
  */
 void *st_manager_private;
diff --git a/src/gallium/state_trackers/dri/dri_drawable.c
b/src/gallium/state_trackers/dri/dri_drawable.c
index 3c2e307..0cfdc30 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/dri_drawable.c
@@ -38,6 +38,8 @@
  #include "util/u_memory.h"
  #include "util/u_inlines.h"
+static uint32_t drifb_ID = 0;
+
  static void
  swap_fences_unref(struct dri_drawable *draw);
@@ -155,6 +157,7 @@ dri_create_buffer(__DRIscreen * sPriv,
 dPriv->driverPrivate = (void *)drawable;
 p_atomic_set(>base.stamp, 1);
+   drawable->base.ID = p_atomic_inc_return(_ID);
 return GL_TRUE;
  fail:
@@ -177,6 +180,7 @@ dri_destroy_buffer(__DRIdrawable * dPriv)
 swap_fences_unref(drawable);
+   drawable->base.ID = 0;
 FREE(drawable);
  }
diff --git a/src/gallium/state_trackers/wgl/stw_st.c
b/src/gallium/state_trackers/wgl/stw_st.c
index 7806a2a..c2844b0 100644
--- a/src/gallium/state_trackers/wgl/stw_st.c
+++ b/src/gallium/state_trackers/wgl/stw_st.c
@@ -46,7 +46,7 @@ struct stw_st_framebuffer {
 unsigned texture_mask;
  };
-
+static uint32_t stwfb_ID = 0;
  /**
   * Is the given mutex held by the calling thread?
@@ -234,6 +234,7 @@ stw_st_create_framebuffer(struct stw_framebuffer 
*fb)

Re: [Mesa-dev] [PATCH] st/mesa: add a winsys buffers list in st_context

[Andy Furniss]

This breaks startx on radeonsi for me on a R9 285.

[  5297.130] (II) glamor: OpenGL accelerated X.org driver based.
[  5297.132] (II) glamor: EGL version 1.5 (DRI2):
[  5297.133] (EE)
[  5297.133] (EE) Backtrace:
[  5297.151] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x584069]
[  5297.164] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f667a45768f]
[  5297.165] (EE) 2: /usr/lib/dri/radeonsi_dri.so 
(st_framebuffer_reuse_or_create.isra.8+0x19a) [0x7f6673aa441a]
[  5297.166] (EE) 3: /usr/lib/dri/radeonsi_dri.so 
(st_api_make_current+0x2e) [0x7f6673aa463e]
[  5297.168] (EE) 4: /usr/lib/dri/radeonsi_dri.so (driBindContext+0x36) 
[0x7f6673bdfdd6]
[  5297.168] (EE) 5: /usr/lib/../lib64/libEGL.so.1 
(dri2_make_current+0x113) [0x7f666bb23c23]
[  5297.168] (EE) 6: /usr/lib/../lib64/libEGL.so.1 
(eglMakeCurrent+0x2a3) [0x7f666bb15123]
[  5297.181] (EE) 7: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_egl_init+0x2c9) [0x7f666c03c8a9]
[  5297.189] (EE) 8: /usr/lib/xorg/modules/drivers/amdgpu_drv.so 
(amdgpu_glamor_pre_init+0x4f) [0x7f667524266f]
[  5297.190] (EE) 9: /usr/lib/xorg/modules/drivers/amdgpu_drv.so 
(AMDGPUPreInit_KMS+0x70d) [0x7f667523aa7d]

[  5297.191] (EE) 10: /usr/libexec/Xorg (InitOutput+0xa9b) [0x477f1b]
[  5297.192] (EE) 11: /usr/libexec/Xorg (dix_main+0x1c6) [0x439106]
[  5297.194] (EE) 12: /lib/libc.so.6 (__libc_start_main+0xf0) 
[0x7f667a4445e0]

[  5297.194] (EE) 13: /usr/libexec/Xorg (_start+0x29) [0x424649]
[  5297.194] (EE)
[  5297.194] (EE) Segmentation fault at address 0x490
[  5297.195] (EE)
Fatal server error:
[  5297.195] (EE) Caught signal 11 (Segmentation fault). Server aborting

Charmaine Lee wrote:

Commit a5e733c6b52e93de3000647d075f5ca2f55fcb71 fixes the dangling
framebuffer object by unreferencing the window system draw/read buffers
when context is released. However this can prematurely destroy the
resources associated with these window system buffers. The problem is
reproducible with Turbine Demo running with VMware driver. In this case,
the depth buffer content was lost when the context is rebound to a
drawable.

To prevent premature destroy of the resources associated with
window system buffers, this patch maintains a list of these buffers in
the context, making sure the reference counts of these buffers will not
reach zero until the associated framebuffer interface objects no
longer exist. This also helps to avoid unnecessary destruction and
re-construction of the resources associated with the framebuffer.

Fixes VMware bug 1909807.
---
  src/gallium/include/state_tracker/st_api.h|  5 +++
  src/gallium/state_trackers/dri/dri_drawable.c |  4 ++
  src/gallium/state_trackers/wgl/stw_st.c   |  4 +-
  src/mesa/state_tracker/st_context.c   | 22 ++
  src/mesa/state_tracker/st_context.h   |  7 
  src/mesa/state_tracker/st_manager.c   | 59 ++-
  src/mesa/state_tracker/st_manager.h   |  4 ++
  7 files changed, 94 insertions(+), 11 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index d641092..3fd5f01 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -311,6 +311,11 @@ struct st_framebuffer_iface
 int32_t stamp;
  
 /**

+* Identifier that uniquely identifies the framebuffer interface object.
+*/
+   uint32_t ID;
+
+   /**
  * Available for the state tracker manager to use.
  */
 void *st_manager_private;
diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
b/src/gallium/state_trackers/dri/dri_drawable.c
index 3c2e307..0cfdc30 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/dri_drawable.c
@@ -38,6 +38,8 @@
  #include "util/u_memory.h"
  #include "util/u_inlines.h"
  
+static uint32_t drifb_ID = 0;

+
  static void
  swap_fences_unref(struct dri_drawable *draw);
  
@@ -155,6 +157,7 @@ dri_create_buffer(__DRIscreen * sPriv,
  
 dPriv->driverPrivate = (void *)drawable;

 p_atomic_set(>base.stamp, 1);
+   drawable->base.ID = p_atomic_inc_return(_ID);
  
 return GL_TRUE;

  fail:
@@ -177,6 +180,7 @@ dri_destroy_buffer(__DRIdrawable * dPriv)
  
 swap_fences_unref(drawable);
  
+   drawable->base.ID = 0;

 FREE(drawable);
  }
  
diff --git a/src/gallium/state_trackers/wgl/stw_st.c b/src/gallium/state_trackers/wgl/stw_st.c

index 7806a2a..c2844b0 100644
--- a/src/gallium/state_trackers/wgl/stw_st.c
+++ b/src/gallium/state_trackers/wgl/stw_st.c
@@ -46,7 +46,7 @@ struct stw_st_framebuffer {
 unsigned texture_mask;
  };
  
-

+static uint32_t stwfb_ID = 0;
  
  /**

   * Is the given mutex held by the calling thread?
@@ -234,6 +234,7 @@ stw_st_create_framebuffer(struct stw_framebuffer *fb)
  
 stwfb->fb = fb;

 stwfb->stvis = fb->pfi->stvis;
+   stwfb->base.ID = p_atomic_inc_return(_ID);
  
 stwfb->base.visual = >stvis;

 p_atomic_set(>base.stamp, 1);
@@ -255,6 +256,7 @@ 

Re: [Mesa-dev] configure fails to find llvm since recent llvm commit.

[Andy Furniss]

Emil Velikov wrote:

On 3 July 2017 at 16:31, Andy Furniss <adf.li...@gmail.com> wrote:

Rafael Avila de Espindola wrote:


What check is configure doing?



Not sure just a user.


Is the llvm build a clean one? What is the value of LLVM_APPEND_VC_REV?



It is a clean build.
A reply to the list advised to start using

-DLLVM_APPEND_VC_REV=OFF

With this it is OK.


Skimming through the LLVM it's not obvious what is the before/after
output of `llvm-config --version'. Can anyone share some examples?


On current git head, well it was when I started the build from clean, 
probably not by now :-)


Without -DLLVM_APPEND_VC_REV=OFF the output is

5.0.0git-5a8feb7

With it, it's

5.0.0svn


It sounds like one decided to omit the "svn" (or equivalent) from the
string returned, while the DSO still has it.

Speaking of breakage - 3.9.1 has broken llvm-config
--libnames/libfiles [1] ... sigh.
If there's a for 3.9.2 we might want to nominate it ;-)

-Emil



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

Re: [Mesa-dev] configure fails to find llvm since recent llvm commit.

[Andy Furniss]

Rafael Avila de Espindola wrote:

What check is configure doing?


Not sure just a user.


Is the llvm build a clean one? What is the value of LLVM_APPEND_VC_REV?


It is a clean build.
A reply to the list advised to start using

-DLLVM_APPEND_VC_REV=OFF

With this it is OK.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] configure fails to find llvm since recent llvm commit.

[Andy Furniss]

Laurent Carlier wrote:

Le lundi 3 juillet 2017, 13:53:12 CEST Andy Furniss a écrit :

Don't know if mesa needs changing or it's an llvm needs fixing issue,
but since llvm commit

commit 78fbc18aed8024139cb87c5db69ab5b43dc615d6
Author: Rafael Espindola <rafael.espind...@gmail.com>
Date:   Fri Jun 30 18:48:33 2017 +

  Completely disable git/svn version checking if not needed.

  Working with git on a branch I find it really annoying that committing
  a change causes ninja to think that stuff needs to be rebuilt.

  With this change at least nothing in llvm needs to be rebuild when
  something is committed.

  git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306858
91177308-0d34-0410-b5e6-96231b3b80d8

configuring mesa bails after failing to find llvm shared libs (and gives
outdated suggestion). Shared libs are installed.

checking for AMDGPU... yes
configure: error: Could not find llvm shared libraries:
  Please make sure you have built llvm with the --enable-shared
option
  and that your llvm libraries are installed in /usr/lib
  If you have installed your llvm libraries to a different
directory you
  can use the --with-llvm-prefix= configure flag to specify this
directory.
  NOTE: Mesa is attempting to use llvm shared libraries by default.
  If you do not want to build with llvm shared libraries and
instead want to
  use llvm static libraries then add --disable-llvm-shared-libs
to your configure
  invocation and rebuild.
___


It's a llvm change, you need to add -DLLVM_APPEND_VC_REV=OFF when you build
llvm, It should fix the issue.


Ahh, thanks for the info.

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

[Mesa-dev] configure fails to find llvm since recent llvm commit.

[Andy Furniss]

Don't know if mesa needs changing or it's an llvm needs fixing issue, 
but since llvm commit


commit 78fbc18aed8024139cb87c5db69ab5b43dc615d6
Author: Rafael Espindola 
Date:   Fri Jun 30 18:48:33 2017 +

Completely disable git/svn version checking if not needed.

Working with git on a branch I find it really annoying that committing
a change causes ninja to think that stuff needs to be rebuilt.

With this change at least nothing in llvm needs to be rebuild when
something is committed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306858 
91177308-0d34-0410-b5e6-96231b3b80d8


configuring mesa bails after failing to find llvm shared libs (and gives 
outdated suggestion). Shared libs are installed.


checking for AMDGPU... yes
configure: error: Could not find llvm shared libraries:
Please make sure you have built llvm with the --enable-shared 
option

and that your llvm libraries are installed in /usr/lib
If you have installed your llvm libraries to a different 
directory you
can use the --with-llvm-prefix= configure flag to specify this 
directory.

NOTE: Mesa is attempting to use llvm shared libraries by default.
If you do not want to build with llvm shared libraries and 
instead want to
use llvm static libraries then add --disable-llvm-shared-libs 
to your configure

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

Re: [Mesa-dev] [PATCH] radeonsi: don't emit partial flushes at the end of IBs (v2)

[Andy Furniss]

Marek Olšák wrote:

Hi guys,

Can you please re-apply the problematic commit and test whether 
R600_DEBUG=noce fixes the corruption?


It doesn't help valley, it does make the specific artifact I posted
disappear, but there are still others on different scenes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: don't emit partial flushes at the end of IBs (v2)

[Andy Furniss]

Dieter Nützel wrote:

Addendum:

Only wild shot in the dark...

Could it be the LLVM (gfx9) thing, too?


I think it's just this commit, with more confidence as sees it as well.

I was a bit off llvm head when I first saw it, updated to head in case
it changed things - hit the assert bug, found and reverted that commit.



In a rush.

Dieter

Am 23.06.2017 14:56, schrieb Dieter Nützel:

Hello Andy,

do you have a screenshot handy? I get maybe the same artifacts on
Unigine Valley (in the trees?) on my RX580 but without _this_ patch
applied. I have other 'new' one from 'Patchwork Mesa' in.


Valley, is normally OK for me. Tricky to get a screen shot as the
artifacts are single frame flashes - though they do repeat. Other scenes
seem to have less noticeable ones than this from scene 2.

Ignore image quality - this is a shot from a paused x11grab h264
ultrafast preset compressed video made with ffmpeg.

https://drive.google.com/open?id=0BxP5-S1t9VEETWNDdzZ3NFp0M1k
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: don't emit partial flushes at the end of IBs (v2)

[Andy Furniss]

Marek Olšák wrote:

From: Marek Olšák 

The kernel sort of does the same thing with fences.

v2: do emit partial flushes on SI


Bugzilla seems to be down currently so replying here.

On R9 285 with current agd5f 4.13-wip kernel I get some slight
artifacts on Unigine Valley since this.

Valley is run 1920x1080 full screen everything on/highest settings.

Artifacts start scene 2 with rare brief flashes of blue chequered patches.



---
  src/gallium/drivers/radeonsi/si_hw_context.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c 
b/src/gallium/drivers/radeonsi/si_hw_context.c
index 345825a..76b295f 100644
--- a/src/gallium/drivers/radeonsi/si_hw_context.c
+++ b/src/gallium/drivers/radeonsi/si_hw_context.c
@@ -122,27 +122,31 @@ void si_context_gfx_flush(void *context, unsigned flags,
}
  
  	ctx->gfx_flush_in_progress = true;
  
  	/* This CE dump should be done in parallel with the last draw. */

if (ctx->ce_ib)
si_ce_save_all_descriptors_at_ib_end(ctx);
  
  	r600_preflush_suspend_features(>b);
  
-	ctx->b.flags |= SI_CONTEXT_CS_PARTIAL_FLUSH |

-   SI_CONTEXT_PS_PARTIAL_FLUSH;
-
/* DRM 3.1.0 doesn't flush TC for VI correctly. */
-   if (ctx->b.chip_class == VI && ctx->b.screen->info.drm_minor <= 1)
-   ctx->b.flags |= SI_CONTEXT_INV_GLOBAL_L2 |
+   if (ctx->b.chip_class == VI && ctx->b.screen->info.drm_minor <= 1) {
+   ctx->b.flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
+   SI_CONTEXT_CS_PARTIAL_FLUSH |
+   SI_CONTEXT_INV_GLOBAL_L2 |
SI_CONTEXT_INV_VMEM_L1;
+   } else if (ctx->b.chip_class == SI) {
+   /* The kernel doesn't wait for idle before doing SURFACE_SYNC. 
*/
+   ctx->b.flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
+   SI_CONTEXT_CS_PARTIAL_FLUSH;
+   }
  
  	si_emit_cache_flush(ctx);
  
  	if (ctx->trace_buf)

si_trace_emit(ctx);
  
  	if (ctx->is_debug) {

/* Save the IB for debug contexts. */
radeon_clear_saved_cs(>last_gfx);
radeon_save_cs(ws, cs, >last_gfx);



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

Re: [Mesa-dev] [PATCH] radeon/video: only support h264 baseline encode

[Andy Furniss]

Christian König wrote:

Am 04.04.2017 um 18:40 schrieb Andy Furniss:

Well it's a tricky situation with cabac which would be a shame to loose.

Yeah, completely agree.



Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support 


As noted before mbaff isn't so much of a problem. I mean the stream
wouldn't be what the application requested, but it would still be
correctly encoded.

The bigger problem is that we can't convince our firmware team to
support B-frames.

I've added my manager and going to raise the topic on our next
multimedia call once more.


Thanks, it would be really good to have b-frames (like the competition).



Regards,
Christian.



As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ffmpeg or gstreamer (ignoring current mesa issue).

... -c:v h264_vaapi -profile:v 77 -bf 0 ...

... max-bframes=0 ! video/x-h264, profile=main ...


Christian König wrote:

Am 04.04.2017 um 17:38 schrieb boyuan.zh...@amd.com:

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/drivers/radeon/radeon_video.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c
b/src/gallium/drivers/radeon/radeon_video.c
index 605a2c7..02e8dcf 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -221,7 +221,7 @@ int rvid_get_video_param(struct pipe_screen
*screen,
  if (entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
  switch (param) {
  case PIPE_VIDEO_CAP_SUPPORTED:
-return codec == PIPE_VIDEO_FORMAT_MPEG4_AVC &&
+return profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE &&
  rvce_is_fw_version_supported(rscreen);
  case PIPE_VIDEO_CAP_NPOT_TEXTURES:
  return 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] radeon/video: only support h264 baseline encode

[Andy Furniss]

Andy Furniss wrote:

Well it's a tricky situation with cabac which would be a shame to loose.

Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support 

As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ffmpeg or gstreamer (ignoring current mesa issue).

... -c:v h264_vaapi -profile:v 77 -bf 0 ...

... max-bframes=0 ! video/x-h264, profile=main ...


Hmm, maybe some tweaking would be needed for that to work properly
testing shows that it comes out as 88 - maybe to do with the constrained
flags being set in the driver that's expecting baseline?





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

Re: [Mesa-dev] [PATCH] radeon/video: only support h264 baseline encode

[Andy Furniss]

Andy Furniss wrote:

Well it's a tricky situation with cabac which would be a shame to loose.

Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support 

As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ffmpeg or gstreamer (ignoring current mesa issue).

... -c:v h264_vaapi -profile:v 77 -bf 0 ...


FWIW ffmpeg actually detects the lack of b-frame support, omitting -bf 0
from above will throw an error.

[h264_vaapi @ 0x3075aa0] B frames are not supported (0x1).

I guess that means that gstreamer could in theory do the same.

Looking at a ReLive sample shows it's flagged as main, has cabac
and doesn't have any b-frames.

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

Re: [Mesa-dev] [PATCH] radeon/video: only support h264 baseline encode

[Andy Furniss]

Well it's a tricky situation with cabac which would be a shame to loose.

Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support 

As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ffmpeg or gstreamer (ignoring current mesa issue).

... -c:v h264_vaapi -profile:v 77 -bf 0 ...

... max-bframes=0 ! video/x-h264, profile=main ...


Christian König wrote:

Am 04.04.2017 um 17:38 schrieb boyuan.zh...@amd.com:

From: Boyuan Zhang 

Signed-off-by: Boyuan Zhang 


Reviewed-by: Christian König 


---
  src/gallium/drivers/radeon/radeon_video.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c
b/src/gallium/drivers/radeon/radeon_video.c
index 605a2c7..02e8dcf 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -221,7 +221,7 @@ int rvid_get_video_param(struct pipe_screen *screen,
  if (entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
  switch (param) {
  case PIPE_VIDEO_CAP_SUPPORTED:
-return codec == PIPE_VIDEO_FORMAT_MPEG4_AVC &&
+return profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE &&
  rvce_is_fw_version_supported(rscreen);
  case PIPE_VIDEO_CAP_NPOT_TEXTURES:
  return 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 08/11] st/va: clear the video surface on allocation

[Andy Furniss]

Andy Furniss wrote:

ping.


Christian König wrote:

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

This makes debugging of decoding problems quite a bit easier.


This breaks gstreamer encode for me.

ffmpeg is OK, but then IIRC ffmpeg only uses one of something that
gstreamer uses two of, not wishing to get too technical here :-)

Whatever the cause, gst is twice as fast as ffmpeg and with this
I get -

[drm:amdgpu_vce_cs_reloc [amdgpu]] *ERROR* BO to small for addr
0x01000b 48 47

andy [vce-tests]$ time gst-launch-1.0 -f filesrc
location=/mnt/ramdisk/trees-1440p50.nv12 blocksize=5529600 !
video/x-raw,format=NV12,width=2560,height=1440,framerate=50/1,pixel-aspect-ratio=1/1
! queue ! vaapih264enc  rate-control=cbr bitrate=1
keyframe-period=25 max-bframes=0 ! video/x-h264, profile=main ! filesink
location=/mnt/ramdisk/gst.264
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
Pipeline is PREROLLING ...
Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context,
gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\
vaapidisplayglx1";
0:00:01.134997848   790  0x19310f0 ERROR   vaapivideomemory
gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
create a VA derived image from surface 0x7fefcc002b70
amdgpu: The CS has been rejected, see dmesg for more information (-22).
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
0:00:01.157992874   790 0x7fefcc0028a0 ERRORvaapiencode
gstvaapiencode.c:210:gst_vaapiencode_default_alloc_buffer: invalid
GstVaapiCodedBuffer size (0 bytes)
amdgpu: The CS has been cancelled because the context is lost.
0:00:01.161509344   790 0x7fefcc0028a0 ERRORvaapiencode
gstvaapiencode.c:316:gst_vaapiencode_push_frame: failed to allocate
encoded buffer in system memory
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.




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

Re: [Mesa-dev] [PATCH 3/3] targets/va: export radeon winsys_create functions

[Andy Furniss]

Andy Furniss wrote:


I've not verified that, no. If it doesn't fix the bug, we still need
this patch because of aforementioned reasons, and then we have to fix
the bug.


It fixes mpv for me testing vaapi hw decode + gl display.

It doesn't fix ffmpeg cli though.

ffmpeg  -hwaccel vaapi -i testfile -f null -

still gets the message.


So this seems to be because I compile ffmpeg with --enable-opencl

Built without that there is no message.


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

Re: [Mesa-dev] [PATCH 3/3] targets/va: export radeon winsys_create functions

[Andy Furniss]

Marek Olšák wrote:

On Fri, Mar 24, 2017 at 12:24 PM, Emil Velikov  wrote:

On 24 March 2017 at 11:02, Nicolai Hähnle  wrote:

On 24.03.2017 01:00, Marek Olšák wrote:


From: Marek Olšák 

This should fix this radeonsi error:
  "mesa: for the -simplifycfg-sink-common option: may only occur zero or
one
   times!"

Can we have some commit message. Feel free to reuse the following:

Earlier commit added a LLVM 4.0 workaround by passing
-simplifycfg-sink-common=false to LLVM.
When using multiple drivers, for example GL/dri and VAAPI, we may end
up with the option being parsed multiple times.
Hence we'll see errors like

  "mesa: for the -simplifycfg-sink-common option: may only occur zero or one
   times!"

Workaround this by exporting the driver entry point. This will lead to
the function being called once.

Fixes: 7751ed39e40 ("radeonsi: disable sinking common instructions
down to the end block")


---
 src/gallium/targets/va/va.sym | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/targets/va/va.sym b/src/gallium/targets/va/va.sym
index c925b2e..b19bc36 100644
--- a/src/gallium/targets/va/va.sym
+++ b/src/gallium/targets/va/va.sym
@@ -1,6 +1,8 @@
 {
global:
__vaDriverInit_*_*;
+   radeon_drm_winsys_create;
+   amdgpu_winsys_create;


Please add a reference to the si_shader_tgsi_setup.c and vice-versa.
Otherwise we will end up removing one but not the other.


It's actually not a workaround. It's a fix of va.sym that happens to
fix that bug and it would be the correct thing to do even if there was
no issue. Thus, I think a reference to si_shader_tgsi_setup is
unnecessary. I'm not fixing the bug here. I'm just enforcing one
screen+winsys per device per process like we already do between GL and
VDPAU.






Oof, that's ugly, but at least it's only a change to va and the chance of
collision is low. Have you verified that it fixes the bug?


I've not verified that, no. If it doesn't fix the bug, we still need
this patch because of aforementioned reasons, and then we have to fix
the bug.


It fixes mpv for me testing vaapi hw decode + gl display.

It doesn't fix ffmpeg cli though.

ffmpeg  -hwaccel vaapi -i testfile -f null -

still gets the message.


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

Re: [Mesa-dev] [PATCH] radeonsi: disable sinking common instructions down to the end block

[Andy Furniss]

Samuel Pitoiset wrote:

This patch has a minor issue for me using radeonsi on tonga.

ffmpeg vaapi hwdecode by cli or via mpv now produces the message

mesa: for the -simplifycfg-sink-common option: may only occur zero or 
one times!




On 03/15/2017 02:01 PM, Marek Olšák wrote:

On Wed, Mar 15, 2017 at 1:56 PM, Samuel Pitoiset
 wrote:



On 03/15/2017 01:51 PM, Marek Olšák wrote:


On Wed, Mar 15, 2017 at 1:21 AM, Samuel Pitoiset
 wrote:


Initially this was a workaround for a bug introduced in LLVM 4.0
in the SimplifyCFG pass that caused image instrinsics to disappear
(because they were badly sunk). Finally, this is a win because it
decreases SGPR spilling and increases the number of waves a bit.

Although, shader-db results are good I think we might want to
remove it in the future once the issue is fixed. For now, enable
it for LLVM >= 4.0.

This also fixes a rendering issue with the speedometer in Dirt Rally.

More information can be found here https://reviews.llvm.org/D26348.

Thanks to Dave Airlie for the patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99484
Signed-off-by: Samuel Pitoiset 
---

For those interested, here's the full shader-db report:

https://hastebin.com/osepehehat.pas

 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 5c63b732b3..4fb7a126e4 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 

 /* Data for if/else/endif and bgnloop/endloop control flow
structures.
  */
@@ -124,6 +125,11 @@ static void init_amdgpu_target()
LLVMInitializeAMDGPUTarget();
LLVMInitializeAMDGPUTargetMC();
LLVMInitializeAMDGPUAsmPrinter();
+
+#if HAVE_LLVM >= 0x0400
+   const char *argv[2] = {"mesa",
"-simplifycfg-sink-common=false"};
+   LLVMParseCommandLineOptions(2, argv, NULL);
+#endif



Would it possible to do:
if (HAVE_LLVM >= 0x0400) {
...
}

Also, Cc stable?



Your call. But if the issue is fixed at some point in 4.0.1 or 5.0 we
will
need to backport one more patch.


Since this only disables the problematic optimization, we can keep it
in stable and we won't have to backport anything else. (optimizations
are usually not accepted in stable)


Fine by me. I will add the cc tag and the FIXME comment before pushing.
Thanks.



Marek


___
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 08/11] st/va: clear the video surface on allocation

[Andy Furniss]

Christian König wrote:

From: Christian König 

This makes debugging of decoding problems quite a bit easier.


This breaks gstreamer encode for me.

ffmpeg is OK, but then IIRC ffmpeg only uses one of something that
gstreamer uses two of, not wishing to get too technical here :-)

Whatever the cause, gst is twice as fast as ffmpeg and with this
I get -

[drm:amdgpu_vce_cs_reloc [amdgpu]] *ERROR* BO to small for addr 
0x01000b 48 47


andy [vce-tests]$ time gst-launch-1.0 -f filesrc 
location=/mnt/ramdisk/trees-1440p50.nv12 blocksize=5529600 ! 
video/x-raw,format=NV12,width=2560,height=1440,framerate=50/1,pixel-aspect-ratio=1/1 
! queue ! vaapih264enc  rate-control=cbr bitrate=1 
keyframe-period=25 max-bframes=0 ! video/x-h264, profile=main ! filesink 
location=/mnt/ramdisk/gst.264

libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
Pipeline is PREROLLING ...
Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context, 
gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ 
vaapidisplayglx1";
0:00:01.134997848   790  0x19310f0 ERROR   vaapivideomemory 
gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot 
create a VA derived image from surface 0x7fefcc002b70

amdgpu: The CS has been rejected, see dmesg for more information (-22).
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
0:00:01.157992874   790 0x7fefcc0028a0 ERRORvaapiencode 
gstvaapiencode.c:210:gst_vaapiencode_default_alloc_buffer: invalid 
GstVaapiCodedBuffer size (0 bytes)

amdgpu: The CS has been cancelled because the context is lost.
0:00:01.161509344   790 0x7fefcc0028a0 ERRORvaapiencode 
gstvaapiencode.c:316:gst_vaapiencode_push_frame: failed to allocate 
encoded buffer in system memory

amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.
amdgpu: The CS has been cancelled because the context is lost.


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

Re: [Mesa-dev] [PATCH] gallium/targets: rework the empty targets removal

[Andy Furniss]

Emil Velikov wrote:

From: Emil Velikov <emil.veli...@collabora.com>

Earlier commit added extra tracking and we've attempted to remove the
vdpau/other folder if empty. V2 of said commit dropped the pipe
to /dev/null and the explicit "true" override.

Sadly both of those are needed since there's no guarantee that the
folder will be empty before we [mesa] make install.

Since we're bringing those two back, there's no need to track if we've
installed anything, and simply do "rm -d foo/ &>/dev/null || true"

Cc: Andy Furniss <adf.li...@gmail.com>
Reported-by: Andy Furniss <adf.li...@gmail.com>
Fixes: 1cd4fde053 ("gallium/targets: don't leave an empty target 
directory(ies)")
Signed-off-by: Emil Velikov <emil.veli...@collabora.com>


Make install works OK for me with this.


---
 src/gallium/targets/dri/Makefile.am   | 3 +--
 src/gallium/targets/vdpau/Makefile.am | 3 +--
 src/gallium/targets/xvmc/Makefile.am  | 3 +--
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/gallium/targets/dri/Makefile.am 
b/src/gallium/targets/dri/Makefile.am
index 4d92f45e42..459459ebed 100644
--- a/src/gallium/targets/dri/Makefile.am
+++ b/src/gallium/targets/dri/Makefile.am
@@ -139,12 +139,11 @@ endif
 # gallium_dri.so in the set of final installed files.
 install-data-hook:
for i in $(TARGET_DRIVERS); do  \
-   has_drivers=1;  \
ln -f $(DESTDIR)$(dridir)/gallium_dri.so\
  $(DESTDIR)$(dridir)/$${i}_dri.so; \
done;   \
$(RM) $(DESTDIR)$(dridir)/gallium_dri.*;\
-   test $${has_drivers} -eq 1 || $(RM) -d $(DESTDIR)$(dridir)
+   $(RM) -d $(DESTDIR)$(dridir) &>/dev/null || true

 uninstall-hook:
for i in $(TARGET_DRIVERS); do  \
diff --git a/src/gallium/targets/vdpau/Makefile.am 
b/src/gallium/targets/vdpau/Makefile.am
index a0f310bc59..cd7ef982aa 100644
--- a/src/gallium/targets/vdpau/Makefile.am
+++ b/src/gallium/targets/vdpau/Makefile.am
@@ -108,7 +108,6 @@ endif
 install-data-hook:
$(AM_V_GEN)dest_dir=$(DESTDIR)/$(vdpaudir); \
for i in $(TARGET_DRIVERS); do  \
-   has_drivers=1;  \
j=libvdpau_gallium.$(LIB_EXT);  \
k=libvdpau_$${i}.$(LIB_EXT);\
l=$${k}.$(VDPAU_MAJOR).$(VDPAU_MINOR).0;\
@@ -122,7 +121,7 @@ install-data-hook:
   $${dest_dir}/$${k};  \
done;   \
$(RM) $${dest_dir}/libvdpau_gallium.*;  \
-   test $${has_drivers} -eq 1 || $(RM) -d $${dest_dir}
+   $(RM) -d $${dest_dir} &>/dev/null || true

 uninstall-hook:
for i in $(TARGET_DRIVERS); do  \
diff --git a/src/gallium/targets/xvmc/Makefile.am 
b/src/gallium/targets/xvmc/Makefile.am
index b65a191eab..e29dd6a5ca 100644
--- a/src/gallium/targets/xvmc/Makefile.am
+++ b/src/gallium/targets/xvmc/Makefile.am
@@ -70,7 +70,6 @@ endif
 install-data-hook:
$(AM_V_GEN)dest_dir=$(DESTDIR)/$(xvmcdir);  \
for i in $(TARGET_DRIVERS); do  \
-   has_drivers=1;  \
j=libXvMCgallium.$(LIB_EXT);\
k=libXvMC$${i}.$(LIB_EXT);  \
l=$${k}.$(XVMC_MAJOR).$(XVMC_MINOR).0;  \
@@ -84,7 +83,7 @@ install-data-hook:
   $${dest_dir}/$${k};  \
done;   \
$(RM) $${dest_dir}/libXvMCgallium.*;\
-   test $${has_drivers} -eq 1 || $(RM) -d $${dest_dir}
+   $(RM) -d $${dest_dir} &>/dev/null || true

 uninstall-hook:
for i in $(TARGET_DRIVERS); do  \



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

Re: [Mesa-dev] [PATCH v2] gallium/targets: don't leave an empty target directory(ies)

[Andy Furniss]

Emil Velikov wrote:

Some drivers do not support certain targets - for example nouveau
doesn't do VAAPI, while freedreno doesn't do of the video backends.

As such if we enter vdpau when building freedreno/ilo/etc, a vdpau/
folder will be created, empty library will be build and almost
immediately removed. Thus keeping an empty vdpau/ folder around.

There are two ways to fix this.

 * add substantial tracking in configure/makefiles so that we never end
up in targets/vdpau
 Downsides:
Error prone, as the configure checks and the 'include
gallium/drivers/foo/Automake.inc' can easily get out of sync.

 * remove the folder, if empty, alongside the empty library.
 Downsides:
In the latter case vdpau/ might be empty before the mesa build has
started, yet we'll remove it either way.

This patch implements the latter option, as the downside isn't that
significant, plus the patch is way shorter ;-)

v2: use has_drivers to track since TARGET_DRIVERS can contain space,
hence neither string comparison nor -n/-z works correctly.


This breaks make install on my setup.

 ./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float 
--enable-opencl --enable-omx --with-egl-platforms=x11,drm 
--with-gallium-drivers=radeonsi,swrast --enable-gbm 
--enable-shared-glapi --enable-glx-tls --with-dri-drivers= && make -j5




make install



Making install in state_trackers/xvmc
make[4]: Entering directory 
'/mnt/sdb1/Gits/mesa/src/gallium/state_trackers/xvmc'
make[5]: Entering directory 
'/mnt/sdb1/Gits/mesa/src/gallium/state_trackers/xvmc'

make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory 
'/mnt/sdb1/Gits/mesa/src/gallium/state_trackers/xvmc'
make[4]: Leaving directory 
'/mnt/sdb1/Gits/mesa/src/gallium/state_trackers/xvmc'

Making install in targets/xvmc
make[4]: Entering directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/xvmc'
make[5]: Entering directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/xvmc'
make[5]: Nothing to be done for 'install-exec-am'.
 /bin/mkdir -p '/usr/lib'
 /bin/sh ../../../../libtool   --mode=install /usr/bin/install -c 
libXvMCgallium.la '/usr/lib'
libtool: install: /usr/bin/install -c .libs/libXvMCgallium.so.1.0.0 
/usr/lib/libXvMCgallium.so.1.0.0
libtool: install: (cd /usr/lib && { ln -s -f libXvMCgallium.so.1.0.0 
libXvMCgallium.so.1 || { rm -f libXvMCgallium.so.1 && ln -s 
libXvMCgallium.so.1.0.0 libXvMCgallium.so.1; }; })
libtool: install: (cd /usr/lib && { ln -s -f libXvMCgallium.so.1.0.0 
libXvMCgallium.so || { rm -f libXvMCgallium.so && ln -s 
libXvMCgallium.so.1.0.0 libXvMCgallium.so; }; })
libtool: install: /usr/bin/install -c .libs/libXvMCgallium.lai 
/usr/lib/libXvMCgallium.la
libtool: finish: PATH="/sbin:/bin:/usr/sbin:/usr/bin:/sbin" ldconfig -n 
/usr/lib

--
Libraries have been installed in:
   /usr/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
 during execution
   - add LIBDIR to the 'LD_RUN_PATH' environment variable
 during linking
   - use the '-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to '/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
make  install-data-hook
make[6]: Entering directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/xvmc'
  GEN  install-data-hook
/bin/sh: line 16: test: -eq: unary operator expected
rm: cannot remove ‘//usr/lib’: Directory not empty
Makefile:1059: recipe for target 'install-data-hook' failed
make[6]: *** [install-data-hook] Error 1
make[6]: Leaving directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/xvmc'
Makefile:987: recipe for target 'install-data-am' failed
make[5]: *** [install-data-am] Error 2
make[5]: Leaving directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/xvmc'
Makefile:939: recipe for target 'install-am' failed
make[4]: *** [install-am] Error 2
make[4]: Leaving directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/xvmc'
Makefile:600: recipe for target 'install-recursive' failed
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory '/mnt/sdb1/Gits/mesa/src/gallium'
Makefile:856: recipe for target 'install-recursive' failed
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory '/mnt/sdb1/Gits/mesa/src'
Makefile:1013: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/mnt/sdb1/Gits/mesa/src'
Makefile:644: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1

___

Re: [Mesa-dev] [PATCH] st/va: remove assert for single slice

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Andy,

I am attaching the patches.
Does it cause any difference in the corruption in this video?

https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s



Hi, it seems mpv and ffmpeg have been changing their vaapi code recently.

With an old mpv the corruption is the same as without the patches.

With git mpv the patches cause a segfault -

Program received signal SIGSEGV, Segmentation fault.
0x710bbe8e in __memcpy_sse2_unaligned () from /lib/libc.so.6
(gdb) bt
#0  0x710bbe8e in __memcpy_sse2_unaligned () from /lib/libc.so.6
#1  0x7fffe423f4e0 in ruvd_decode_bitstream (decoder=0x226dcb0, 
target=, picture=, num_buffers=out>, buffers=, sizes=) at radeon_uvd.c:1029
#2  0x7fffe40f37cb in handleVASliceDataBufferType (buf=out>, context=0x2236290) at picture.c:323
#3  vlVaRenderPicture (ctx=, context_id=, 
buffers=, num_buffers=) at picture.c:518

#4  0x00cba28e in ff_vaapi_decode_issue ()
#5  0x008f8dac in vaapi_mpeg2_end_frame ()
#6  0x007635cc in decode_chunks ()
#7  0x007648e7 in mpeg_decode_frame ()
#8  0x008daa53 in avcodec_decode_video2 ()
#9  0x008db780 in do_decode ()
#10 0x008dc650 in avcodec_send_packet ()

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

Re: [Mesa-dev] [PATCH] st/va: remove assert for single slice

[Andy Furniss]

Nayan Deshmukh wrote:


Any ideas why? I am attaching the diff for reference.



Could be that the shader based decoder has a bug with multiple slices as
well.


It could be. Andy can you test it with your hardware decoder to see if
its specific
to shader decoder.


Can you re-send or attach anything you want me to try to the bug.

The diff in here is too corrupt to apply.

It's a long time since I used shader decode (on rv790 before it got uvd).

IIRC there were samples that were a bit wrong - but then that was
testing with vdpau.


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

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

[Andy Furniss]

Michel Dänzer wrote:

On 30/01/17 12:08 AM, Andy Furniss wrote:

Christian König wrote:

That looks correct to me, but I'm not deeply enough into the H264
encoding any more.

Adding Leo and Boyuan to comment as well.


I just sent v2 to list and tried to cc Boyuan and Leo but it failed.

git send-email -1 -v2 --to=mesa-dev@lists.freedesktop.org
--cc=christian.koe...@amd.com --cc=boyuan.zh...@amd.com
--cc=leo@amd.com --cc=s...@jkqxz.net

looking on patchwork headers (gmail doesn't echo mails back to me = PITA)

I only see you and Mark CCd. I see now that there are capitals in there
addresses as used by you - I got their addresses from other mails to
me/list which were not capitalised - bah.


FWIW, case doesn't matter in e-mail addresses.


Yea, that's what I thought, but a quick google wasn't 100% in agreement.

Anyway I guess it was something else.

The v2 patch is here just in case Leo and Boyuan need to see it.

https://patchwork.freedesktop.org/patch/135837/

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

Re: [Mesa-dev] [PATCH] st/va: Support fractional framerate in misc parameter

[Andy Furniss]

Mark Thompson wrote:

Signed-off-by: Mark Thompson 
---
See  - this is a recent 
addition, but is backwards-compatible.

Depends on Andy's patch 
 for 
actual support for fractional framerate.


Seems good testing so far, in the sense that it doesn't regress anything.

Added CCs.



  src/gallium/state_trackers/va/picture.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index a024437bff..8073ad8906 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -357,7 +357,13 @@ static VAStatus
  handleVAEncMiscParameterTypeFrameRate(vlVaContext *context, 
VAEncMiscParameterBuffer *misc)
  {
 VAEncMiscParameterFrameRate *fr = (VAEncMiscParameterFrameRate 
*)misc->data;
-   context->desc.h264enc.rate_ctrl.frame_rate_num = fr->framerate;
+   if (fr->framerate & 0x) {
+  context->desc.h264enc.rate_ctrl.frame_rate_num = fr->framerate   & 
0x;
+  context->desc.h264enc.rate_ctrl.frame_rate_den = fr->framerate >> 16 & 
0x;
+   } else {
+  context->desc.h264enc.rate_ctrl.frame_rate_num = fr->framerate;
+  context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   }
 return VA_STATUS_SUCCESS;
  }




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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

[Andy Furniss]

Rainer Hochecker wrote:



On 27.01.2017 12:26, Andy Furniss wrote:

Peter Frühberger wrote:


just tell us when we can remove:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L534



Maybe I mis-remember, but doesn't AMD also need some EGL work for
VAAPI display with kodi?

Would be handy to get kodi to work with vaapi for extra testing,
but if I disable that test decode works but nothing is displayed.

ERROR: VAAPI::COutput::CreateEGLContext - Could not make surface current
+ lots of
ERROR: VAAPI::GLMapSurface - Error: invalid VAImageFormat(22)




Currently Kodi uses EGL only in Intel systems because vdpau is bound to
GLX. See
CWinSystemX11GLContext::RefreshGLContext


Ok, thanks for the info.

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

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

[Andy Furniss]

Christian König wrote:

That looks correct to me, but I'm not deeply enough into the H264
encoding any more.

Adding Leo and Boyuan to comment as well.


I just sent v2 to list and tried to cc Boyuan and Leo but it failed.

git send-email -1 -v2 --to=mesa-dev@lists.freedesktop.org 
--cc=christian.koe...@amd.com --cc=boyuan.zh...@amd.com 
--cc=leo@amd.com --cc=s...@jkqxz.net


looking on patchwork headers (gmail doesn't echo mails back to me = PITA)

I only see you and Mark CCd. I see now that there are capitals in there
addresses as used by you - I got their addresses from other mails to 
me/list which were not capitalised - bah.




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

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

[Andy Furniss]

Mark Thompson wrote:

On 27/01/17 22:06, Andy Furniss wrote:



Could use floats I guess like I did here.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=a5993022275c20061ac025d9adc26c5f9d02afee

I don't know what the preference is between float and int.


I think float is fine here?  I don't know what the preference is either...  
(uint64_t would also be big enough, I think.)

As an alternative source of inspiration, 
<https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/gen6_mfc_common.c#n93>
 is full of doubles ;)


I sent a float v2 patch to the list.

Float vs double didn't seem to make any difference at normal bitrates so 
I just used float.


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

[Mesa-dev] [PATCH v2] st/va encode handle ntsc framerate rate control

[Andy Furniss]

Tested with ffmpeg and gst-vaapi. Without this bits per
frame is set way too low for fractional framerates.

v2: Mark Thompson: simplify calculation.
Use float.

Signed-off-by: Andy Furniss <adf.li...@gmail.com>
---
 src/gallium/state_trackers/va/picture.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 82584ea..53bb9eb 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -119,14 +119,21 @@ getEncParamPreset(vlVaContext *context)
context->desc.h264enc.rate_ctrl.fill_data_enable = 1;
context->desc.h264enc.rate_ctrl.enforce_hrd = 1;
context->desc.h264enc.enable_vui = false;
-   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0)
-  context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
+   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0 ||
+   context->desc.h264enc.rate_ctrl.frame_rate_den == 0) {
+ context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
+ context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   }
context->desc.h264enc.rate_ctrl.target_bits_picture =
-  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+  context->desc.h264enc.rate_ctrl.target_bitrate *
+  ((float)context->desc.h264enc.rate_ctrl.frame_rate_den /
+  context->desc.h264enc.rate_ctrl.frame_rate_num);
context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
-  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
+  context->desc.h264enc.rate_ctrl.peak_bitrate *
+  ((float)context->desc.h264enc.rate_ctrl.frame_rate_den /
+  context->desc.h264enc.rate_ctrl.frame_rate_num);
 
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
context->desc.h264enc.ref_pic_mode = 0x0201;
 }
 
@@ -362,7 +369,7 @@ handleVAEncSequenceParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, vl
   context->gop_coeff = VL_VA_ENC_GOP_COEFF;
context->desc.h264enc.gop_size = h264->intra_idr_period * 
context->gop_coeff;
context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
-   context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   context->desc.h264enc.rate_ctrl.frame_rate_den = h264->num_units_in_tick;
return VA_STATUS_SUCCESS;
 }
 
-- 
2.7.0

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

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

[Andy Furniss]

Mark Thompson wrote:

On 26/01/17 18:26, Andy Furniss wrote:

Tested with ffmpeg and gst-vaapi. Without this bits per
frame is set way too low.

Signed-off-by: Andy Furniss <adf.li...@gmail.com>
---
  src/gallium/state_trackers/va/picture.c | 32 
  1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 82584ea..a024437 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -119,14 +119,30 @@ getEncParamPreset(vlVaContext *context)
 context->desc.h264enc.rate_ctrl.fill_data_enable = 1;
 context->desc.h264enc.rate_ctrl.enforce_hrd = 1;
 context->desc.h264enc.enable_vui = false;
-   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0)
-  context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
-   context->desc.h264enc.rate_ctrl.target_bits_picture =
-  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
-  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
+   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0 ||
+   context->desc.h264enc.rate_ctrl.frame_rate_den == 0) {
+ context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
+ context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   }
+   if (context->desc.h264enc.rate_ctrl.frame_rate_den > 1) {
+  context->desc.h264enc.rate_ctrl.target_bits_picture =
+ context->desc.h264enc.rate_ctrl.target_bitrate /
+ (context->desc.h264enc.rate_ctrl.frame_rate_num /
+ context->desc.h264enc.rate_ctrl.frame_rate_den + 1);


This is still doing more rounding than necessary?  (Consider 0.5fps as 1/2, 
say.)  Don't you want:


Hmm, sub 1 fps is going to be treated as 1 fps with my code but -



context->desc.h264enc.rate_ctrl.target_bits_picture =
 (context->desc.h264enc.rate_ctrl.target_bitrate *
  context->desc.h264enc.rate_ctrl.frame_rate_den) /
 context->desc.h264enc.rate_ctrl.frame_rate_num;

(And no need for any extra +1 or conditional, because you've already made sure 
that neither of them are zero.)


This will overflow, with high bitrate plus ntsc denom = 1001

Could use floats I guess like I did here.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=a5993022275c20061ac025d9adc26c5f9d02afee

I don't know what the preference is between float and int.


+  context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+ context->desc.h264enc.rate_ctrl.peak_bitrate /
+ (context->desc.h264enc.rate_ctrl.frame_rate_num /
+ context->desc.h264enc.rate_ctrl.frame_rate_den + 1);


Similarly this one.


+   } else {
+  context->desc.h264enc.rate_ctrl.target_bits_picture =
+ context->desc.h264enc.rate_ctrl.target_bitrate /
+ context->desc.h264enc.rate_ctrl.frame_rate_num;
+  context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+ context->desc.h264enc.rate_ctrl.peak_bitrate /
+ context->desc.h264enc.rate_ctrl.frame_rate_num;
+   }


Doing that would also avoid needing the if at all.



+   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
 context->desc.h264enc.ref_pic_mode = 0x0201;
  }

@@ -362,7 +378,7 @@ handleVAEncSequenceParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, vl
context->gop_coeff = VL_VA_ENC_GOP_COEFF;
 context->desc.h264enc.gop_size = h264->intra_idr_period * 
context->gop_coeff;
 context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
-   context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   context->desc.h264enc.rate_ctrl.frame_rate_den = h264->num_units_in_tick;
 return VA_STATUS_SUCCESS;
  }


Otherwise LGTM :)


Thanks.



Thanks,

- Mark



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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

[Andy Furniss]

Peter Frühberger wrote:


just tell us when we can remove:
https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L534


Maybe I mis-remember, but doesn't AMD also need some EGL work for VAAPI 
display with kodi?


Would be handy to get kodi to work with vaapi for extra testing,
but if I disable that test decode works but nothing is displayed.

ERROR: VAAPI::COutput::CreateEGLContext - Could not make surface current
+ lots of
ERROR: VAAPI::GLMapSurface - Error: invalid VAImageFormat(22)


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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

[Andy Furniss]

Andy Furniss wrote:

Andy Furniss wrote:

Christian König wrote:

Hi guys,

ok this is completely work in progress and untested except for a
compile run.

Most of the stuff necessary should be there for VDPAU, but I'm
honestly not sure how to approach VAAPI.


These regress R9 285 8bit h264 vaapi decode with mpv,

[vd] Pixel formats supported by decoder: vdpau vaapi_vld yuv420p
[vd] Codec profile: High (0x64)
[vaapi] Using profile 'VAProfileH264High'.
[vaapi] vaCreateConfig(): the requested RT Format is not supported
[ffmpeg/video] h264: Reinit context to 3840x2160, pix_fmt: yuv420p
[vd] Falling back to software decoding.


Seems this may be an mpv issue caused by patch 7

ffmpeg is not regressed by this.


mpv current git is working OK, I was testing with a few days old.


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

[Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

[Andy Furniss]

Tested with ffmpeg and gst-vaapi. Without this bits per
frame is set way too low.

Signed-off-by: Andy Furniss <adf.li...@gmail.com>
---
 src/gallium/state_trackers/va/picture.c | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 82584ea..a024437 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -119,14 +119,30 @@ getEncParamPreset(vlVaContext *context)
context->desc.h264enc.rate_ctrl.fill_data_enable = 1;
context->desc.h264enc.rate_ctrl.enforce_hrd = 1;
context->desc.h264enc.enable_vui = false;
-   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0)
-  context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
-   context->desc.h264enc.rate_ctrl.target_bits_picture =
-  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
-  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
+   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0 ||
+   context->desc.h264enc.rate_ctrl.frame_rate_den == 0) {
+ context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
+ context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   }
+   if (context->desc.h264enc.rate_ctrl.frame_rate_den > 1) {
+  context->desc.h264enc.rate_ctrl.target_bits_picture =
+ context->desc.h264enc.rate_ctrl.target_bitrate /
+ (context->desc.h264enc.rate_ctrl.frame_rate_num /
+ context->desc.h264enc.rate_ctrl.frame_rate_den + 1);
+  context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+ context->desc.h264enc.rate_ctrl.peak_bitrate /
+ (context->desc.h264enc.rate_ctrl.frame_rate_num /
+ context->desc.h264enc.rate_ctrl.frame_rate_den + 1);
+   } else {
+  context->desc.h264enc.rate_ctrl.target_bits_picture =
+ context->desc.h264enc.rate_ctrl.target_bitrate /
+ context->desc.h264enc.rate_ctrl.frame_rate_num;
+  context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+ context->desc.h264enc.rate_ctrl.peak_bitrate /
+ context->desc.h264enc.rate_ctrl.frame_rate_num;
+   }
 
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
context->desc.h264enc.ref_pic_mode = 0x0201;
 }
 
@@ -362,7 +378,7 @@ handleVAEncSequenceParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, vl
   context->gop_coeff = VL_VA_ENC_GOP_COEFF;
context->desc.h264enc.gop_size = h264->intra_idr_period * 
context->gop_coeff;
context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
-   context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   context->desc.h264enc.rate_ctrl.frame_rate_den = h264->num_units_in_tick;
return VA_STATUS_SUCCESS;
 }
 
-- 
2.7.0

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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

[Andy Furniss]

Andy Furniss wrote:

Christian König wrote:

Hi guys,

ok this is completely work in progress and untested except for a
compile run.

Most of the stuff necessary should be there for VDPAU, but I'm
honestly not sure how to approach VAAPI.


These regress R9 285 8bit h264 vaapi decode with mpv,

[vd] Pixel formats supported by decoder: vdpau vaapi_vld yuv420p
[vd] Codec profile: High (0x64)
[vaapi] Using profile 'VAProfileH264High'.
[vaapi] vaCreateConfig(): the requested RT Format is not supported
[ffmpeg/video] h264: Reinit context to 3840x2160, pix_fmt: yuv420p
[vd] Falling back to software decoding.


Seems this may be an mpv issue caused by patch 7

ffmpeg is not regressed by this.


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

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

[Andy Furniss]

Christian König wrote:

Hi guys,

ok this is completely work in progress and untested except for a compile run.

Most of the stuff necessary should be there for VDPAU, but I'm honestly not 
sure how to approach VAAPI.


These regress R9 285 8bit h264 vaapi decode with mpv,

[vd] Pixel formats supported by decoder: vdpau vaapi_vld yuv420p
[vd] Codec profile: High (0x64)
[vaapi] Using profile 'VAProfileH264High'.
[vaapi] vaCreateConfig(): the requested RT Format is not supported
[ffmpeg/video] h264: Reinit context to 3840x2160, pix_fmt: yuv420p
[vd] Falling back to software decoding.

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Christian König wrote:

Ah, yes of course. If we delay creating the decoder we need to call
begin_frame() again as well.

Please review and/or test the attached patch. Andy I did understand you
right that this is already a Tested-by from your side, isn't it?


Yes, this patch seems OK.

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Christian,

The new patch leads to seg fault on my system. You forgot to set the
needs_begin_frame to true when the decoder is created. Here's diff for
reference:


Setting true there seems to fix, though only a quick test.

The patch below sets false :-)



diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index e75006d..a51e482 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -178,6 +178,8 @@ handlePictureParameterBuffer(vlVaDriver *drv,
vlVaContext *context, vlVaBuffer *

if (!context->decoder)
   return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+  context->needs_begin_frame = false;
 }

 return vaStatus;
--

I am wondering if calling decode_bitstream one at a time for each
buffer is similar to
calling it with all buffers at once?

Cheers,
Nayan

On Thu, Jan 19, 2017 at 8:36 PM, Andy Furniss <adf.li...@gmail.com> wrote:

Andy Furniss wrote:


Christian König wrote:


Hi Andy,

Am 19.01.2017 um 11:46 schrieb Andy Furniss:


I think you are right about the slices, the failing vids are blu-ray/tv.


https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing




Thanks for the link, if you have time please give the attached patch a
try.

It should fix the issue, but I currently don't have a test system for
VAAPI ready so I can't confirm it of hand.



It doesn't fix properly. The vid will play normally after a second,
but during that second I get to see many flash frames of gpu mem.

Lucky I chose this sample out of several as the patch does seem to
fix a couple of other previously failing vids.



Though more testing shows it also regresses previously working vids, some as
above, but one never "starts" and is total junk.







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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Andy Furniss wrote:

Christian König wrote:

Hi Andy,

Am 19.01.2017 um 11:46 schrieb Andy Furniss:

I think you are right about the slices, the failing vids are blu-ray/tv.

https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing




Thanks for the link, if you have time please give the attached patch a
try.

It should fix the issue, but I currently don't have a test system for
VAAPI ready so I can't confirm it of hand.


It doesn't fix properly. The vid will play normally after a second,
but during that second I get to see many flash frames of gpu mem.

Lucky I chose this sample out of several as the patch does seem to
fix a couple of other previously failing vids.


Though more testing shows it also regresses previously working vids, some as
above, but one never "starts" and is total junk.



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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Christian König wrote:

Hi Andy,

Am 19.01.2017 um 11:46 schrieb Andy Furniss:

I think you are right about the slices, the failing vids are blu-ray/tv.

https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing



Thanks for the link, if you have time please give the attached patch a try.

It should fix the issue, but I currently don't have a test system for
VAAPI ready so I can't confirm it of hand.


It doesn't fix properly. The vid will play normally after a second,
but during that second I get to see many flash frames of gpu mem.

Lucky I chose this sample out of several as the patch does seem to
fix a couple of other previously failing vids.

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Christian König wrote:

Am 19.01.2017 um 00:20 schrieb Andy Furniss:

Nayan Deshmukh wrote:

On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov
<emil.l.veli...@gmail.com> wrote:

On 17 January 2017 at 14:55, Nayan Deshmukh
<nayan26deshm...@gmail.com> wrote:

On Tue, Jan 17, 2017 at 6:25 PM, Christian König
<christian.koe...@amd.com> wrote:

Hi Nayan,

I've pushed this patch yesterday and this one just a minute ago.


Thanks for the push. I am planning on sending a similar patch for
vaapi.


If this (and the vaapi one) does not have too many nasty dependencies
might be worth tagging for stable ?
Cc: mesa-sta...@lists.freedesktop.org


This one should be added to stable, I forgot to add the stable tag. I
will send a mail


Unfortunately it seems this does regress some h264 videos.

I did test several h264 - 576, 720, 1080 and 4K, all were OK but I've
just found
a couple that are regressed by this = decode to partial junk.


Making an educated guess I would say everything which uses multiple
slices would now break.

Damn it, I should have thought earlier about this. Trivial to fix, we
just need to make sure to call begin_frame only once for each frame.

Nayan, do you want to provide a patch or should I take care of this?

Andy can you point us to a broken video?


I think you are right about the slices, the failing vids are blu-ray/tv.

https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Nayan Deshmukh wrote:

On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov  wrote:

On 17 January 2017 at 14:55, Nayan Deshmukh  wrote:

On Tue, Jan 17, 2017 at 6:25 PM, Christian König
 wrote:

Hi Nayan,

I've pushed this patch yesterday and this one just a minute ago.


Thanks for the push. I am planning on sending a similar patch for vaapi.


If this (and the vaapi one) does not have too many nasty dependencies
might be worth tagging for stable ?
Cc: mesa-sta...@lists.freedesktop.org


This one should be added to stable, I forgot to add the stable tag. I
will send a mail


Unfortunately it seems this does regress some h264 videos.

I did test several h264 - 576, 720, 1080 and 4K, all were OK but I've 
just found

a couple that are regressed by this = decode to partial junk.

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Nayan Deshmukh wrote:

On Fri, Jan 13, 2017 at 9:54 PM, Andy Furniss <adf.li...@gmail.com> wrote:



Would be interesting to see if you see the same with this vid
which easily shows the corruption.

https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s?usp=sharing

Looks bad --hwdec-vaapi with or without --vo=vaapi


with --hwdec=vaapi and --vo=vaapi I see the corruption. But without
--vo=vaapi it uses VAAPI EGL interop and leads to this error
unsupported VA image format unknown


Ok and thanks for looking into the buzilla bug.

I don't know why you get egl interop - I get "normal" opengl and don't
know how force mpv to try egl.

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Nayan Deshmukh wrote:

On Fri, Jan 13, 2017 at 8:32 PM, Andy Furniss <adf.li...@gmail.com> wrote:


Nayan Deshmukh wrote:


Hi Andy,

Please test this patch for regressions.



Do you have a testcase to show the fix?

TBH I've not tested gstreamer with mpeg2 before as vaapi mpeg2
h/w dec never worked properly anyway.

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

With mpv --hwdec=vaapi it doesn't seem to regress anything.


I was talking about --hwdec=vaapi. Before this patch I was not able to play
any mpeg videos with vaapi as mpv --hwdec=vaapi --vo=vaapi always
segfaulted. With this patch I can see videos properly. Just wanted to
make sure it did not cause any regression when using hardware decoder.


Oh, OK, I can't reproduce that with mpv, but it will still just assert 
with mesa debug build


mpv: picture_mpeg12.c:84: vlVaHandleSliceParameterBufferMPEG12: 
Assertion `buf->size >= sizeof(VASliceParameterBufferMPEG2) && 
buf->num_elements == 1' failed.


Or play with non debug build, but depending on source vid may be
slightly corrupted.

Would be interesting to see if you see the same with this vid
which easily shows the corruption.

https://drive.google.com/drive/folders/0BxP5-S1t9VEEbkR4dWhTUFozV2s?usp=sharing

Looks bad --hwdec-vaapi with or without --vo=vaapi

OK with --hwdec=vdpau --vo=vdpau (just --hwdec=vdpau will be slightly wrong
currently as there is a vdpau gl interop bug that causes half res)



More generally - it's really good you are working on vaapi - I don't
know what you've discusses with anyone but did you see the old threads
around VAAPI_DISABLE_INTERLACE?


I haven't discussed it with anyone but I will try reading the old threads
and the
bug reports.


Thanks.

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

Re: [Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Andy,

Please test this patch for regressions.


Do you have a testcase to show the fix?

TBH I've not tested gstreamer with mpeg2 before as vaapi mpeg2
h/w dec never worked properly anyway.

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

With mpv --hwdec=vaapi it doesn't seem to regress anything.

With gstreamer - I can display junk and segfault with or without
the patch.

This is the first time trying though, and I just don't know whether it's
just me messing up demuxing mpeg container to feed vaapi or whether
it's using vaapi sink (normally I only test x264/mkv/mp4/raw 
encode/transcode).


If you have a working gstreamer commandline to demux mpegps decode and 
display

it would be handy :-)


More generally - it's really good you are working on vaapi - I don't
know what you've discusses with anyone but did you see the old threads
around VAAPI_DISABLE_INTERLACE?

I was meaning to bring this up via bug/finding replying to old mails.
It was only meant to be a short term fix and as time goes on it's
getting more problematic.

Soon ffmpeg will enable de-interlacer, which depending on env, may lock
peoples GPUs if they paste some example from the wiki.

mpv --vo=vaapi is also borked = vmfaults probably related to interlaces
vs progressive buffers (though may be more complicated than that as
hwdec + vo does seem OK)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Andy,

Can you try this patch? This should help with the tearing.


Patch seems to be good - I get page flipping again so DC, modesetting
and "normal" setup all work OK.



diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 48e3133..98a8011 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 res_tmpl.depth0 = 1;
 res_tmpl.array_size = 1;
 res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_SHARED;
+   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
 res_tmpl.usage = PIPE_USAGE_DEFAULT;

 pipe_mutex_lock(dev->mutex);

Regards,
Nayan

On Wed, Jan 11, 2017 at 5:11 PM, Andy Furniss <adf.li...@gmail.com> wrote:

Michel Dänzer wrote:


On 11/01/17 05:13 PM, Nayan Deshmukh wrote:


On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@daenzer.net>
wrote:


On 10/01/17 06:53 PM, Nayan Deshmukh wrote:


On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net>
wrote:


On 06/01/17 05:50 AM, Andy Furniss wrote:


Christian König wrote:


Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:


dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
   handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
 to maintain it for each buffer instead use a global
variable
v4: In case of single gpu we can cache the buffers as applications
   use constant number of buffer and we can avoid calls to
present
   extension for every frame

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>



Acked-by: Christian König <christian.koe...@amd.com>.

Andy & Leo did you guys already had a chance to test it? To me it
looks
like this should work now.



Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.



Somebody should track down why the buffers sent for presentation in
this
case don't use the same tiling parameters as buffers used for GL via
DRI3.


I can look into this, but I don't know where to look exactly. Can you
give some
pointers to get started.



Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
creating the buffers that are now being directly sent to the X server
for presentation.


So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
output surfaces of the state tracker. Will introducing
PIPE_BIND_SCANOUT lead to performance loss for these surfaces?



Potentially, but I doubt it'll make a big difference for this use case.
In the future, there might be a feedback mechanism which allows
re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
current circumstances, but for now it's probably better to set it (at
least in cases where we don't know that the buffer can never be scanned
out directly) to allow for page flipping.



Pure luck noticing this because I haven't tested modesetting driver for
ages, but -

These patches also break full screen vdpau playback when using that.

Result is a screen of mostly junk with a hint of the vid - looks like
when direct scan out fails on wayland due to tiling mismatch.





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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Michel Dänzer wrote:

On 11/01/17 05:13 PM, Nayan Deshmukh wrote:

On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@daenzer.net> wrote:

On 10/01/17 06:53 PM, Nayan Deshmukh wrote:

On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net> wrote:

On 06/01/17 05:50 AM, Andy Furniss wrote:

Christian König wrote:

Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>


Acked-by: Christian König <christian.koe...@amd.com>.

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.


Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.


Somebody should track down why the buffers sent for presentation in this
case don't use the same tiling parameters as buffers used for GL via DRI3.


I can look into this, but I don't know where to look exactly. Can you give some
pointers to get started.


Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
creating the buffers that are now being directly sent to the X server
for presentation.


So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
output surfaces of the state tracker. Will introducing
PIPE_BIND_SCANOUT lead to performance loss for these surfaces?


Potentially, but I doubt it'll make a big difference for this use case.
In the future, there might be a feedback mechanism which allows
re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
current circumstances, but for now it's probably better to set it (at
least in cases where we don't know that the buffer can never be scanned
out directly) to allow for page flipping.


Pure luck noticing this because I haven't tested modesetting driver for 
ages, but -


These patches also break full screen vdpau playback when using that.

Result is a screen of mostly junk with a hint of the vid - looks like
when direct scan out fails on wayland due to tiling mismatch.

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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Alex Deucher wrote:

On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
<nayan26deshm...@gmail.com> wrote:

On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss <adf.li...@gmail.com> wrote:

Christian König wrote:


Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:


dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>



Acked-by: Christian König <christian.koe...@amd.com>.

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.



Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.



That's bad. It should have improved the speed due to less copying involved.
But it seems there are some problems in the patch. It may be that somehow we
make calls to present extension on every frame.



This is not the fault of your patches.  They reduce the copying
involved with generates less GPU activity which causes the GPU to not
ramp up the clocks as high.  For multi-media especially, we really
need to add a kernel interface to request a minimum clock floor for
specific contexts.


Hmm, are these hidden clocks?

echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level

With dri2 it's still OK fullscreen, with opengl perf is hurt but it
doesn't tear fullscreen - just can't make the framerate so player drops
or slow-mo depending on its settings.

Clearly clocks play a part in that on a non DC kernel high will "fix"
but even then that's one test at 1080p. I tried 2160p framebuffer and
it doesn't quite fix that. Going more extreme 4320p it's worse of course
but full screen dri2 and opengl still won't tear.

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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Andy Furniss wrote:


Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.


todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is "slower" = the tear region is 2 to 3 times
larger than non DC kernel with powerplay auto. With high it is smaller
but still present.


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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Nayan Deshmukh wrote:

On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss <adf.li...@gmail.com> wrote:

Christian König wrote:


Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:


dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

Suggested-by: Leo Liu <leo@amd.com>
Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>



Acked-by: Christian König <christian.koe...@amd.com>.

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.



Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.



That's bad. It should have improved the speed due to less copying involved.
But it seems there are some problems in the patch. It may be that somehow we
make calls to present extension on every frame.


Tiling issue that Michel suggested?

FWIW in windowed playback everything (dri2/3/opengl) has this, I assume
because I don't get pageflipping then. I wouldn't notice though because
even if the player opens the window at the top of the screen, the window
border makes the vid low enough to miss the tear.
Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.


Andy you are using dri3 for testing, right?


Yes, there is no (fullscreen) tearing if I startx with DRI3 disabled.


Leo, did you also experience tearing issues?


It's quite possible that most won't see this -

I use a non-compositing desktop (fluxbox), so I guess unless people use
unredirect full screen windows they may still get gl page flipping?

It's only the top of the screen and you won't notice on many video
unless there is a lot of horizontal panning.


Regards,
Nayan



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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Christian König wrote:

Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
 handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
   to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
 use constant number of buffer and we can avoid calls to present
 extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 


Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.


Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.

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

Re: [Mesa-dev] [PATCH] radeon/vce Handle H.264 level 5.2

[Andy Furniss]

Leo Liu wrote:

Hi Andy,

Please rebase all your reviewed patches, and add RB, and send them to me
I will commit them for you.


Ok, thanks, I've sent two to you.



Cheers,

Leo



On 12/05/2016 03:14 PM, Andy Furniss wrote:

Hi, I did a v2, can it be applied?

https://patchwork.freedesktop.org/patch/118006/

Christian König wrote:

Am 25.10.2016 um 00:39 schrieb Andy Furniss:

For gstreamer
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91281

Signed-off-by: Andy Furniss <adf.li...@gmail.com>
---
  src/gallium/drivers/radeon/radeon_vce.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c
b/src/gallium/drivers/radeon/radeon_vce.c
index ef93e46..6d6d414 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -178,13 +178,13 @@ static unsigned get_cpb_num(struct rvce_encoder
*enc)
  case 41:
  dpb = 32768;
  break;
-default:
  case 42:
  dpb = 34816;
  break;
  case 50:
  dpb = 110400;
  break;
+default:
  case 51:


Setting the default to the maximum is probably a good idea, but I would
also add an explicit "case 52:" here as well just for documentation
purposes.

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

Regards,
Christian.


  dpb = 184320;
  break;






___
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] radeon/vce Handle H.264 level 5.2

[Andy Furniss]

Hi, I did a v2, can it be applied?

https://patchwork.freedesktop.org/patch/118006/

Christian König wrote:

Am 25.10.2016 um 00:39 schrieb Andy Furniss:

For gstreamer
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91281

Signed-off-by: Andy Furniss <adf.li...@gmail.com>
---
  src/gallium/drivers/radeon/radeon_vce.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c
b/src/gallium/drivers/radeon/radeon_vce.c
index ef93e46..6d6d414 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -178,13 +178,13 @@ static unsigned get_cpb_num(struct rvce_encoder
*enc)
  case 41:
  dpb = 32768;
  break;
-default:
  case 42:
  dpb = 34816;
  break;
  case 50:
  dpb = 110400;
  break;
+default:
  case 51:


Setting the default to the maximum is probably a good idea, but I would
also add an explicit "case 52:" here as well just for documentation
purposes.

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

Regards,
Christian.


  dpb = 184320;
  break;






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

Re: [Mesa-dev] [PATCH] st/omx/enc Raise default encode level

[Andy Furniss]

Can you apply this please.

Christian König wrote:

Am 25.10.2016 um 00:46 schrieb Andy Furniss:

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

Signed-off-by: Andy Furniss <adf.li...@gmail.com>


Reviewed-by: Christian König <christian.koe...@amd.com>.


---
  src/gallium/state_trackers/omx/vid_enc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index 0d7ab28..07f6799 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -246,7 +246,7 @@ static OMX_ERRORTYPE
vid_enc_Constructor(OMX_COMPONENTTYPE *comp, OMX_STRING nam
 priv->quant.nQpB = OMX_VID_ENC_QUANT_B_FRAMES_DEFAULT;
 priv->profile_level.eProfile = OMX_VIDEO_AVCProfileBaseline;
-   priv->profile_level.eLevel = OMX_VIDEO_AVCLevel42;
+   priv->profile_level.eLevel = OMX_VIDEO_AVCLevel51;
 priv->force_pic_type.IntraRefreshVOP = OMX_FALSE;
 priv->frame_num = 0;






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

Re: [Mesa-dev] [PATCH] gallivm: Fix build after removal of deprecated attribute API

[Andy Furniss]

Aaron Watry wrote:

On Tue, Nov 8, 2016 at 4:38 AM, Andy Furniss <adf.li...@gmail.com> wrote:


Tom Stellard wrote:


---

Build tested only so far.

   src/gallium/auxiliary/draw/draw_llvm.c|  6 +-
   src/gallium/auxiliary/gallivm/lp_bld_intr.c   | 48 +++-
   src/gallium/auxiliary/gallivm/lp_bld_intr.h   | 13 -
   src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |  4 +-
   src/gallium/drivers/radeonsi/si_shader.c  | 69
---
   src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 24 
   6 files changed, 112 insertions(+), 52 deletions(-)



I notice that llvmpipe needs fixing as well - or maybe that's for someone
else?



I sent a patch for that last night.  Feel free to give it a spin.


Oops, sorry I missed that - with it I can build OK.

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

Re: [Mesa-dev] [PATCH] gallivm: Fix build after removal of deprecated attribute API

[Andy Furniss]

Tom Stellard wrote:

---

Build tested only so far.

  src/gallium/auxiliary/draw/draw_llvm.c|  6 +-
  src/gallium/auxiliary/gallivm/lp_bld_intr.c   | 48 +++-
  src/gallium/auxiliary/gallivm/lp_bld_intr.h   | 13 -
  src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |  4 +-
  src/gallium/drivers/radeonsi/si_shader.c  | 69 ---
  src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 24 
  6 files changed, 112 insertions(+), 52 deletions(-)


I notice that llvmpipe needs fixing as well - or maybe that's for 
someone else?



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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Michel Dänzer wrote:

On 28/10/16 08:19 PM, Andy Furniss wrote:

Michel Dänzer wrote:

On 27/10/16 07:52 PM, Andy Furniss wrote:

Andy Furniss wrote:

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
fails top 5% of screen unless I force GPU perf high.

Not related to this patch directly of course, but I am a bit surprised
that on auto powerplay the tonga is too slow to make 60Hz.


It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
doesn't finish within the vertical blank period.


Yea, I didn't word that very well, and also didn't say res (1080p)
making it even less useful.

Naive question = does the blit have to be "backwards", seems I wouldn't
notice if it were the same way as scanout?


It's not backwards. The problem is that OpenGL doesn't provide a
rectangle primitive, so glamor's blits end up being rendered as two
triangles. In order to avoid tearing, at least the first triangle needs
to finish rendering within the vertical blank period.


OK, so with a meaner test like doing -

xrandr --output DVI-D-0  --fb 3840x2160 --panning 3840x2160

and scrolling top left I can get a larger tear area and can see that
the triangles are split top left to bottom right. Possibly misleading
trying to judge what's happening visually, but it looks like the lower
/left triangle is rendered first with the one that covers most of the
top of the screen being the "late" one. If that's correct and assuming
they are copied top to bottom, then maybe there would be much less
visible disturbance if it were the other way round.


I guess I am being far too simplistic here, not knowing even the most
basic detail, like what format is the actual framebuffer that gets
scanned out really kept in?

I know it ends up as BGR0 if grabbed by ffmpeg/gstreamer via X, which
leads to another thought/question. Currently to record screen with VCE
is quite bottle necked by copy to ram/convert to nv12 and copy back.

Are there any show stopping issues that would preclude avoiding the
copy and doing the CSC/subsample/nv12 layout all in vram/by GPU?


Not that I know of. E.g. something like this could work:

With a GLX context using the X root window as the readable, use
glReadPixels to store the screen contents in a PBO, then continue
processing as necessary from there.


Thanks, that's good to know.


Longer term I have an idea how to make the DDX driver support page
flipping in this case as well, but in the meantime making the buffers
sent for presentation tiled instead of linear should allow page flipping
to be used. https://patchwork.freedesktop.org/patch/110569/ might be
enough, which seems to be the best candidate to resolve the nouveau
VDPAU issues as well.


Doesn't help (one quick test with ddx patch).


Weird, not sure why the buffer tiling doesn't match that of the X screen
pixmap then.


I re-tested just in case I messed up, but still can't get it to
work/help.


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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Michel Dänzer wrote:

On 27/10/16 07:52 PM, Andy Furniss wrote:

Andy Furniss wrote:

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
fails top 5% of screen unless I force GPU perf high.

Not related to this patch directly of course, but I am a bit surprised
that on auto powerplay the tonga is too slow to make 60Hz.


It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
doesn't finish within the vertical blank period.


Yea, I didn't word that very well, and also didn't say res (1080p)
making it even less useful.

Naive question = does the blit have to be "backwards", seems I wouldn't
notice if it were the same way as scanout?

I guess I am being far too simplistic here, not knowing even the most
basic detail, like what format is the actual framebuffer that gets
scanned out really kept in?

I know it ends up as BGR0 if grabbed by ffmpeg/gstreamer via X, which
leads to another thought/question. Currently to record screen with VCE
is quite bottle necked by copy to ram/convert to nv12 and copy back.

Are there any show stopping issues that would preclude avoiding the
copy and doing the CSC/subsample/nv12 layout all in vram/by GPU?


Longer term I have an idea how to make the DDX driver support page
flipping in this case as well, but in the meantime making the buffers
sent for presentation tiled instead of linear should allow page flipping
to be used. https://patchwork.freedesktop.org/patch/110569/ might be
enough, which seems to be the best candidate to resolve the nouveau
VDPAU issues as well.


Doesn't help (one quick test with ddx patch).


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