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

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

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 error: wayland

[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

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

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

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 starts

[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

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

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

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:

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

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

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 ref

[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

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

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

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

xpose 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...@collab

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 <adf.li...@gmail.com> Leo Liu wrote: It caused corruption, when vlVaPutImage putting YUV to the fields Cc: me

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

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,

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

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

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 <adf.li...@gmail.com> wrote: Mark Thompson wrote: This reverts

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

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.

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

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

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

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

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

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

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,

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

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

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

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

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

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.

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

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:

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 (first use

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

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 -

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

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

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 <rafael.espind...@gmail.com> Date: F

[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

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

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

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

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 stream

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 stream

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

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

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 -hwaccel vaapi -i

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:

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

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

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

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

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

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

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 send

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

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

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

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 don't

[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 <adf.li...@gmail.com> --- src/gallium/state_trackers/va/picture.c | 19 +--

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 <adf.li...@gmail.com> --- src/gallium/state_trackers/va/picture.c | 32 1 file c

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 vaapi

[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 <adf.li...@gmail.com> --- src/gallium/state_trackers/va/picture.c | 32 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/src/g

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

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

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

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

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

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

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

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

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

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 <adf.li...@gmail.com> wr

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

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

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

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

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.freedesktop.org

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 <adf.li...@gmail.com> --- src/g

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 <adf.li...@gmail.com> Reviewed-by: Christian König <christian.koe...@amd.com>. ---

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

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 -

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   >