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
.
On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry
wrote:
> flightgear now dies with :
> 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.
>
> I don't really understa
lem with glx-multithread and pthread though (fixed by
0001), not with fp-rfl and sqrt/libm .
From 113d7e7d634c067c3f9865c15d272290aab019db Mon Sep 17 00:00:00 2001
From: Xavier Chantry
Date: Fri, 26 Mar 2010 19:04:01 +0100
Subject: [PATCH 1/2] glx-multithread needs -lpthread
Add pthread to link glx
On Thu, Mar 25, 2010 at 8:32 PM, Jakob Bornecrantz wrote:
>
> Thanks again for testing.
>
> Okay, this could be solved by just checking if the state trackers are
> built where we enable the the targets instead of the subsystem or
> driver. The xorg drivers is the only one doing this correctly, by
On Fri, Mar 26, 2010 at 2:51 AM, STEVE555 wrote:
>
> Hi guys,
> I've pulled in the latest commits from Mesa git at about 1am
> this morning.
> I ran gmake -B realclean,and then used autoreconf -iv and ./autogen.sh with
> my configure options,i.e:
>
> ./autogen.sh --prefix=/usr --enable-
On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz wrote:
>
> Thanks for testing...
>
> Hmm I currently only checking for if the --enable-egl switch has been
> thrown when selecting so if you throw in --disable-egl in there it
> should work again. I'll look into it.
>
Interestingly enough, the dr
I've been using the configure line from nouveau wiki for a while now :
http://nouveau.freedesktop.org/wiki/GalliumHowto
./configure --enable-debug --enable-glx-tls --disable-asm
--with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel
--disable-gallium-radeon --disable-gallium-svga
--w
ild drm/sw
>>
>> If I actually broke this as well, admittedly I should have stayed away
>> from the computer today
>>
>>
>> On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry
>> wrote:
>>> scons dri=no drivers=softpipe or llvmpipe
>>>
scons dri=no drivers=softpipe or llvmpipe
glxgears: symbol lookup error:
/home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined
symbol: gallium_soft_create_screen
Works after these two reverts :
Revert "gallium: add soft screen helper"
This reverts commit f87a5f6499f51f651c2a9
ect rendering
libGL error: dlopen foo/swrast_dri.so failed (foo/swrast_dri.so: cannot open
shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
Signed-off-by: Xavier Chantry
---
src/glx/dri2_glx.c |2 +-
s just resulted in segfault at runtime, and I had to make clean and
do a full build again. This was simply because I did not have makedepend
installed, and parts of the tree were not rebuilt when they should.
Signed-off-by: Xavier Chantry
---
configure.ac |5 -
1 files changed, 4 i
On Fri, Mar 19, 2010 at 10:39 PM, Dan Nicholson wrote:
> On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri wrote:
>>> Can we just put this program in the demos? Or at least just make it a
>>> separate target (make test-link)? It seems excessive to make this part
>>> of the default build path.
>>
>>
On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson wrote:
>
>> diff --git a/configure.ac b/configure.ac
>> index 485836a..a582337 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -28,8 +28,11 @@ AC_PROG_CPP
>> AC_PROG_CC
>> AC_PROG_CXX
>> AC_CHECK_PROGS([MAKE], [gmake make])
>> -AC_PATH_PRO
On Wed, Mar 17, 2010 at 1:01 AM, Jose Fonseca wrote:
> Indeed, this problems happen with Windows q3arena demo only. Ioquake3, and I
> believe that the latest windows full quake3 binary too, correctly handles the
> full extensions list.
>
> However I suspect that quake2 and earliy releases of qua
On Tue, Mar 16, 2010 at 4:32 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jose Fonseca wrote:
>> Module: Mesa
>> Branch: mesa_7_7_branch
>> Commit: 93e77b0028170fafd176c3a80a99287343c946b4
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=93e77b002817
On Tue, Mar 16, 2010 at 7:13 PM, Roland Scheidegger wrote:
> On 16.03.2010 18:52, Keith Whitwell wrote:
>> On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote:
>>
>>> I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array
>>> has any impact on our Quake3 performance. After all
n the build process.
>
> All classic DRI drivers as well as all the Gallium drivers with configure
> options compiled successfully with this change.
>
> Thanks to Xavier Chantry and
> Michel Daenzer for helping with this.
> ---
Just tested, that also works for me.
---
On Mon, Mar 15, 2010 at 2:30 PM, Luca Barbieri wrote:
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
>
Oh great, that works for me too !
--
Download Intel®
2010/3/15 Michel Dänzer :
>
> One problem is that drivers can be loaded from several paths; if the HW
> driver fails to load from the first path but succeeds from the next one,
> any error messages from the first attempt would be confusing.
>
If it fails to load because it does not exist ? Or beca
On Mon, Mar 15, 2010 at 1:18 AM, tom fogal wrote:
> Xavier Chantry writes:
>> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
>> 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
>> ../../common/driverfuncs.o ../
On Mon, Mar 15, 2010 at 12:41 AM, tom fogal wrote:
>
> That's just the default compiler/linker setup on Linux. This is in
> contrast to, say, OS X, where undefined symbols cause link errors.
>
> You can emulate the above by building with -Wl,--no-undefined (or maybe
> -no-undefined, something lik
On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell
wrote:
> On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell
> wrote:
>> Sounds good to me - fewer driver directories to fix up after changes...
>>
>
> It'd be good to get this merged sooner rather than later as I'll soon
> be starting on pipe_resource
14:47 < lb1> the fact is that if you remove a function from mesa .c file,
everything will succeed, but the resulting driver will fail to load
14:47 < lb1> because it cannot resolve that symbol
14:48 < lb1> not sure why
14:48 < lb1> I suppose even for shared libraries gcc/ld should fail
Signed-off-by: Xavier Chantry
---
src/gallium/drivers/nv50/nv50_screen.c |1 -
src/gallium/drivers/nv50/nv50_screen.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_screen.c
b/src/gallium/drivers/nv50/nv50_screen.c
index 7e2e8aa
On Tue, Feb 23, 2010 at 11:14 PM, Dan Nicholson wrote:
>
> We could use gcc directly for depends (I have a patch to do it), but:
>
> 1. I don't think it would actually help much in terms of rebuilds
> since makedepend seems to do a perfectly adequate job of finding the
> needed headers.
>
> 2. gcc
On Thu, Feb 25, 2010 at 6:12 PM, José Fonseca wrote:
>
> Thanks. Commited, with just a change: I still allow drivers=trace to
> avoid breaking all build infrastructure that's already using that
> option. I'll eventually remove the option once I've updated everywhere
> not to use it.
>
I did wonde
While keeping up-to-date the nouveau mesa driver (either classic or
gallium), or doing regression testing, the big majority of my rebuilds
resulted in segfaults.
I am not talking about autogen or configure detection. I believe this
also works automatically in other projects and doesn't with mesa, b
cell.
>> Should trace be replaced by cell in the above check ?
>
> Yes, I think so.
>
Also changed in attached patch.
From 1ee8d9963da8a5e78e8f0acb84dc6bea7a364e4e Mon Sep 17 00:00:00 2001
From: Xavier Chantry
Date: Tue, 23 Feb 2010 22:05:15 +0100
Subject: [PATCH] scons: always build trace driv
Since commit c6509f89 , scons dri=no drivers=softpipe (or llvmpipe) no
longer works.
It does show a warning at the beginning :
warning: trace pipe driver disabled: skipping build of xlib libGL.so
But it does not stop there, instead it goes on and build almost
everything, It's hard to see and not v
On Sat, Feb 20, 2010 at 5:22 PM, Brian Paul wrote:
> On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry
> wrote:
>> It seems the commit below will always report an user error when
>> glxinfo -l is called.
>> And indeed I always get the following :
>> $ glxinfo -l
>
It seems the commit below will always report an user error when
glxinfo -l is called.
And indeed I always get the following :
$ glxinfo -l
...
GL_VERTEX_PROGRAM_ARB:
...
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
M
On Thu, Feb 18, 2010 at 11:36 PM, Mike Lothian wrote:
> I'm experiencing 3 issues at the moment
>
> xorg-server master isn't compiling I get the error:
>
> ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus
> -I../hw/
On Tue, Feb 2, 2010 at 12:01 PM, Francisco Jerez wrote:
> For a long time the gallium pipe drivers for nvidia fixed function cards
> (nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and
> godforsaken -- especially nv0x and nv1x had seen almost no progress
> since their creation.
>
On Thu, Jan 28, 2010 at 9:21 PM, Brian Paul wrote:
>
> This patch series fixes some bugs in VBO state validation for variations of
> glDrawElements(). I've tested and haven't found any regressions but since
> these are non-trivial changes, I'm putting them up for review. I'll commit
> later if t
On Mon, Jan 25, 2010 at 2:20 AM, Brian Paul wrote:
>>
>> What exactly is the issue with teeworlds? I haven't seen a bug report.
>>
Searching for noclip in teeworlds forums show at least five reports of
a similar issue. For example :
http://www.teeworlds.com/forum/viewtopic.php?id=4174
Everytime
On Mon, Jan 25, 2010 at 12:56 AM, Brian Paul wrote:
> On Sat, Jan 23, 2010 at 9:27 AM, Xavier Chantry
> wrote:
>> commit 53174afeeb introduced a portability change that converted GLint x,y
>> to GLuint. That breaks when x and y are negative, which seems to be allowed,
>>
so that comparisons are made between signed integers
instead. This hopefully does not break anything while keeping MSVC happy.
Signed-off-by: Xavier Chantry
---
My knowledge of mesa and opengl is close to 0 and C one is limited so this
could be all wrong.
If this is not the proper fix, just
37 matches
Mail list logo