Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification

On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri wrote: > Currently the nv30 and nv40 Gallium drivers are very similar, and > contain about 5000 lines of essentially duplicate code. > > I prepared a patchset (which can be found at > http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unificatio

[Mesa3d-dev] [PATCH] Correct GL_EQUIV code in r67/7xx.

From 247e121106e8d3e389f2e5a6edf13ea70ac18df7 Mon Sep 17 00:00:00 2001 These seem to be documented in . --- src/mesa/drivers/dri/r600/r700_state.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff -

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Sapountzis wrote: > Hi, > > I put some patches at > http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do > the plumbing in order to build the swrast_dri wrapper around gallium > instead of classic mesa. For reference, swrast_dri

Re: [Mesa3d-dev] master: undef/unmangled EGL functions are part of libOSMesa

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tom fogal wrote: >>From a build of master (41eab95b3bc29a4fe6fd08b7f1f80cef5bdc097f) [1]: > > $ lib nm libOSMesa.so | grep "EGL" > 00064254 t _mesa_EGLImageTargetRenderbufferStorageOES > 000b30c0 t _mesa_EGLImageTargetTexture2DO

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

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 ../common/utils.o swrast.o swrast_sp >> an.o >>  ../..

[Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration

It was a long while back that I wondered && somehow ended up volunteering to detect platform TLS support, + enable it in Mesa / the X server if available. I got distracted before finishing the X parts, but rebased the Mesa parts, which are attached. One thing I'm worried about is using an AC macr

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

Xavier Chantry writes: > On Mon, Mar 15, 2010 at 12:41 AM, tom fogal wrote: > > > > You can emulate the [undefined link errors] by building with > > -Wl,--no-undefined (or maybe -no-undefined, something like that, > > see ld(1)). > > With -Wl,--no-undefined, I get so many errors that it did not f

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

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

Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification

Dear Luca, I got your latest commits for your branch,did a make clean instead of make -B realclean as I usaully do and did an autoreconf -iv,then .autogen.sh with my configure options I mentioned earlier to ths thread.I then ran make and make install instead of gmake and gmake insta

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

Xavier Chantry writes: > 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 l > oad > 14:47 < lb1> because it cannot resolve that symbol > 14:48 < lb1> not sure why > 14:48 < lb1> I suppose even fo

Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification

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

Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification

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_resources conversion for the nv drivers. Once I do that, there will be heap

[Mesa3d-dev] undefined symbols and silent fallback to swrast

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

[Mesa3d-dev] master: undef/unmangled EGL functions are part of libOSMesa

>From a build of master (41eab95b3bc29a4fe6fd08b7f1f80cef5bdc097f) [1]: $ lib nm libOSMesa.so | grep "EGL" 00064254 t _mesa_EGLImageTargetRenderbufferStorageOES 000b30c0 t _mesa_EGLImageTargetTexture2DOES U glEGLImageTargetRenderbufferStorageOES

Re: [Mesa3d-dev] Compiler warnings when building Mesa

>From: Johannes Obermayr >To: mesa3d-dev >Sent: Sun, March 14, 2010 1:30:27 PM >Subject: [Mesa3d-dev] Compiler warnings when building Mesa > >Hi, > >here is a list with compiler warnings I have seen for a longer time. > >Just for info: >libdrm: 20100313 >XServer: 1.7.5 >protos/macros: 20100311

Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification

Perhaps try running make clean and make if you haven't already? And perhaps make sure that the installed libGL.so and DRI drivers are build from the same codebase. The changes in my branch definitely shouldn't affect this. > I wanted to merge Lucsa' branch in to my copy of Mesa master to test it

[Mesa3d-dev] Compiler warnings when building Mesa

Hi, here is a list with compiler warnings I have seen for a longer time. Just for info: libdrm: 20100313 XServer: 1.7.5 protos/macros: 20100311 I can also provide a full log (~1.4 MiB). Please decide whether fixing them is necessary/worth ... Thanks. Johannes gcc -c -I../../include -I../../sr

Re: [Mesa3d-dev] i965 shader regression [bisected]

On Sat, 2010-03-13 at 16:52 +0200, Maxim Levitsky wrote: > This time I caught it early. > > 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a is first bad commit > commit 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a > Author: Eric Anholt > Date: Wed Mar 10 17:38:33 2010 -0800 > > i965: Do FS SLT, SGT,

[Mesa3d-dev] [Bug 27065] build failure: No rule to make target `../../../../src/gallium/drivers/softpipe/sp_winsys.h', needed by `x11/native_ximage.o'.

http://bugs.freedesktop.org/show_bug.cgi?id=27065 --- Comment #2 from David Ronis 2010-03-14 09:50:58 PST --- Actually, I had run make clean and that didn't help; however, explicitly removing the depend file as you suggested seems to have worked. Thanks -- Configure bugmail: http://bugs

Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification

Hi guys, I came across this post and downloaded luca's version of Mesa (mesa-lb) using: git clone git://repo.or.cz/mesa/mesa-lb.git and then git checkout --track -b unification+fixes+stable origin/unification+fixes+stable and switched to that branch. I then for safety,I compiled and ins

Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.

On Sun, Mar 14, 2010 at 10:28 AM, Chia-I Wu wrote: > On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell > wrote: >> This looks like it introduces an extra full-window copying operation >> at every swapbuffers...  is that correct? >> If so, I think we should try to figure out an alternative approach

Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.

On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell wrote: > This looks like it introduces an extra full-window copying operation > at every swapbuffers...  is that correct? > If so, I think we should try to figure out an alternative approach > without the copying...  would actually flipping between t

[Mesa3d-dev] plumbing for gallium swrast_dri.so

Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It

Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.

Chia-I, This looks like it introduces an extra full-window copying operation at every swapbuffers... is that correct? If so, I think we should try to figure out an alternative approach without the copying... would actually flipping between two textures (thus preserving the old back/new front) c

Re: [Mesa3d-dev] Galuim3d alteration idea. Cache and common storage for glsl to native gpu conversions .

On Sat, Mar 13, 2010 at 3:13 AM, Peter Dolding wrote: > http://ccache.samba.org/ is where part of this idea comes from. > > > Speeding up glsl conversion to gpu code will make things more effective. > There is no point running the glsl to native gpu conversions more times than > that are require p