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 vdpaumplayer
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
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
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
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
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:
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
Maarten Lankhorst wrote:
No point in having it when just having sampler_view_planes is good enough.
Signed-off-by: Maarten Lankhorstm.b.lankho...@gmail.com
---
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
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
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 with vdpau
Maarten Lankhorst wrote:
The brokenness in vlVdpVideoMixerRender was compensating for
brokenness in vlVdpPresentationQueueDisplay, so fix both at
the same time.
Signed-off-by: Maarten Lankhorstm.b.lankho...@gmail.com
Tested-by: Andy Furniss andy...@ukfsn.org
Lankhorstm.b.lankho...@gmail.com
Tested-by: Andy Furniss andy...@ukfsn.org
___
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 Lankhorstm.b.lankho...@gmail.com
Tested-by: Andy Furniss andy...@ukfsn.org
___
mesa-dev mailing list
mesa-dev
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 remove
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
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 to Thread
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't
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.
Christian König wrote:
Hi,
sorry for the late reply, have been in Canada on a team meeting.
Did you got it working Andy or do you need some more help?
It's OK, now thanks.
I have started setting LDFLAGS as Dan suggested.
I think the overall situation with finding libraries in the mesa
fykc...@gmail.com wrote:
Depending on how it was configured mplayer needs (probably)
/etc/X11/XvMCConfig containing /path/to/your/lib/libXvMCr600.so
I add the path /usr/lib/libXvMCr600.so to /etc/X11/XvMCConfig, but
mplayer seems not invoke it (No r600 in strace or /proc/pid/maps).
Maybe I
fykc...@gmail.com wrote:
Hi,
在 2011年8月2日 下午8:16，fykc...@gmail.comfykc...@gmail.com 写道：
Depending on how it was configured mplayer needs (probably)
/etc/X11/XvMCConfig containing /path/to/your/lib/libXvMCr600.so
I add the path /usr/lib/libXvMCr600.so to /etc/X11/XvMCConfig, but
mplayer seems
fykc...@gmail.com wrote:
Does it work now then?
No, it renders a corrupted playback
http://dev.lemote.com/files/upload/software/temp/newmobcal1920-playback.png
I guess that may be related with driver or DRM stack, after playback,
my desktop corrupts
Maybe this is already known/just not complete yet, but as I've
previously written that r600 -vo vdpau without decode looked OK I ought
to mention it as I've just noticed.
1080 height mpeg2 or h264 internally is 1088, the bottom 8 lines
should be cropped off, which is what -vo x11/gl/xv/xvmc
deathsim...@vodafone.de wrote:
From: Christian Königdeathsim...@vodafone.de
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
Andy Furniss wrote:
deathsim...@vodafone.de wrote:
From: Christian Königdeathsim...@vodafone.de
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
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
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 12 bitstream parser
Maybe the stream is faulty - http://www.andyqos.ukfsn.org/swan.mpg
It's not just this stream - I've since found one that is encoded
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
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
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
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
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
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
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, please send me
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 sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader
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
Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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
Christian König wrote:
When the video buffer turns out to be larger than
requested by the application we shouldn't upload
or download more data into / from it original requested.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39309
Hi
It doesn't fix decoding (for my 9600) - which that
Andy Furniss wrote:
Christian König wrote:
When the video buffer turns out to be larger than
requested by the application we shouldn't upload
or download more data into / from it original requested.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39309
Hi
It doesn't fix decoding (for my
Andy Furniss wrote:
Andy Furniss wrote:
Christian König wrote:
When the video buffer turns out to be larger than
requested by the application we shouldn't upload
or download more data into / from it original requested.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39309
Hi
It doesn't
Emeric Grange wrote:
2012/6/7 Andy Furniss andy...@ukfsn.org
I don't know how Christian handles his mail, but Vodafone are blocking my
ISP's SMTP address, so this is just going to the list - unless someone else
can reply all.
Replied all, I hope it helps.
Emeric
Thanks, hopefully
Christian König wrote:
Unfortunately it's not quite right, there's an artifact on
r300 s/w
decode = thin green lines right and bottom.
R600 with the patch doesn't show it as much, but 1080
stuff does have
one at the bottom.
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
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)
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 blackwhite 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
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, the last one
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 vadimgir...@gmail.com:
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
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
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 know when I'll get
Marek Olšák wrote:
On Sun, Jul 15, 2012 at 12:57 PM, Andy Furniss andy...@ukfsn.org 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
RV790 testing with ETQW - mesa commit
commit 99c65bac341f808279a8a847158ace4f058aa72e
Author: Marek Olšák mar...@gmail.com
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
Marek Olšák wrote:
Hi Andy,
this should be fixed by the commit:
commit c3c83af380d703cdc24475bd39baa1722c333b44
Author: Marek Olšák mar...@gmail.com
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
Andy Furniss wrote:
Marek Olšák wrote:
Hi Andy,
this should be fixed by the commit:
commit c3c83af380d703cdc24475bd39baa1722c333b44
Author: Marek Olšák mar...@gmail.com
Date: Wed Jul 18 18:33:37 2012 +0200
r600g: setup streamout before calling last r600_need_cs_space
before drawing
Andy Furniss wrote:
Andy Furniss wrote:
Marek Olšák wrote:
Hi Andy,
this should be fixed by the commit:
commit c3c83af380d703cdc24475bd39baa1722c333b44
Author: Marek Olšák mar...@gmail.com
Date: Wed Jul 18 18:33:37 2012 +0200
r600g: setup streamout before calling last
Kernel is dcn card is rv790 - vdpau csc/scale regressed.
This only shows with 422 colour so most things work.
commit 7c371f46958910dd2ca9487c89af1b72bbfdada9
Author: Marek Olšák mar...@gmail.com
Date: Sat Jul 28 00:38:42 2012 +0200
r600g: make sure copying of all texture formats is
Marek Olšák wrote:
Does the attached patch fix this issue?
Not properly - it fixes the invalid command stream but the output is not
quite right -
http://www.andyqos.ukfsn.org/vdpau-422-patched.png
Marek
On Mon, Aug 6, 2012 at 5:40 PM, Andy Furniss andy...@ukfsn.org wrote:
Kernel
Marek Olšák wrote:
Do you have any idea what could be wrong with the patch? Also could
please tell me how to setup VDPAU and where to download the tests, so
that I can test this.
I don't know about the patch.
One thing which may be a clue or a red herring is that when Christian
first
Kenneth Graunke wrote:
On 08/10/2012 07:51 AM, Chad Versace wrote:
On 08/09/2012 01:22 PM, Kenneth Graunke wrote:
On 08/09/2012 01:10 PM, Chad Versace wrote:
Add -Wno-narrowing to CXXFLAGS for gcc.
This removes warnings of the form
warning: narrowing conversion of X from 'int' to
Chad Versace wrote:
Andy, I just reverted the patch.
Ok, thanks
This opens a larger question. gcc 4.2 was released in May 2007, over 5 years
ago, and received its last update in May 2008. How old of a gcc should new Mesa
releases support?
That's a fair point - that was on an old LFS AGP
Andy Furniss wrote:
Chad Versace wrote:
Andy, I just reverted the patch.
Ok, thanks
This opens a larger question. gcc 4.2 was released in May 2007, over 5
years
ago, and received its last update in May 2008. How old of a gcc should
new Mesa
releases support?
That's a fair point
Chad Versace wrote:
This opens a larger question. gcc 4.2 was released in May 2007, over 5 years
ago, and received its last update in May 2008. How old of a gcc should new Mesa
releases support?
That's a fair point - that was on an old LFS AGP box I don't really use apart
from booting now and
Maybe I am messing up somewhere, but I was previously OK with llvm 3.1.
32 bit old LFS setup with a 4890 card.
Now I need to use git tstellar/llvm with
--enable-experimental-targets=AMDGPU.
On head I get a gpu lock with anything gl, this from gears -
radeon :01:00.0: GPU lockup CP stall
Mathias Fröhlich wrote:
Hi Vincent,
On Tuesday, November 06, 2012 12:14:52 Vincent Lejeune wrote:
Do you use the master branch ?
Yes, e3213f01f7764af573ed641a7bc98dde5824e321 is my current head in llvm.
This commit generates some llvm.R600.store.pixel.color/stencil/depth
intrinsics, which
Mike Lothian wrote:
Hi Andy
Try the LLVM ebuilds in the FireBurn overlay - they turn on intrinsics
without using the debug versions
Thanks, but I am using LFS.
I'm still seeing the issues when running some games but least it won't be a
debug build
OK, I'll try a non debug soon just to
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/r600_asm.c
b/src/gallium/drivers/r600
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/r600_asm.c
b/src/gallium
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]:
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
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 it does fix
Christian König wrote:
Hi guys,
just wanted to give a little status update for the xvmc state tracker
for r600 hardware. I think I found most of the bugs related to
progressive video playback and it now seems to work 100%. I also started
to implement interlaced video support, which already
Christian König wrote:
Hi guys,
just wanted to give a little status update for the xvmc state tracker
for r600 hardware. I think I found most of the bugs related to
progressive video playback and it now seems to work 100%.
All the old compliance progressive streams (ones ending 015.m2v, 015
Christian König wrote:
I figured out an usable workaround for motion_vertical_field_selection
and now even field based mc looks 99% correct, only some minor colored
artefacts left in your Pendulum.mpg test video. If you like you could
test some other interlaced videos now.
It's certainly
Christian König wrote:
Hi everybody,
just wanted to note that I got the first implementation of the XvMC iDCT
code working.
Cool, but I just updated both trees and have lost rendering on my rv670,
the window is just mid grey.
Another Issue which started with the last batch of changes/ddx
Christian König wrote:
Could you fire up gdb and give me an output of the idct structure at
frame 3? To do so make sure gdb is installed and then run the following
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6bfa6d0 (LWP 2455)]
r600_bo_reference
Christian König wrote:
I didn't mention at the time as I thought it may go away when IDCT was
enabled.
That's interesting, it looks like the pointer to the vertex shader is
NULL. That would also explain the gray picture, but there is in assert
if the shader can't be created in the init
Christian König wrote:
I just committed some additionally error handling, and you should add
--enable-debug to your configure options. Just run the following
commands:
make distclean
../configure --with-dri-drivers=r600 --enable-gallium-r600
--with-state-trackers=xorg,xorg/xvmc
Andy Furniss wrote:
--enable-debug
make
Hmm, it's working now. I notice the tree has changed from earlier with a
merge - maybe something in that?
Testing, it seems like it's just the --enable-debug that has made the
difference between working and not.
Reverted the last commit
Michel Dänzer wrote:
On Die, 2010-11-23 at 01:27 +, Andy Furniss wrote:
Andy Furniss wrote:
--enable-debug
make
Hmm, it's working now. I notice the tree has changed from earlier with a
merge - maybe something in that?
Testing, it seems like it's just the --enable-debug that has made
Christian König wrote:
Am Dienstag, den 23.11.2010, 14:17 + schrieb Andy Furniss:
Apart from -DDEBUG the extra -g is the only difference I have spotted in
a diff of the make outputs so far.
Ok, i'm just an idiot. totally forgot that an assert evaluates to
nothing on a non debug build
Christian König wrote:
http://www.w6rz.net/ramp.zip
The end result looks really good now, at least how far I can tell.
It's much better than it was and the levels are roughly correct.
On close inspection it is not consistent, the main static pattern being
different pixels in the corners
Andy Furniss wrote:
Christian König wrote:
A fix is checked in, so please try again.
Working now without debug.
With current git this is crashing again for me on quit. Also seeing
extra artifacts on the Pendulum.mpg.
*** glibc detected *** /home/andy/Src/Mplayer-svn/mplayer/mplayer
Christian König wrote:
Thanks for the info, I fixed at least one bug which could cause this,
but there are probably a bunch more. Please try again.
I'm currently optimizing the shader generation in r600g a bit, I will
try to fix the rest of the bugs when this is done.
OK. It still crashes on
Christian König wrote:
Hi,
in the past couple of weeks i tried to optimize the shaders used for the
iDCT and MC code. Beside optimizing the TGSI code for the shaders i
optimized the TGSI-R600 code generation in r600g quite a bit:
I am getting an error trying to build your latest xvmc mesa,
Christian König wrote:
Ups, I forgot to push again after committing the merge fixes, please
pull and try again.
Building OK now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Kenneth Graunke wrote:
Now that this works with both make and SCons, builtin_function.cpp no
longer needs to live in the repository.
After updating talloc to avoid a build error I am now getting -
Regenerating builtin_function.cpp...
python -t -O -O builtins/tools/generate_builtins.py
Kenneth Graunke wrote:
Right...as Corbin mentioned, the script is written for Python 2.6.
I can change it to 2.5 if necessary, but 2.6 has been out for over two years,
so I didn't think it'd be a problem.
If 2.6 is needed/better then who am I to ask for 2.5 :-).
Maybe configure should be
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
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
1 - 100 of 379 matches
Mail list logo
