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

27; 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 Cc: Dylan Baker

Re: [Mesa-dev] tizonia egl build fail

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 erro

[Mesa-dev] tizonia egl build fail

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 #includ

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

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

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

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

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

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

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

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

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 @@ stat

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

Emil Velikov wrote: On 7 November 2017 at 10:58, 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 st

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

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 st

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

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/xbm

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

Michel Dänzer wrote: On 18/10/17 05:41 PM, Emil Velikov wrote: On 17 October 2017 at 15:39, Andy Furniss 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

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

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

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

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

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

Emil Velikov wrote: On 16 October 2017 at 03:22, Jan Vesely wrote: On Sun, 2017-10-15 at 00:00 +0100, Andy Furniss wrote: Andy Furniss wrote: Since commit 13a53c4f5cdd664fd155c9e78fb46a4387af006c Author: Emil Velikov Date: Thu Oct 5 11:19:05 2017 +0100 configure.ac: rework llvm

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

Andy Furniss wrote: 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

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

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_AP

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

Tested-by: Andy Furniss 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

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

7;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 Cc: Marek Olšák Signed-off-by: Daniel Stone --- src/egl/drivers/dri2/platform_wayland.c | 56

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

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 Leo Liu wrote: It caused corruption, when vlVaPutImage putting YUV to the fields Cc: mesa-sta...@lists.freedesktop.org Cc: Andy Furniss

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

Tested-by: Andy Furniss Leo Liu wrote: It caused corruption, when vlVaPutImage putting YUV to the fields Cc: mesa-sta...@lists.freedesktop.org Cc: Andy Furniss --- src/gallium/state_trackers/va/image.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium

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

Tested-by: Andy Furniss Leo Liu wrote: It caused corruption, when vlVdpVideoSurfacePutBitsYCbCr putting YUV to the fields Cc: mesa-sta...@lists.freedesktop.org Cc: Andy Furniss --- src/gallium/state_trackers/vdpau/surface.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src

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

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 wrote: Mark Thompson wrote: This reverts commit

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

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 "

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

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" P

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

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

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

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 thi

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

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. [d

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

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

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

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 de

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

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 deinterl

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

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

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

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

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

Ilia Mirkin wrote: On Mon, Aug 21, 2017 at 5:54 PM, Andy Furniss 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

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

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

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

--with-omx-target=tizonia should work. Cheers On Thu, Aug 17, 2017 at 4:39 AM, Andy Furniss 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.

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

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 t

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

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 an

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

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

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

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

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

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

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

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

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

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_crea

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

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

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

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

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

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] (

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

Emil Velikov wrote: On 3 July 2017 at 16:31, Andy Furniss 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

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

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

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

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 Date: Fri Jun 30 18:48:33

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

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

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

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.

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

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 an

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

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

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

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

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

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 s

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

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 s

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

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 (ig

Re: [Mesa-dev] [PATCH 08/11] st/va: clear the video surface on allocation

Andy Furniss wrote: ping. 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

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

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 -h

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

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

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

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,

Re: [Mesa-dev] [PATCH 08/11] st/va: clear the video surface on allocation

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 ca

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

ntee 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 Reported-by: Andy Furniss Fixes: 1cd4f

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

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

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

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 corr

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

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 anyth

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

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

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

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 fo

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

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 som

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

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.

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

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

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

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 --- src/gallium/state_trackers/va/picture.c | 19 +-- 1 file changed, 13 insertions

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

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 --- src/gallium/state_trackers/va/picture.c | 32 1 file changed, 24 insertions(+), 8

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

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

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

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

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

Tested with ffmpeg and gst-vaapi. Without this bits per frame is set way too low. Signed-off-by: Andy Furniss --- 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

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

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 wit

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

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 supp

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

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

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

me 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 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 v

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

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

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

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

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

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

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

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 plann

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

Nayan Deshmukh wrote: On Fri, Jan 13, 2017 at 9:54 PM, Andy Furniss 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

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

Nayan Deshmukh wrote: On Fri, Jan 13, 2017 at 8:32 PM, Andy Furniss 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 a

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

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 do

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

MPLER_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 wrote: Michel Dänzer wrote: O

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

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 wrote: On 10/01/17 06:53 PM, Nayan Deshmukh wrote: On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote: On 06/01/17 05:50 AM, Andy Furniss wrote: Christian König wrote: Am

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

Alex Deucher wrote: On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh wrote: On Fri, Jan 6, 2017 at 2:20 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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

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 powe

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

Nayan Deshmukh wrote: On Fri, Jan 6, 2017 at 2:20 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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

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

Re: [Mesa-dev] [PATCH] radeon/vce Handle H.264 level 5.2

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

Re: [Mesa-dev] [PATCH] radeon/vce Handle H.264 level 5.2

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 --- src/gallium/drivers/radeon

Re: [Mesa-dev] [PATCH] st/omx/enc Raise default encode level

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 Reviewed-by: Christian König . --- src/gallium/state_trackers/omx/vid_enc.c | 2 +- 1 file changed, 1

Re: [Mesa-dev] [PATCH] gallivm: Fix build after removal of deprecated attribute API

Aaron Watry wrote: On Tue, Nov 8, 2016 at 4:38 AM, Andy Furniss 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

Re: [Mesa-dev] [PATCH] gallivm: Fix build after removal of deprecated attribute API

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_so

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

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

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

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

  1   2   3   4   >