Andy Furniss wrote:
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
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
Date: Wed Jul 18 18:33:37 2012 +0200
r600g: setup streamout before calling last r600_need_cs_space
before
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
Date: Sat Jul 28 00:38:42 2012 +0200
r600g: make sure copying of all texture formats is accelerated
[drm:ra
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 wrote:
Kernel is dcn card is rv790
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 implemen
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 'float'
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 b
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 a
Andy Furniss wrote:
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
Date: Wed Jul 18 18:33:37 2012 +0200
r600g: setup streamout before calling last
Marek Olšák wrote:
I have fixed this master. You were right - tiling on 422 was broken.
Ok, thanks, working now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Vadim Girlin wrote:
Use 1/256 for R6xx/7xx, 1/4096 for evergreen, instead of default 1/16.
Helps to pass some piglit tests (fbo, multisample).
It also fixes the worse inaccuracies seen when using vdpau mpeg2 decode
on my rv790. It's still not as accurate as s/w, but the remaining errors
mayb
Marek Olšák wrote:
OpenSUSE is (was?) shipping r300g with LLVM disabled. Can you believe it?
Poor users with SWTCL chipsets... and bad reputation for us too.
---
configure.ac |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8989c2b..
Christian König wrote:
Hi Andy and everybody on the list,
sorry for the late reply, but i've been on vacation the last couple of
days.
Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss:
In addition to the quit crash I notice that resizing will also crash.
Should be fixed b
Andy Furniss wrote:
So is there something still missing for the xvmc state tracker, or can I
continue with implementing the vdpau state tracker?
There is a fullscreen issue - with 4/3 content on 16/9 screen the side
black bars are drawn to leave 4/3 viewable, but the content is still
Andy Furniss wrote:
There has been a regression though -
[g3dvl] remove resource_format workaround
causes quite bad artifacts on newmobcal.
I can get rid of the new artifacts for xvmc with the patch below.
ffmpeg12vdpau shows the same "new" artifacts, but is not fixed by this.
di
Christian König wrote:
The problem is more complicated than this, using a signed buffer format
is just a workaround, the real solution is to implement blender clamping
in r600g. You could try this (temporary) patch until I figured out how
to do this correctly on all supported hardware:
--- a/sr
Andy Furniss wrote:
It does fix xvmc - my chip is RV770 (well RV790) so I wasn't expecting
any change.
I've got a RV670 box that I test with occasionally, so I thought I would
try that - I didn't get to test the patch as I found it has suffered a
separate regression, whi
Christian König wrote:
But how do you test this? Are you using the mplayer or some other tool
to get the vdpau output playing without synchronisation? Asking because
I'm still searching for something similar to mpeg2play_accel, a very
simple tool to hack and test the interface.
I am just using
Andy Furniss wrote:
dd6cd206a6395be651bc965580e17c0d63513c7b
[g3dvl] correctly implement non power of two buffers
regresses rendering on my RV670.
I see with the weekend changes and master merge that the "new" xvmc
artifacts on my rv790 are now gone without patching.
mplayer
Christian König wrote:
My rv670 is still suffering quite different problems both xvmc and vdpau -
Please try the following patch with xvmc:
--- a/src/gallium/drivers/r600/r600_video_context.c
+++ b/src/gallium/drivers/r600/r600_video_context.c
@@ -40,5 +40,5 @@ r600_video_create(struct pipe_scr
Christian König wrote:
My rv670 is still suffering quite different problems both xvmc and vdpau -
http://www.andyqos.ukfsn.org/pend-rv670-vdpau.png
http://www.andyqos.ukfsn.org/mobcal-rv670-vdpau.png
It's on my todo list, but I don't have any idea what's causing this,
probably more a bug inside
Christian König wrote:
Am Montag, den 16.05.2011, 19:54 +0100 schrieb Andy Furniss:
I noticed another strange thing with pipe-video on my rv670.
Until recently there was a bug that made the mesa demo lodbias misrender.
It's fixed now in master and pipe-video, but if I use pipe-video +
Christian König wrote:
Hello list,
I'm about to commit the attached patches, they add checks that the
correct development packages are installed before enabling the different
state trackers.
Don't know if this one is specific to my setup/options but -
./autogen.sh --prefix=/home/andy/Src/Xorg
Andy Furniss wrote:
make[3]: *** No rule to make target
`../../../../src/gallium/winsys/sw/xlib/libws_xlib.a', needed by
`../../../../lib/gallium/libvdpau_softpipe.so'. Stop.
I see this is fixed now in master.
I have another problem though, vdpau-softpipe is not using my
LD_LIBRA
Andy Furniss wrote:
I have another problem though, vdpau-softpipe is not using my
LD_LIBRARY_PATH so fails to find where my lvdpau is.
As you can see from below r600 does use it and adds
-L/home/andy/Src/Xorg-git/modular/lib and links OK.
Maybe this doesn't come from LD_LIBRARY_PAT
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
mak
fykc...@gmail.com wrote:
Hi all,
I've tried mesa-7.11rc4 with pipe-video patch on a Loongson3A based notebook:
* CPU: 4-core MIPS64 compatible (Little-endian, 64bit kernel with an
o32 userland)
* Graphics: RS780E
I tried h264、mpeg2 samples with mplayer -vo vdpau and xvmc, non of them works:
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 s
fykc...@gmail.com wrote:
Hi,
在 2011年8月2日 下午8:16，fykc...@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 not invoke it (N
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
http://dev.lemote.com/files/upload/software/
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
Christian König wrote:
This is a shader based median filter, generally
used for noise reduction, it could still need some
improvements, but should usually work out of the box.
Hi Christian.
I haven't really tested these properly yet, but did find a small issue
with low strength denoise and mp
Christian König wrote:
A filter strength of zero or one doesn't make any
sense.
Low strengths work OK now, but this patch seems to have made denoise
stronger. Maybe I am looking at the wrong material, but more than 0.2
for sharpen or denoise looks too way much.
Benchmark wise sharpen seems
Christian König wrote:
Benchmark wise sharpen seems cheap, but denoise at full strength is
expensive, and comparing full on before and after the patch on 1080
material shows that it's doing more work.
Correct, before anything under 0.4 would have given you a zero or one
pixel window and 1.0 wou
Christian König wrote:
Hi everyone,
the following patchset adds most of the still missing functionality to the
VDPAU state tracker, including the support for bitmap surfaces so Alpha
Substation Subtitles in mplayer now seems to work fine.
It also improves the general video playback functional
Christian König wrote:
xvmc is much better now its' buffers don't get mixed up, I saw it tear
once but couldn't repeat.
I spoke too soon about xvmc - I was concentrating on SD which is "fixed"
by the patches.
HD with or without these is still quite broken.
It doesn't look like out of order
Christian König wrote:
I made some tests and measured the time between each page flip, and I
have to say: WOW! I'm deeply impressed that you recognized that there is
something wrong with the naked eye!
With 30/60 and streams with lots of motion it looked quite bad.
So now I have the strong t
Christian König wrote:
This gets xine working with VDPAU.
Didn't for me but my xine may be borked :-(
But then YUY2 with mplayer is also failing -
vl/vl_video_buffer.c:451:vl_video_buffer_create_ex: Assertion
`tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_444' failed.
Same stream works w
Christian König wrote:
That assertion is indeed incorrect now, but the problem lies even
deeper. Neither our MPEG2 decoder nor xines software decoder can handle
4:2:2 streams, so I couldn't find a way to test that probably. Xine is
just checking for YUY2 support before using VDPAU in any way, so
Emeric Grange wrote:
With today series I get that output :
http://img807.imageshack.us/img807/5593/cran07032012184105.png
I see the same as you - xine works, but can be made to fail.
mplayer sw decode + yuy2 vdpau output is corrupted.
By the way something seemed wrong while reading mplayer
Christian König wrote:
mplayer sw decode + yuy2 vdpau output is corrupted.
Yeah, still working on that. The problem is tilling related, just
disable 2D tilling and it works like a charm. I think I've found the
problem right now and going to send out some fixed patches in the next
couple of minu
Christian König wrote:
Thanks for all that info.
Anyway, I will be busy with UVD code review next week so I won't have
time to work on the state tracker for some time now, so that has to wait
for a little while longer.
Ahh, UVD - good luck with the review. and thanks for all the vdpau work
Christian König wrote:
That wasn't working as supposed.
What is the status of the recent interlaced commits?
AFAICT not enabled yet - I did have a look by doing
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 113dad6..99ef20f 100644
--- a/src/g
Christian König wrote:
Hui? Well i thought I got weave working also, obviously need to take a
look at it again. Anyway, this isn't really interesting until somebody
implements a temporal and/or temporal-spatial deinterlacing. I just
wanted to have the needed infrastructure ready and public avail
Marek Olšák wrote:
It's already done in _mesa_validate_Draw* and it's not needed to do it again
unless I am missing something.
---
src/mesa/vbo/vbo_exec_array.c | 20
1 files changed, 0 insertions(+), 20 deletions(-)
For me (rv790) this causes an assert with nexuiz (ha
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 bu
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 decodi
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 do
Emeric Grange wrote:
2012/6/7 Andy Furniss
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 it sh
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.
make[3]: Entering directory
`/home/andy/Src/Mesa-git/mesa/src/gallium/targets/dri-r600'
/bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker 'g++'
-ldflags '-L/home/andy/Src/Xorg-git/modular/lib -L/usr/lib -lpthread
-ldl -lm ' \
target.o
../../../../src/mesa/drive
Brian Paul wrote:
On 09/15/2012 05:56 AM, Andy Furniss wrote:
make[3]: Entering directory
`/home/andy/Src/Mesa-git/mesa/src/gallium/targets/dri-r600'
/bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker
'g++' -ldflags '-L/home/andy/Src/Xorg-git/modular/lib
Marek Olšák wrote:
Hi,
this is actually a very small cleanup that got unexpectedly big. I
really underestimated the size of gallium.
Build nit -
make[3]: Entering directory
`/home/andy/Src/Mesa-git/mesa/src/gallium/auxiliary'
gcc -c -I. -I../../../src/gallium/include
-I../../../src/gallium/
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 w
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/r600_asm.c
index 5f2548e..f06af44 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/sr
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 see
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
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 looks
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:
We currently only support 4:2:0 and deinterlace the luma channel very
early when copying to video buffers and to be honest, I have no idea how
interlacing is handled on chroma channels when there is only one chroma
value per four result pixels. I have read the section in t
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 bette
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 ch
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 (radeon=0x8f3c5
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 function
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 --enable-gall
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 comm
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 tha
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 buil
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 o
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 q
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, ma
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
/home/a
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 chan
I guess it's since glsl/Makefile: glcpp doesn't need libglsl.a
that make -j4 now errors, make works. I always do make distclean and
autogen before builds.
gcc: ../../src/glsl/libglsl.a: No such file or directory
make[2]: *** [glcpp/glcpp] Error 1
make[2]: *** Waiting for unfinished jobs
m
As I have mesa/libdrm/xorg gits installed under home and my system
versions are very old and broken/missing I need to get cmake to use
custom paths.
With current git even though glew include dir is settable with ccmake it
still insists on looking in /usr/include. I have tried many combinations
Marek Olšák wrote:
I just pushed commit c880d607992ae7bdc29f70f8eec34c481fed7811 to piglit,
which should fix this.
Thanks, that fixes glew - but I don't get much further because it still
tries to link against old Xlibs in /usr rather than new ones in custom path.
I must admit I haven't tried
tom fogal wrote:
Andy Furniss writes:
I've just had to rm -r and re-clone because I couldn't find how to
distclean :-).
"git clean -df" makes things pretty clean ;)
I don't think I know how to distclean in cmake either... the workaround
for cmake is to just use ou
I am getting a build fail today -
mklib: Making Linux static library: libglapi.a
ar: creating libglapi.a
make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/mapi/glapi'
make[2]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/glsl'
flex --nounistd -oglcpp/glcpp-lex.c glcpp/glcpp-l
Andy Furniss wrote:
I am getting a build fail today -
mklib: Making Linux static library: libglapi.a
ar: creating libglapi.a
make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/mapi/glapi'
make[2]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/glsl'
flex --nounistd -og
Brian Paul wrote:
On Thu, Mar 3, 2011 at 3:44 AM, Andy Furniss wrote:
Andy Furniss wrote:
I am getting a build fail today -
mklib: Making Linux static library: libglapi.a
ar: creating libglapi.a
make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/mapi/glapi'
make[2]: Ent
Marek Olšák wrote:
Hi,
libtxc_dxtn has got new bug fixes in my private branch recently (e.g. Bug
24016 was fixed and some piglit tests too) and I thought it would be useful
to make an announcement.
I have tagged libtxc_dxtn 1.0.0 in my repository and it can be obtained via
git from here:
http:
Dan Nicholson wrote:
You have a libtool older than 2.2. You can replace this with
AC_PROG_LIBTOOL
AC_DISABLE_STATIC
Thanks, installed now using those.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/list
Benjamin BELLEC wrote:
Hello,
I have compiled the last Mesa code (and libtxc_dxtn from Marek Olšák's
branch) in order to test the S3TC support recently pushed in r600g.
In his commit
(http://cgit.freedesktop.org/mesa/mesa/commit/?id=8e0437914bb786d0b05be8f95e4ff37bf5a19f44),
Dave Airlie says "St
Andy Furniss wrote:
I also get 1/2 second stalls occasionally.
These are now fixed with today's d-r-t update but perf has taken quite a
big hit with quality settings on high.
Perf in other games doesn't seem to be affected.
___
mesa-d
301 - 389 of 389 matches
Mail list logo
