Nayan Deshmukh wrote:
Hi Andy,
Thanks for testing my patches.
NP
The scaling happens after CSC.
OK, thanks.
I believe there is some misunderstanding here, I was able to see the
artifacts in the video that you sent me previously. But I was not
able to replicate them
Yea, I got that -
Vincent Lejeune wrote:
---
src/gallium/drivers/r600/r600_llvm.c | 119 +++
src/gallium/drivers/r600/r600_shader.c | 1 +
src/gallium/drivers/radeon/radeon_llvm.h | 1 +
3 files changed, 121 insertions(+)
Looks like this or whatever version went in to m
Christian König wrote:
Reviewed and pushed.
Pushed where?
I guess they don't affect radeon uvd anyway, just when I saw 422 and
444, I was hopeful that uvd cards would get 422 vo like non uvd cards do
- I have a need for that (to use TV deinterlacer).
___
Emil Velikov wrote:
Hi all,
These patches add support for building (grouping) the various targets
per API, meaning that only one library will be created for e.g.
vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a
hardlink to it.
How is this supposed to work from a users poi
Emil Velikov wrote:
Yes I had a few copy/paste typos that were causing make install to fall short
when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed.
Let me know if latest master work for you.
No, it fails to install anything to do with libvdpau_gallium* which is
pr
fail.
Reported-by: Andy Furniss
Signed-off-by: Emil Velikov
---
Andy does this fixes the problem ?
I still don't get libvdpau_gallium installed.
I do with this get the usual one installed properly now -
ls -lh /usr/lib/vdpau/
total 11M
lrwxrwxrwx 1 root root 26 Jun 23
Emil Velikov wrote:
On 23/06/14 19:58, Andy Furniss wrote:
I still don't get libvdpau_gallium installed.
Not sure what made you believe that libvdpau_gallium should be installed, but
that truly is not the case.
Ahh, it was looking at the output of make install, which usually flies
Grigori Goronzy wrote:
On 18.06.2014 13:11, Christian König wrote:
@Grigori: Should I push it or did you got your account in the
meantime?
Bit late but I only just noticed this went in.
This is a really useful feature for me, having recently got a radeonsi,
as it lets me use my tvs deinterlac
Grigori Goronzy wrote:
On 02.07.2014 22:18, Andy Furniss wrote:
Before I knew how to get field sync to use my TVs deinterlacer I had to
modify mesa so that I could use the vdpau de-interlacer(s), when I did
this I noticed that 422 didn't work and looked the same as it does now
this has go
Andy Furniss wrote:
Grigori Goronzy wrote:
On 02.07.2014 22:18, Andy Furniss wrote:
Before I knew how to get field sync to use my TVs deinterlacer I had to
modify mesa so that I could use the vdpau de-interlacer(s), when I did
this I noticed that 422 didn't work and looked the same as it
Andy Furniss wrote:
Andy Furniss wrote:
Grigori Goronzy wrote:
On 02.07.2014 22:18, Andy Furniss wrote:
Before I knew how to get field sync to use my TVs deinterlacer I had to
modify mesa so that I could use the vdpau de-interlacer(s), when I did
this I noticed that 422 didn't wor
I was looking into some minor 422 issues/discrepencies I noticed long
ago using vdpau on my rv790.
I noticed that there is code that is halving height rather than width -
422 is full height AFAIK.
Making the changes below doesn't actually make any noticable difference
to what I was looking i
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders to maximum and enjoy the
Vadim Girlin wrote:
Unrelated question wtr heaven 3.0 - does it work properly anyway?
For me running 64bit on rv790 with vanilla mesa with or without llvm I
have to set shaders to medium, on high it works but I get no
lighting/effects. There are also a couple of scenes that render as
flared out
Vadim Girlin wrote:
Overcautious stack reservation caused significant loss of performance.
v2: fix stack depth computation
I get some corruption with this patch and heaven 3.0 with llvm on
HD4890, R600_LLVM=0 is OK.
It appears on sunlit areas over a certain distance and the patches move
ar
Vadim Girlin wrote:
v3: handle hw-specific cases
Signed-off-by: Vadim Girlin
---
cc: Andy Furniss
Hopefully this should work better on the non-evergreen chips
This one seems to work OK for me.
___
mesa-dev mailing list
mesa-dev
Vadim Girlin wrote:
Testing with rv790 with drm-fixes kernel not much works -
etqw runs but in a level 50% of screen is junk.
nexuiz menus total junk, didn't test further.
xonotic menus OK but gpu lock on starting timedemo.
vdpau mpeg2 decode - renders 90% junk.
heaven 3.0 (on a different p
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me the dumps
with "R600_DUMP_SHADERS=2 R600_SB_DUMP=3".
All of the mesa de
Vadim Girlin wrote:
On 02/19/2013 08:39 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, ple
Sebastien Caty wrote:
On March 3, 2013 12:14:54 AM Vadim Girlin wrote:
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty
wrote:
Trying to dig more and found out which shader is causing trouble but I
On one of my builds I have libdrm/mesa/xorg living under my home,
normally I can build mesa by setting LDFLAGS and --prefix= but since the
uvd commit I get -
Making all in radeon
make[3]: Entering directory
`/mnt/sdb1/Src/Mesa-git/mesa/src/gallium/drivers/radeon'
CC radeon_uvd.lo
In f
Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
These changes make MPEG2 I-frames generate the correct macroblock data (as
compared to mplayer via xvmc). Other MPEG2 frames are still misparsed, and
MPEG1 I-frames have some errors (but largely match up).
This messes up mpeg2 vdpau decode for
Ilia Mirkin wrote:
On Sat, Feb 15, 2014 at 5:10 AM, Christian König
wrote:
That's most likely an issue with st/vdpau. I implemented a small hack to
clear the black bars of a surface only once. No idea how exactly it happens,
but Grigoris patch seems to somehow break the logic there.
Anyway we
Andy Furniss wrote:
Ilia Mirkin wrote:
On Sat, Feb 15, 2014 at 5:10 AM, Christian König
wrote:
That's most likely an issue with st/vdpau. I implemented a small
hack to clear the black bars of a surface only once. No idea how
exactly it happens, but Grigoris patch seems to somehow brea
Grigori Goronzy wrote:
On 15.02.2014 13:14, Andy Furniss wrote:
Thanks Grigori for doing this - looks really good on HD stuff I've
tested and of course is easily fast enough, unlike anything on the
CPU at high res.
Any plans for the future?
Well, adding edge-guided spatial interpolatio
Noticed recently that make distclean is failing for me -
Making distclean in mesa
make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
Makefile:2486: ../glsl/.deps/shader_enums.Plo: No such file or directory
make[2]: *** No rule to make target '../glsl/.deps/shader_enums.Plo'. St
/shader_enums.Plo
glsl/shader_enums.lo: glsl/shader_enums.c glsl/shader_enums.h \
util/macros.h
glsl/shader_enums.h:
util/macros.h:
Regardless, it's a bit strange that make distclean would need some
esoteric editing operation to work!
On Wed, Oct 7, 2015 at 6:00 PM, Andy Furniss
wrote:
Noticed rec
Oded Gabbay wrote:
Oded Gabbay (4): r600g/radeonsi: send endian info to format
translation functions r600g: set endianess of 16/32-bit buffers
according to do_endian_swap r600g: use do_endian_swap in color
swapping functions r600g: use do_endian_swap in texture swapping
function
I get a build
Oded Gabbay wrote:
On Tue, Apr 26, 2016 at 1:26 PM, Andy Furniss wrote:
Oded Gabbay wrote:
Oded Gabbay (4): r600g/radeonsi: send endian info to format
translation functions r600g: set endianess of 16/32-bit buffers
according to do_endian_swap r600g: use do_endian_swap in color
swapping
Jose Fonseca wrote:
Thanks for the heads up.
Fixed now.
clover fails for me with current llvm git + mesa head on your fix.
Making all in state_trackers/clover
make[3]: Entering directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/state_trackers/clover'
CXX llvm/libclllvm_la-invocatio
Linux from scratch doesn't use these anymore (seds requirement out of
libdrm build)
Today I see I can't now build Mesa on linux without them, is this
intentional?
I normally build OK - but with Python 2, now Python 3 is needed this is
the first build with that - just saying in case it's relevant
Christian König wrote:
From: Christian König
We support 5.1 for a while now.
I know (well think) vdpau doesn't really mention 5.2 anywhere, but for
ffmpeg I've been making this change for some time to say 5.2.
Tonga can easily do 5.2, players don't seem to look at this field, but
ffmpeg cli
Alex Deucher wrote:
On Wed, May 25, 2016 at 10:57 AM, Christian König
wrote:
From: Christian König
We support 5.1 for a while now.
Resend as the last one didn't have the CCs.
I know (well think) vdpau doesn't really mention 5.2 anywhere, but for
ffmpeg I've been making this change for some
Christian König wrote:
Am 26.05.2016 um 11:27 schrieb Andy Furniss:
Alex Deucher wrote:
On Wed, May 25, 2016 at 10:57 AM, Christian König
wrote:
From: Christian König
We support 5.1 for a while now.
Resend as the last one didn't have the CCs.
I know (well think) vdpau doesn
Emil Velikov wrote:
On 27 May 2016 at 15:40, Christian König wrote:
No, what I'm saying is that it is a number and not an enum.
This way you don't need to change the specification when you want to support
a new level.
That's the case indeed. Thanks for explaining.
That's handy, FWIW the r
Christian König wrote:
Am 28.05.2016 um 00:45 schrieb Andy Furniss:
Emil Velikov wrote:
On 27 May 2016 at 15:40, Christian König
wrote:
No, what I'm saying is that it is a number and not an enum.
This way you don't need to change the specification when you want to
support
a
In tree build make distclean is failing for me since -
b7f7ec78435771ab02f7d9a61bb1d4a11df720b8 is the first bad commit
commit b7f7ec78435771ab02f7d9a61bb1d4a11df720b8
Author: Emil Velikov
Date: Mon Jun 6 19:39:40 2016 +0100
mesa: automake: distclean git_sha1.h when building OOT
In
435 ("mesa: automake: distclean git_sha1.h when building
OOT")
Cc:
Cc: Andy Furniss
Reported-by: Andy Furniss
Signed-off-by: Emil Velikov
---
Thanks for catching this Andy. The following seems to work fine here.
Can you give it a try on you end ?
Working OK for me with this, thanks.
Nayan Deshmukh wrote:
use bicubic filtering as high quality scaling L1.
Nice, but it doesn't show up in vdpauinfo as a "y".
What player/options are you using to test this?
Thanks.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lis
Nayan Deshmukh wrote:
Hi Andy,
I forgot to change the feature in query.c, which is responsible for the
information about the capabilities of the mixer. I'll send the patch with
change.
Ok, I tried the new patch and with mplayer or mpv the output is corrupted.
I am using R9285 tonga.
65 is better than me - eg. it may be using the
progressive shader, whereas I am using the weave shader.
On Wed, Jun 22, 2016 at 1:50 AM, Andy Furniss wrote:
Nayan Deshmukh wrote:
Hi Andy,
I forgot to change the feature in query.c, which is responsible for the
information about the capabilitie
Andy Furniss wrote:
Nayan Deshmukh wrote:
I forgot to CC the list, so I am attaching our conversation here. Also
probably my R7 M265 uses
a progressive shader.
OK, maybe that could be it.
I may be able to try progressive, but need to remember what to change...
Seems I can't
Christian König wrote:
Am 21.06.2016 um 23:51 schrieb Andy Furniss:
Andy Furniss wrote:
Nayan Deshmukh wrote:
I forgot to CC the list, so I am attaching our conversation here. Also
probably my R7 M265 uses
a progressive shader.
OK, maybe that could be it.
I may be able to try progressive
Andy Furniss wrote:
re-testing with an unpatched mesa and return false after PREFERS I see
the same.
s/w decode mplayer or mpv will segfault - bt below. No asserts with
debug build of mesa.
Sometimes/depending on input file it doesn't instantly segfault brief
output is corrupt and I ge
Nayan Deshmukh wrote:
Hi Andy,
Could you test the new patch series that I have sent? It should probably
work this time.
Only had time for some quick tests so far.
The scaling is now 99% OK, maybe 100% as I don't really know what
artifacts to expect from artificial tests.
The aspect is now co
Nayan Deshmukh wrote:
In the new patches, I have set the pillar boxes black and the hqscaling=0
should work fine too.
Yes, this seems OK now with the latest patches.
2 remaining issues I've noticed -
The image with hqscaling=1 is offset (guess up 1 left 1) compared to
hqscaling=0,xv or opengl
Nayan Deshmukh wrote:
Hi Andy,
Thanks for testing the patches.
Please send me the videos and ratios with which there is corruption.
https://drive.google.com/file/d/0BxP5-S1t9VEEaHZEM203RFpyNEE/view?usp=sharing
This has no aspect encoded and displayed fullscreen on a 1920x1080
monitor shows v
Nayan Deshmukh wrote:
Hi Andy,
On Sun, Jun 26, 2016 at 12:25 AM, Andy Furniss wrote:
Nayan Deshmukh wrote:
Hi Andy,
Thanks for testing the patches.
Please send me the videos and ratios with which there is corruption.
https://drive.google.com/file/d/0BxP5-S1t9VEEaHZEM203RFpyNEE/view
Nayan Deshmukh wrote:
Hi Christian and Andy,
I have sent new series of patches which takes care of the points Christian
pointed out.
I have also made some changes to make it more efficient than before.
Also due to a wrong message id, I have sent the messages as a new thread
instead of replyin
Christian König wrote:
Am 28.06.2016 um 20:11 schrieb Nayan Deshmukh:
Hi Andy,
Thanks for testing the patches.
On Tue, Jun 28, 2016 at 11:26 PM, Andy Furniss mailto:adf.li...@gmail.com>> wrote:
Nayan Deshmukh wrote:
Hi Christian and Andy,
I have sent new ser
Julien Isorce wrote:
Hi Christian,
I have 2 remarks:
1: I am sure you have the clear answer to the following questions, so
maybe add a comment in the commit message: Isn't the thread safety
delegated to the application that use vaapi ? like it is designed for
many libraries. I tried to find ans
Christian König wrote:
Slightly unrelated question = with vaapi using mpeg2 do you get the
same result as vdpau or s/w?
Well MPEG2 actually defines that the resulting image doesn't need to
be 100% bit identical on all decoders. H.264 and others are way more
strict regarding this.
Do you also
Haven't had time to find what caused this, it does seem to be mesa -
Updated mesa last night from a day or two old, llvm 5-10 days old
previous mesa built OK against that.
Got the build fail, updated llvm retried - same fail.
Going back in mesa and applying the build fix for current llvm doesn'
Grigori Goronzy wrote:
On 04.07.2014 01:24, Andy Furniss wrote:
Maybe not 1/frame but anyway the first couple of a run have
numbers rather than s
[27977.386795] radeon :01:00.0: GPU fault detected: 146
0x0c035014 [27977.386800] radeon :01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_ADDR
Grigori Goronzy wrote:
On 29.08.2014 12:31, Andy Furniss wrote:
As for that 4:2:2 "doesn't work", AFAICT it absolutely does, but
there is no linear interpolation for chroma, so quality isn't ideal.
This seems to be a hardware restriction, unfortunately.
Hmm, we may hav
Marek Olšák wrote:
From: Marek Olšák
---
Turn this on, run piglit, and pray for mercy.
It might be interesting to see if it makes 3D apps any faster. Or piglit.
Well it's not piglit and I haven't benchmarked anything yet, but I get a
couple of faults at the start of Unigine Valley.
[20635
Andy Furniss wrote:
Marek Olšák wrote:
From: Marek Olšák
---
Turn this on, run piglit, and pray for mercy.
It might be interesting to see if it makes 3D apps any faster. Or piglit.
Well it's not piglit and I haven't benchmarked anything yet, but I get a
couple of faults at th
Benjamin Bellec wrote:
No problem with Valley on Evergeen (CYPRESS).
Unigine Valley 1.0 (64-bit) Basic preset without "forcedma" :
It doesn't produce them on basic for me - so maybe if you try a higher
setting.
It still runs after producing the errors, though for me valley is very
glitchy. I
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
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
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
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
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
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
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
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] (
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
__
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
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
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
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
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
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
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 "
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
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
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
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
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
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
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
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
101 - 200 of 389 matches
Mail list logo
