On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote:
On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner aplatt...@nvidia.com wrote:
__glXInitializeVisualConfigFromTags doesn't skip the payload of unrecognized
tags. Instead, it treats the value as if it were the next tag, which can
Hey. I get following error when try to compile mesa-git with
--enable-gallium-llvm.
g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread
-lffi -ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format
-Wl,--start-group -lXext -lXxf86vm -lXdamage -lXfixes -lX11-xcb -lX11
On Mon, May 3, 2010 at 12:52 PM, yaiba.kurog...@interia.pl wrote:
Hey. I get following error when try to compile mesa-git with
--enable-gallium-llvm.
g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread -lffi
-ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com
wrote:
This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
Compiz shows dark screen.
(Using nouveau drivers)
Without this commit
I am sure they're not advertised as supported render targets. You can find
the list of render target formats in r300_texture.c :
r300_translate_colorformat.
Yes the 3D blit is lossless for low precision formats. The thing is, as you
say, I'd have to change both the format and dimensions, i.e.
On Mon, May 3, 2010 at 3:52 AM, yaiba.kurog...@interia.pl wrote:
Hey. I get following error when try to compile mesa-git with
--enable-gallium-llvm.
g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread -lffi
-ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format
This gives a ~30% shader optimization time improvement on blender.
Tested by comparing the dumped LLVM modules.
Current ordering:
time ~/llvm-git/obj/Release-Asserts/bin/opt l.bc -constprop -instcombine
-mem2reg -gvn -simplifycfg
real0m1.126s
user0m1.108s
sys 0m0.012s
With this
On 02.05.2010 13:08, José Fonseca wrote:
On Sun, 2010-05-02 at 02:36 -0700, Dave Airlie wrote:
On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca jfons...@vmware.com
wrote:
I read the extension and it is not crystal clear, but it seems to
imply the swizzles are orthogonal to the format, and applied
Jakob Bornecrantz wallbra...@gmail.com writes:
A half backed idea would be to have to run a opt in slightly unstable
branch, instead of going full multi-branch development model. Where
bug-fixes can go in freely, small features can go in after a review
of the changes by the module maintainer.
On 2010-05-03 19:00, José Fonseca wrote:
Török,
Thanks.
I didn't see as much improvement (most of the stuff I've been playing
with has actually simple shaders), but I saw no regression so I've
commited it. We have more benchmarks running continuously from git so
once the commit goes
Jose Fonseca wrote:
I read the extension and it is not crystal clear, but it seems to imply the swizzles are orthogonal to the format, and applied as the very last step before being used in a shader. That is, the semantics are the same of adding a swizzle instruction after a TEX opcode,
Dave Airlie wrote:
In looking at adding EXT_texture_swizzle I'm a bit confused about what
exactly should happen with BGRA textures, as on r300 we use the
texture swizzling to do BGRA, so we would have some interaction at
that point.
To make sure we test for this I've made the following
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned by
util_format_name, it makes debug logs shorter. The second patch adds
util_format_is_plain.
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index fb6ade5..d851c31 100644
---
On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote:
Jose Fonseca wrote:
I read the extension and it is not crystal clear, but it seems to imply the
swizzles are orthogonal to the format, and applied as the very last step
before being used in a shader. That is, the semantics are the same
Dave Airlie wrote:
On Sat, May 1, 2010 at 6:47 PM, Dave Airlie airl...@gmail.com wrote:
In looking at adding EXT_texture_swizzle I'm a bit confused about what
exactly should happen with BGRA textures, as on r300 we use the
texture swizzling to do BGRA, so we would have some interaction at
that
On Mon, 2010-05-03 at 10:25 -0700, Marek Olšák wrote:
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned
by util_format_name, it makes debug logs shorter. The second patch
adds util_format_is_plain.
diff --git a/src/gallium/auxiliary/util/u_format.h
On Mon, 2010-05-03 at 10:29 -0700, José Fonseca wrote:
On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote:
Jose Fonseca wrote:
I read the extension and it is not crystal clear, but it seems to imply
the swizzles are orthogonal to the format, and applied as the very last
step before
On Mon, 2010-05-03 at 10:42 -0700, Brian Paul wrote:
Marek Olšák wrote:
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned by
util_format_name, it makes debug logs shorter. The second patch adds
util_format_is_plain.
I'd prefer to keep the long format
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vinson Lee wrote:
Module: Mesa
Branch: master
Commit: 9446fd8f69564e09ffd0f28735a99c510f84bb62
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9446fd8f69564e09ffd0f28735a99c510f84bb62
Author: Vinson Lee v...@vmware.com
Date: Sat
On Monday 03 May 2010 14:17:30 Alex Deucher wrote:
On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote:
I think it's worth exploring a policy of somehow tagging commits as
candidates for back-porting to the stable branch so they can be some
level of accounting and tracking.
On Mon, May 3, 2010 at 2:26 PM, Zack Rusin za...@vmware.com wrote:
On Monday 03 May 2010 14:17:30 Alex Deucher wrote:
On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote:
I think it's worth exploring a policy of somehow tagging commits as
candidates for back-porting to the
On Mon, 2010-05-03 at 13:11 -0600, Brian Paul wrote:
Xavier Chantry wrote:
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com
wrote:
This commit breaks compiz completely here on nvidia G50 (Geforce
Dan Nicholson wrote:
Brian,
I'm putting forward this request completely understanding your
position why you don't want automake and libtool in your project.
However, I think that mesa has outgrown the static Makefiles approach
for a number of reasons. For a project that's grown to the
On Mon, May 3, 2010 at 9:11 PM, Brian Paul bri...@vmware.com wrote:
This commit also causes piglit fbo-3d test to fail with both llvmpipe
and nv50 gallium.
http://img163.imageshack.us/img163/535/fbo3d.png
Can you retest now?
Yup, fbo-3d is back on both nv50 and llvmpipe/swrastg. Thanks !
On Mon, 2010-05-03 at 15:18 -0600, Brian Paul wrote:
Maxim Levitsky wrote:
On Mon, 2010-05-03 at 13:11 -0600, Brian Paul wrote:
Xavier Chantry wrote:
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
The libtool script wrapped every cc command and it slowed the build
process considerably. Have you done any before/after build time
comparisons? I build a *lot*.
This was traditionally the #1 complaint about autotools. Over
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
Vinson Lee wrote:
Module: Mesa
Branch: master
Commit: 9446fd8f69564e09ffd0f28735a99c510f84bb62
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9446fd8f69564e09ffd0f28735a99c510f84bb62
Author: Vinson Lee
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
Vinson Lee wrote:
Module: Mesa
Branch: master
Commit: 9446fd8f69564e09ffd0f28735a99c510f84bb62
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9446fd8f69564e09ffd0f28735a99c510f84bb62
Author:
Ok. I removed -Wl,--as-needed and now compilation went smooth.However
when I enable gles1 and gles2 and add es state tracker I got something
like this:
mklib: Making Linux shared library: libGL.so.1.2
mklib: Installing libGL.so.1.2 libGL.so.1 libGL.so in ../../lib
make[2]: Opuszczenie
29 matches
Mail list logo
