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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
__
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
--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.
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
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
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
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
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
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
Andy Furniss wrote:
Andy Furniss wrote:
Tom Stellard wrote:
On Wed, Nov 07, 2012 at 09:24:13PM +, Andy Furniss wrote:
Vincent Lejeune wrote:
git seems to have trouble sending my patch to ML atm, can you
manually apply it ? It fixes lock up here
diff --git a/src/gallium/drivers/r600
make distclean
git clean -dfx
git pull
./autogen.sh --prefix=/usr --disable-egl --enable-texture-float
--enable-gallium-g3dvl --enable-r600-llvm-compiler
--with-gallium-drivers=r600,swrast --with-dri-drivers= && make -j5
(get fail and run just make again)
Making all in dri-r600
make[3]: Ent
Andreas Boll wrote:
Until we have jobermayr's shared libs patches,
don't link libgallium.la twice.
Fixes
http://lists.freedesktop.org/archives/mesa-dev/2013-January/032515.html
Thanks, I tested and it does fix build for me.
A couple of things I notice - before on my new/normal 64bit setup
/l
Tom Stellard wrote:
On Fri, Jan 11, 2013 at 03:38:48PM +, Andy Furniss wrote:
Andreas Boll wrote:
Until we have jobermayr's shared libs patches,
don't link libgallium.la twice.
Fixes
http://lists.freedesktop.org/archives/mesa-dev/2013-January/032515.html
Thanks, I tested and i
Maarten Lankhorst wrote:
Testing interlaced videos that decode correctly with nvidia vdpau would help
a lot to figure out what the proper way to handle interlacing would be, so if
someone has a bunch that play with nvidia accelerated vdpau&mplayer
correctly,
could you please link them? ;)
Maarten Lankhorst wrote:
For some reason mplayer handles all the above images as progressive with vdpau,
and it sets picture_structure to 3. I can see the interlacing on movement, but
it
doesn't seem like mplayer tells vdpau it is interlaced, sigh. :/
That's a shame. Is there another way that
Maarten Lankhorst wrote:
Sadly mplayer tells vdpau to have all videos decoded as progressive so
I can't really do anything. :-(
I just had a look at an old copy of h.262 spec I have.
Unless I am misreading it seems that
picture_structure = 3 (frame) is perfectly valid for interlaced.
It jus
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough. :-)
This patch causes R600 xvmc to render incorrect chroma for me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.o
Maarten Lankhorst wrote:
The brokenness in vlVdpVideoMixerRender was compensating for
brokenness in vlVdpPresentationQueueDisplay, so fix both at
the same time.
These fix the two remaining issues (aspect not maintained when
fullscreen and subtitle position getting changed when toggling back fr
Maarten Lankhorst wrote:
create_buffer, destroy_buffer and set_buffer are a curiosity of
vl_mpeg12_decoder
and shouldn't be part of the api.
set_quant_matrix and set_reference_frames shouldn't be separate calls, but part
of
picparm, which is a requirement for h264 to work.
set_decode_target an
Maarten Lankhorst wrote:
Hey Andy,
On 12/06/2011 10:45 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough. :-)
This patch causes R600 xvmc to render incorrect chroma for me.
Thanks for testing! I plugged in my r600
Maarten Lankhorst wrote:
Hm, could you test with some added sanity checks?
mplayer: vl/vl_vlc.h:139: vl_vlc_eatbits: Assertion `vlc->valid_bits >
num_bits' failed.
If that works, maybe remove the vl_vlc_fillbits call I added in
vl_mpeg12_bs_decode
to see if that is what caused it. Unfortu
Maarten Lankhorst wrote:
You might want to check with valgrind to see if it tosses any warning, too.
I tried valgrind and it does seem that r600 is leaking - below is from a
vanilla mesa with a working test stream and vdpau, xvmc leaks half as
much with the same stream. In the patched/crashi
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst
---
Changes since v2:
- fixed borked ureg_MOV, I have no idea how it worked when I tested this
on r600 to begin with, it renders correctly now with XvMC accele
Maarten Lankhorst wrote:
Softpipe is working, that's handy - last time I tried it was too borked to be
of use, but now I can actually see which errors are software and which are
added by R600.
My observation for softpipe working correctly only seems to apply for
XVMC_MOCOMP,
if I try with X
Andy Furniss wrote:
There are minor errors - when I said "Softpipe is working" I was
comparing to the past when it would render mainly junk with a shrunken
portion of the vid and later when that went away, it would render with
blocks of frame -1 mixed with current frame.
Actually
Maarten Lankhorst wrote:
The brokenness in vlVdpVideoMixerRender was compensating for
brokenness in vlVdpPresentationQueueDisplay, so fix both at
the same time.
Signed-off-by: Maarten Lankhorst
Tested-by: Andy Furniss
___
mesa-dev mailing list
Tested-by: Andy Furniss
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorst
Tested-by: Andy Furniss
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
Christian König wrote:
@Andy: Could you please confirm that they are also working? (They should
apply ontop of current master).
Yes - they are working OK for me.
One thing I noticed while messing with mplayer subs/OSD is that vdpau in
full screen positions them relative to the screen rather
Maarten Lankhorst wrote:
Hey Andy,
On 12/07/2011 05:48 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
Hm, could you test with some added sanity checks?
mplayer: vl/vl_vlc.h:139: vl_vlc_eatbits: Assertion `vlc->valid_bits>
num_bits' failed.
If that works, maybe
Maarten Lankhorst wrote:
Looks like I made the checking a bit too paranoid, causing it to not always
decode last few macroblocks because of fear of reaching end of stream..
Does this work? I removed a few paranoid asserts, and if performance is still
bad, I'll alter the patch to swap between m
Maarten Lankhorst wrote:
Hey Andy,
On 12/19/2011 01:50 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
Looks like I made the checking a bit too paranoid, causing it to not always
decode last few macroblocks because of fear of reaching end of stream..
Does this work? I removed a few
Andy Furniss wrote:
I compiled with -O0 but the backtraces are different - maybe there is
some randomness.
Remembered to attach them this time :-)
mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl->length' failed.
Program received signal SIGABRT, Aborted.
[Switching t
Maarten Lankhorst wrote:
Hey Andy,
On 12/19/2011 10:17 PM, Andy Furniss wrote:
Andy Furniss wrote:
I compiled with -O0 but the backtraces are different - maybe there is
some randomness.
Remembered to attach them this time :-)
Thanks, but nothing seems to be obviously wrong there. I don&#
Maarten Lankhorst wrote:
Well, I found a video that appears to fail in a similar way to one of your
failure modes, they could both be the same but showing in different ways.
I've found a small mpeg1 vid that causes
mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl->length' failed
at
Maarten Lankhorst wrote:
Feel free to commit the result with those 3 changes without further review. :)
Mesa master is now failing with everything again for me (with -vc
ffmpeg12vdpau )
vl/vl_vlc.h:228:vl_vlc_eatbits: Assertion `vl_vlc_valid_bits(vlc) <=
num_bits' failed.
__
make[5]: Entering directory
`/home/andy/Src/Mesa-git/mesa/src/mesa/drivers/dri/swrast'
make[5]: *** No rule to make target `swrast_span.c', needed by
`swrast_span.lo'. Stop.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedes
I am getting a build error today - will have time later to investigate more.
I did notice, though that make distclean on head is not cleaning well
enough for me to git reset --hard back to somewhere that previously
worked without build errors.
I have to look at git status and manually clean u
Matt Turner wrote:
On Tue, Jan 31, 2012 at 6:18 AM, Andy Furniss wrote:
I am getting a build error today - will have time later to investigate more.
I did notice, though that make distclean on head is not cleaning well enough
for me to git reset --hard back to somewhere that previously worked
I am getting a build fail with vdpau since
commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt
Date: Thu Jan 26 18:48:20 2012 -0800
autoconf: Enable missing-prototypes errors when available.
After the removal of the dri driver link test, this should help avoid
the
Andy Furniss wrote:
I am getting a build fail with vdpau since
I see it's fixed now.
commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt
Date: Thu Jan 26 18:48:20 2012 -0800
autoconf: Enable missing-prototypes errors when available.
After the removal of the dri d
Maybe it's just me having a strange/old LFS system - but I am getting
build errors since
Make sure libGL.so links with libglsl
f53e7e981ef35ab64a084c8da6c67bd2d230fe33
Perhaps my build options are to blame -
CPPFLAGS="-I/home/andy/Src/Xorg-git/modular/include"
LDFLAGS="-L/home/andy/Src/Xor
Matt Turner wrote:
On Tue, Jan 31, 2012 at 3:12 PM, Andy Furniss wrote:
Maybe it's just me having a strange/old LFS system - but I am getting build
errors since
Are you subscribed? It seems so is everyone else. :P
Make sure libGL.so links with li
Brian Paul wrote:
make[3]: *** [r600_dri.so] Error 1
I've been running into weird build problems all day too (I'm seeing the
same problem with softpipe ATM using very simple configure options).
It seems that make -j8 is flakey too. I've had better luck omitting -j.
That definitely needs to be
Christian König wrote:
Hey Andy,
the attached patch should fix your issue.
Please test it.
Yes, it looks OK with that, thanks.
Andy.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
deathsim...@vodafone.de wrote:
From: Christian König
Based on work of Maarten Lankhorst this time.
I am getting new artifacts on r600 and softpipe (ignoring all the other
issues it has) when using -vc ffmpeg12vdpau, -vo vdpau alone or xvmc are
unaffected.
Some streams don't show it at all
Andy Furniss wrote:
deathsim...@vodafone.de wrote:
From: Christian König
Based on work of Maarten Lankhorst this time.
I am getting new artifacts on r600 and softpipe
Forgot to say - I don't get them if I reset git to 6/7 so it does seem
to be specifically
Rewrite the mpeg 1&2
Christian König wrote:
Thanks to you once more, it was just looking at the bytes left in the
buffer, but not the bits! So we ended up not decoding the last 32 bits
of a buffer.
That seems to have fixed it.
I just pushed a fix, and I'm really wondering where the heck do you get
all those nic
Andy Furniss wrote:
I've never tested with this before so don't know if it's a regression,
It is a regression since Rewrite the mpeg 1&2 bitstream parser
Maybe the stream is faulty - http://www.andyqos.ukfsn.org/swan.mpg
It's not just this stream - I've si
Christian König wrote:
Looks like there is some garbage at the end of the stream, mplayer is
also complaining nicely about "TS_PARSE: COULDN'T SYNC".
I played around a bit more, it seems that rather than garbage it's
because the TS stream just ends.
I now have a bit of a SD TV stream that I
Christian König wrote:
MPlayer 1.0rc4-4.5.2 works flawless with the snooker-short.ts video. So
it is definitely some difference between this version and svn version.
I agree - 1.0rc4 (4.2.3) also works for me.
The difference between sound/-nosound is probably just some different
memory alloc
Christian König wrote:
That makes the output black in case of decoding errors.
This fixes the green lines I was seeing with sw decode after the last
patch. It doesn't replace them with black.
It does make the broken hw decode on rv350 more black than it was.
_
I have an atypical and old x86 LFS setup but could build OK a couple of
days ago.
make distclean
git clean -dfx
git pull
LDFLAGS="-L/home/andy/Src/Xorg-git/modular/lib" ./autogen.sh
--prefix=/home/andy/Src/Xorg-git/modular --enable-debug --disable-egl
--enable-texture-float --enable-gallium-g
Brian Paul wrote:
Can you see if the patch/info on bug
https://bugs.freedesktop.org/show_bug.cgi?id=51335 helps?
Yes editing src/mesa/x86/Makefile.am to add -I$(top_srcdir)/include \
fixed it, thanks.
Git apply complained when I tried to use the actual patch (save as on
the link)
bash-3.2
Vadim Girlin wrote:
git://github.com/VadimGirlin/mesa.git
www: https://github.com/VadimGirlin/mesa/compare/r600-perf
Could anybody test them for regressions on non-evergreen cards
(R6xx/7xx/CAYMAN)?
nexuiz failed for me on rv790 (only thing I tested).
Brief screen full of black&white noise
Andy Furniss wrote:
Vadim Girlin wrote:
git://github.com/VadimGirlin/mesa.git
www: https://github.com/VadimGirlin/mesa/compare/r600-perf
Could anybody test them for regressions on non-evergreen cards
(R6xx/7xx/CAYMAN)?
nexuiz failed for me on rv790 (only thing I tested).
Brief screen full
Andy Furniss wrote:
Andy Furniss wrote:
Vadim Girlin wrote:
git://github.com/VadimGirlin/mesa.git
www: https://github.com/VadimGirlin/mesa/compare/r600-perf
Could anybody test them for regressions on non-evergreen cards
(R6xx/7xx/CAYMAN)?
nexuiz failed for me on rv790 (only thing I tested
Vadim Girlin wrote:
Thanks for testing. I've updated the branch with possible fix, could you
try it again?
It seems OK now.
I say seems because I had a bit of a build issue with llvm and make -j5,
but just make alone seemed to get past it.
Previously I tested with and without building with
Andy Furniss wrote:
Anyway this is the random, probably parallel build related fail I saw -
I don't know yet if it's just your tree + last change or not, but I
built several times OK when finding a working commit earlier.
I posted the wrong error - this one is from current head, th
Tom Stellard wrote:
This is an error caused by parallel build.
Ok, thanks for the confirmation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Vadim Girlin wrote:
On Mon, 2012-06-25 at 12:19 +0200, Andreas Boll wrote:
2012/6/24 Vadim Girlin :
On Sun, 2012-06-24 at 17:43 +0400, Vadim Girlin wrote:
Allocate flushed depth texture in the VRAM if we aren't going to access it by
CPU. If we need CPU access later, then it'll be reallocated i
Don't know if it's old gcc(s) or 32bit but I can't build current master -
../../src/gallium/auxiliary/util/u_math.h:385: error: integer constant
is too large for 'long' type
Looks like I need ULL on the constants in
d069d8ef3835c65d1fac755b26080f284f7b7b49
util: Added functions for checking
Marek Olšák wrote:
FYI, I have pushed your DB decompression fix, because my
not-yet-published work depends on it.
I can't be sure whether todays changes caused this, because I can't
reproduce it :-(
But I haven't seen it before and didn't see it 24hrs ago when I ran the
same test.
Today I
Andy Furniss wrote:
Marek Olšák wrote:
FYI, I have pushed your DB decompression fix, because my
not-yet-published work depends on it.
I can't be sure whether todays changes caused this, because I can't
reproduce it :-(
Ok so I can reproduce if I am patient enough.
Don't kno
Marek Olšák wrote:
On Sun, Jul 15, 2012 at 12:57 PM, Andy Furniss wrote:
Marek Olšák wrote:
FYI, I have pushed your DB decompression fix, because my
not-yet-published work depends on it.
I can't be sure whether todays changes caused this, because I can't
reproduce it :-(
But
RV790 testing with ETQW - mesa commit
commit 99c65bac341f808279a8a847158ace4f058aa72e
Author: Marek Olšák
Date: Sun Feb 26 20:37:43 2012 +0100
r600g: implement wait-free buffer transfer for DISCARD_RANGE
Getting corruption and below.
Updating to current drm-core-next didn't help.
Reset
Marek Olšák wrote:
Hi Andy,
this should be fixed by the commit:
commit c3c83af380d703cdc24475bd39baa1722c333b44
Author: Marek Olšák
Date: Wed Jul 18 18:33:37 2012 +0200
r600g: setup streamout before calling last r600_need_cs_space before
drawing
Please let me know if you still have a
201 - 300 of 389 matches
Mail list logo
