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 katal
On Mon, May 3, 2010 at 6:47 PM, Maxim Levitsky wrote:
> Note that not git tip of mesa makes compiz abort on:
>
> compiz: main/buffers.c:371: _mesa_drawbuffers: Assertion `mask[output] != ~0u'
You may have to do a 'make clean' because of a stale dependency.
-Brian
___
On Mon, 3 May 2010 15:15:25 -0700, Dan Nicholson wrote:
> On Mon, May 3, 2010 at 2:04 PM, Brian Paul wrote:
> > So anyway, I just checked out Eric's git tree and the automake branch.
> > I ran "./autogen.sh":
> >
> > $ ./autogen.sh
> > autoreconf: Entering directory `.'
> > autoreconf: configure.
https://bugs.freedesktop.org/show_bug.cgi?id=27612
--- Comment #1 from Vinson Lee 2010-05-03 18:00:27 PDT ---
The build is probably picking up /usr/include/drm/i915_drm.h over
/usr/include/libdrm/i915_drm.h, and /usr/include/drm/i915_drm.h doesn't have
I915_MADV_DONTNEED.
This is likely fixed by
On Tue, 2010-05-04 at 02:10 +0300, Maxim Levitsky wrote:
> On Mon, 2010-05-03 at 16:48 -0600, Brian Paul wrote:
> > Maxim Levitsky wrote:
> > > 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:
> >
On Mon, 2010-05-03 at 16:48 -0600, Brian Paul wrote:
> Maxim Levitsky wrote:
> > 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 O
Maxim Levitsky wrote:
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 wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
wrote:
This commit
On Tue, May 4, 2010 at 12:09 AM, Brian Paul wrote:
> My guess is that the code GCC actually generates for both versions (the
>> original and the memcpy version) is pretty close to identical. At -O0,
>> the memcpy version should be smaller / faster / have better stickers.
>>
>> In this particula
On Mon, May 3, 2010 at 2:04 PM, Brian Paul wrote:
> 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
>
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: Vinson
-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
-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. Ov
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 wrote:
> On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
> wrote:
> >
On Mon, May 3, 2010 at 9:11 PM, Brian Paul 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 !
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 wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
wrote:
This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
Compiz shows dar
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 complexity
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 wrote:
> >> On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
> >> wrote:
> >>> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
> >>> Compiz shows da
Ian Romanick wrote:
-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
Date: Sat Ma
Xavier Chantry wrote:
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
wrote:
This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
Compiz shows dark screen.
(Using nouveau drivers)
Without this commit compiz works almost pe
On Mon, May 3, 2010 at 2:26 PM, Zack Rusin wrote:
> On Monday 03 May 2010 14:17:30 Alex Deucher wrote:
>> On Mon, May 3, 2010 at 2:09 PM, Brian Paul 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
On Monday 03 May 2010 14:17:30 Alex Deucher wrote:
> On Mon, May 3, 2010 at 2:09 PM, Brian Paul 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. I don't thi
-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
> Date: Sat May 1 15
2010/4/28 Brian Paul :
> Kristian Høgsberg wrote:
>>
>> 2010/4/27 Kristian Høgsberg :
>> [ I hit send to early there... ]
>>>
>>> review the patches, or at least just some of them. The overall
>>> approach is
>>
>> 1. Add a API tag to GLcontext so we key off of that.
>> 2. Use API-aware construc
On Mon, May 3, 2010 at 2:09 PM, Brian Paul wrote:
>
> Well, never let it be said that I'm inflexible. I'm conceding on the
> dev model debate. It's more important to have happy developers
> contributing to produce stable drivers than to debate the merits of
> dev model A vs. B. For me, cherry p
Well, never let it be said that I'm inflexible. I'm conceding on the
dev model debate. It's more important to have happy developers
contributing to produce stable drivers than to debate the merits of
dev model A vs. B. For me, cherry picking will be more work than
merging, but again, that's no
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
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
> > > s
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 names.
I was recently burned by the Gallium docs omitting the prefix
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
> b/src/g
Dave Airlie wrote:
On Sat, May 1, 2010 at 6:47 PM, 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 su
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
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
--- a/s
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 enhancmen
On 2010-05-03 19:37, José Fonseca wrote:
> On Mon, 2010-05-03 at 09:20 -0700, Török Edwin wrote:
>> Do the shaders need strict IEEE 754 math?
>
> I doubt. We already use -ffast-math in when compiling mesa.
>
> -ffast-math tipically optimizes by leaving intermediate values in the
> x86 FP stack w
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, regardless
On Mon, 2010-05-03 at 09:20 -0700, Török Edwin wrote:
> 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
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 go
Jakob Bornecrantz 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. What that means i
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 through them we should have more data.
Also, do you k
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
>> 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
>>> t
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 patch
On Mon, May 3, 2010 at 3:52 AM, 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
> -Wl,--start-group -lXext -
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. pret
This fixes flightgear assertion in dxt stubs :
Mesa warning: external dxt library not available: texstore_rgba_dxt3
util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0'
failed.
Only advertise for BIND_SAMPLER_VIEW to avoid very weird paths, according to
José Fonseca.
---
src/ga
On Mon, May 3, 2010 at 7:39 AM, Colin Harrison
wrote:
> Hi,
>
> I needed to apply the following patch now that drisw state tracker uses the
> new API aware context create...
Thanks, fixed.
Kristian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.o
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák wrote:
> On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
> wrote:
>>
>> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
>> Compiz shows dark screen.
>> (Using nouveau drivers)
>>
>> Without this commit compiz works almost perfect
Hi,
I needed to apply the following patch now that drisw state tracker uses the
new API aware context create...
--- ./src/mesa/drivers/dri/swrast/save_swrast.c 2010-05-02
20:45:28.0 +0100
+++ ./src/mesa/drivers/dri/swrast/swrast.c 2010-05-03
11:27:40.0 +0100
@@ -501,7 +501,7
Also, does r300 advertise rendertarget support for compressed textures?
It probably does, and that's why you end up in this surface_copy path.
Jose
On Mon, 2010-05-03 at 04:47 -0700, José Fonseca wrote:
> As long as the blit engine is not lossy, you could support everything by
> using PIPE_FORM
As long as the blit engine is not lossy, you could support everything by
using PIPE_FORMAT_I8_UNORM or something and adjusting dimensions.
Jose
On Sun, 2010-05-02 at 12:02 -0700, Marek Olšák wrote:
> Module: Mesa
> Branch: master
> Commit: 3b2cf97c5c84c3a92f97f335b27f754aa42c5259
> URL:
> htt
On Mon, May 3, 2010 at 12:52 PM, 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
> -Wl,--start-group -lXext
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
-lx
51 matches
Mail list logo
