Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, 2009-02-13 at 06:41 -0800, Dan Nicholson wrote: On Fri, Feb 13, 2009 at 02:12:25PM +, José Fonseca wrote: On Fri, 2009-02-13 at 06:05 -0800, Jakob Bornecrantz wrote: On 13 feb 2009, at 15.00, José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Autoconf/configure completely overwrites any settings in configs/ default. Cheers Jakob. Maciej I haven't tested, but this should do the trick if you're using autoconf: diff --git a/configure.ac b/configure.ac index a9a8d5a..a523f76 100644 --- a/configure.ac +++ b/configure.ac @@ -474,6 +474,7 @@ yes) if test $mesa_driver != osmesa; then PROGRAM_DIRS=xdemos fi +SRC_DIRS=$SRC_DIRS glew ;; *) # verify the requested demos directories exist @@ -483,6 +484,7 @@ yes) AC_MSG_ERROR([Program directory '$demo' doesn't exist]) done PROGRAM_DIRS=$demos +SRC_DIRS=$SRC_DIRS glew ;; esac Since GLEW is only needed with the GLUT demos, wouldn't this be better? diff --git a/configure.ac b/configure.ac index 549ca90..36b5859 100644 --- a/configure.ac +++ b/configure.ac @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx +SRC_DIRS=$SRC_DIRS glut/glx glew GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions Dan, Although only GLUT examples depend on GLEW atm, GLEW itselfg does not depend on GLUT, and we might want to use GLEW in non GLUT examples (eg., the GLX examples) Jose -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, Feb 16, 2009 at 8:59 AM, José Fonseca jfons...@vmware.com wrote: On Fri, 2009-02-13 at 06:41 -0800, Dan Nicholson wrote: On Fri, Feb 13, 2009 at 02:12:25PM +, José Fonseca wrote: On Fri, 2009-02-13 at 06:05 -0800, Jakob Bornecrantz wrote: On 13 feb 2009, at 15.00, José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Autoconf/configure completely overwrites any settings in configs/ default. Cheers Jakob. Maciej I haven't tested, but this should do the trick if you're using autoconf: diff --git a/configure.ac b/configure.ac index a9a8d5a..a523f76 100644 --- a/configure.ac +++ b/configure.ac @@ -474,6 +474,7 @@ yes) if test $mesa_driver != osmesa; then PROGRAM_DIRS=xdemos fi +SRC_DIRS=$SRC_DIRS glew ;; *) # verify the requested demos directories exist @@ -483,6 +484,7 @@ yes) AC_MSG_ERROR([Program directory '$demo' doesn't exist]) done PROGRAM_DIRS=$demos +SRC_DIRS=$SRC_DIRS glew ;; esac Since GLEW is only needed with the GLUT demos, wouldn't this be better? diff --git a/configure.ac b/configure.ac index 549ca90..36b5859 100644 --- a/configure.ac +++ b/configure.ac @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx +SRC_DIRS=$SRC_DIRS glut/glx glew GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions Dan, Although only GLUT examples depend on GLEW atm, GLEW itselfg does not depend on GLUT, and we might want to use GLEW in non GLUT examples (eg., the GLX examples) Yeah, after I went and looked at what glew actually was, it became apparent that this wasn't quite right. Right now, I think the right way to handle it is like glut/glu/glw. --disable-glew if you want that, then the demos that need glew will be disabled. The only thing that really stopped me from doing that is that glew isn't an installed library. So, it didn't seem to make sense to say enable/disable this internal static library. Maybe it should just always be on right now, which is easy. See patch below. -- Dan diff --git a/configure.ac b/configure.ac index 36b5859..2d48ccf 100644 --- a/configure.ac +++ b/configure.ac @@ -409,7 +409,7 @@ esac dnl dnl Driver specific build directories dnl -SRC_DIRS=mesa egl +SRC_DIRS=mesa egl glew GLU_DIRS=sgi WINDOW_SYSTEM= GALLIUM_DIRS=auxiliary drivers state_trackers @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx glew +SRC_DIRS=$SRC_DIRS glut/glx GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, 2009-02-16 at 09:17 -0800, Dan Nicholson wrote: On Mon, Feb 16, 2009 at 8:59 AM, José Fonseca jfons...@vmware.com wrote: On Fri, 2009-02-13 at 06:41 -0800, Dan Nicholson wrote: On Fri, Feb 13, 2009 at 02:12:25PM +, José Fonseca wrote: On Fri, 2009-02-13 at 06:05 -0800, Jakob Bornecrantz wrote: On 13 feb 2009, at 15.00, José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Autoconf/configure completely overwrites any settings in configs/ default. Cheers Jakob. Maciej I haven't tested, but this should do the trick if you're using autoconf: diff --git a/configure.ac b/configure.ac index a9a8d5a..a523f76 100644 --- a/configure.ac +++ b/configure.ac @@ -474,6 +474,7 @@ yes) if test $mesa_driver != osmesa; then PROGRAM_DIRS=xdemos fi +SRC_DIRS=$SRC_DIRS glew ;; *) # verify the requested demos directories exist @@ -483,6 +484,7 @@ yes) AC_MSG_ERROR([Program directory '$demo' doesn't exist]) done PROGRAM_DIRS=$demos +SRC_DIRS=$SRC_DIRS glew ;; esac Since GLEW is only needed with the GLUT demos, wouldn't this be better? diff --git a/configure.ac b/configure.ac index 549ca90..36b5859 100644 --- a/configure.ac +++ b/configure.ac @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx +SRC_DIRS=$SRC_DIRS glut/glx glew GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions Dan, Although only GLUT examples depend on GLEW atm, GLEW itselfg does not depend on GLUT, and we might want to use GLEW in non GLUT examples (eg., the GLX examples) Yeah, after I went and looked at what glew actually was, it became apparent that this wasn't quite right. Right now, I think the right way to handle it is like glut/glu/glw. --disable-glew if you want that, then the demos that need glew will be disabled. The only thing that really stopped me from doing that is that glew isn't an installed library. So, it didn't seem to make sense to say enable/disable this internal static library. Maybe it should just always be on right now, which is easy. See patch below. -- Dan diff --git a/configure.ac b/configure.ac index 36b5859..2d48ccf 100644 --- a/configure.ac +++ b/configure.ac @@ -409,7 +409,7 @@ esac dnl dnl Driver specific build directories dnl -SRC_DIRS=mesa egl +SRC_DIRS=mesa egl glew GLU_DIRS=sgi WINDOW_SYSTEM= GALLIUM_DIRS=auxiliary drivers state_trackers @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx glew +SRC_DIRS=$SRC_DIRS glut/glx GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions Yep -- this is fine. Jose -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, 2009-02-13 at 18:43 -0800, Dave Airlie wrote: Gallium3D currently builds on Linux userland (gcc), Windows user-space (MSVC, MinGW, and MinGW cross-compilers) and Windows kernel-space (MSVC only unfortunately). Mesa3D/Gallium3D scons build system supports all those combinations, *today*. Jose it supports building, I think Donnie's point is that its impossible to package something that uses scons, so makes it useless to people who downstream consume Mesa instead of developers doing builds. Dave, It is not impossible to package something that uses scons. Several packages in debian use it: $ grep Build-Depends: .*\scons\ /var/lib/apt/lists/*_Sources | wc -l 82 Concerning CFLAGS etc, one can easily modify scons to listen to it. E.g: env.Append(CFLAGS = os.environ['CFLAGS'] We can add this to mesa/gallium if it makes packager's lives easier. Scons also accepts options via command line and SCONSFLAGS. I won't even comment on KDE developers statement that Donnie quoted: it was done almost 3 years ago, and with a completely different set of requirements. I played with cmake on gallium, and it was useless. I think that all this anti-scons stuff is just FUD. Anyway, I won't push scons as the build system to rule them all, as it is pretty unrealistic. Everybody prefers what they know best, and don't want the productivity downer of learning a new tool. It is understandable, and that's why make will remain for the years to come. I'd be glad if just more linux developers gave gallium scons build system a honest try and helped me support it on linux, besides just a couple of us in vmware. It supports: - out of tree builds (build linux x86, linux x86-64, windows, etc, from a single source tree) - worry-free implicit dependency scanning - cross platform (*truly*, and not just relying on cygwin, msys, etc to provide a fake unix environment on windows) - builtin ccache-like functionality (on all platforms) - files are rebuilt based on md5sums, not their time stamps (pretty neat when one temporarily git-checkouts something else) - autoconf like functionality (although I barely scratched the surface on this) - automatic parallel builds on multicore systems - ... Jose -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Also I get many linker warnings when building progs/demos: /usr/bin/ld: Warning: size of symbol `glutBitmapTimesRoman10' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica10' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica12' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica18' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so Maciej -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Also I get many linker warnings when building progs/demos: /usr/bin/ld: Warning: size of symbol `glutBitmapTimesRoman10' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica10' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica12' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica18' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so This should have been fixed with my commit 5ef5162103168bff2d68670a715d5afdee82e9e9. Please pull a fresh checkout and try again. Jose -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, 2009-02-13 at 06:05 -0800, Jakob Bornecrantz wrote: On 13 feb 2009, at 15.00, José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Autoconf/configure completely overwrites any settings in configs/ default. Cheers Jakob. Maciej I haven't tested, but this should do the trick if you're using autoconf: diff --git a/configure.ac b/configure.ac index a9a8d5a..a523f76 100644 --- a/configure.ac +++ b/configure.ac @@ -474,6 +474,7 @@ yes) if test $mesa_driver != osmesa; then PROGRAM_DIRS=xdemos fi +SRC_DIRS=$SRC_DIRS glew ;; *) # verify the requested demos directories exist @@ -483,6 +484,7 @@ yes) AC_MSG_ERROR([Program directory '$demo' doesn't exist]) done PROGRAM_DIRS=$demos +SRC_DIRS=$SRC_DIRS glew ;; esac Jose -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On piątek, 13 lutego 2009 15:00:25 José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Also I get many linker warnings when building progs/demos: /usr/bin/ld: Warning: size of symbol `glutBitmapTimesRoman10' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica10' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica12' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so /usr/bin/ld: Warning: size of symbol `glutBitmapHelvetica18' changed from 4 in /tmp/cc8CTNmD.o to 16 in ../../lib/libglut.so This should have been fixed with my commit 5ef5162103168bff2d68670a715d5afdee82e9e9. Please pull a fresh checkout and try again. Jose Sorry for the noise. I was trying to build radeon-rewrite branch. It works great on master. Maciej -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, Feb 13, 2009 at 02:12:25PM +, José Fonseca wrote: On Fri, 2009-02-13 at 06:05 -0800, Jakob Bornecrantz wrote: On 13 feb 2009, at 15.00, José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Autoconf/configure completely overwrites any settings in configs/ default. Cheers Jakob. Maciej I haven't tested, but this should do the trick if you're using autoconf: diff --git a/configure.ac b/configure.ac index a9a8d5a..a523f76 100644 --- a/configure.ac +++ b/configure.ac @@ -474,6 +474,7 @@ yes) if test $mesa_driver != osmesa; then PROGRAM_DIRS=xdemos fi +SRC_DIRS=$SRC_DIRS glew ;; *) # verify the requested demos directories exist @@ -483,6 +484,7 @@ yes) AC_MSG_ERROR([Program directory '$demo' doesn't exist]) done PROGRAM_DIRS=$demos +SRC_DIRS=$SRC_DIRS glew ;; esac Since GLEW is only needed with the GLUT demos, wouldn't this be better? diff --git a/configure.ac b/configure.ac index 549ca90..36b5859 100644 --- a/configure.ac +++ b/configure.ac @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx +SRC_DIRS=$SRC_DIRS glut/glx glew GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions -- 1.5.6.6 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On piątek, 13 lutego 2009 15:41:49 Dan Nicholson wrote: On Fri, Feb 13, 2009 at 02:12:25PM +, José Fonseca wrote: On Fri, 2009-02-13 at 06:05 -0800, Jakob Bornecrantz wrote: On 13 feb 2009, at 15.00, José Fonseca wrote: On Fri, 2009-02-13 at 05:44 -0800, Maciej Cencora wrote: On środa, 11 lutego 2009 00:47:52 Brian Paul wrote: OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian The GLEW library isn't build so all progs/demos builds fail. One have to manually enter the src/glew directory and type make to make it build. Which configuration are you using? GLEW is enabled on all configurations for which GLUT is also enabled. Autoconf/configure completely overwrites any settings in configs/ default. Cheers Jakob. Maciej I haven't tested, but this should do the trick if you're using autoconf: diff --git a/configure.ac b/configure.ac index a9a8d5a..a523f76 100644 --- a/configure.ac +++ b/configure.ac @@ -474,6 +474,7 @@ yes) if test $mesa_driver != osmesa; then PROGRAM_DIRS=xdemos fi +SRC_DIRS=$SRC_DIRS glew ;; *) # verify the requested demos directories exist @@ -483,6 +484,7 @@ yes) AC_MSG_ERROR([Program directory '$demo' doesn't exist]) done PROGRAM_DIRS=$demos +SRC_DIRS=$SRC_DIRS glew ;; esac Since GLEW is only needed with the GLUT demos, wouldn't this be better? diff --git a/configure.ac b/configure.ac index 549ca90..36b5859 100644 --- a/configure.ac +++ b/configure.ac @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx +SRC_DIRS=$SRC_DIRS glut/glx glew GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions Actually demos don't build without your patches. I run make clean but it doesn't remove most of lib/ files so the progs/demos build succeed at first. What's the deal with all those build systems? Can't we agree on one and drop the rest? Maciej -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, Feb 13, 2009 at 7:04 AM, Maciej Cencora m.cenc...@gmail.com wrote: On piątek, 13 lutego 2009 15:41:49 Dan Nicholson wrote: Since GLEW is only needed with the GLUT demos, wouldn't this be better? diff --git a/configure.ac b/configure.ac index 549ca90..36b5859 100644 --- a/configure.ac +++ b/configure.ac @@ -1006,7 +1006,7 @@ if test x$enable_glut = xyes test $mesa_driver = osmesa; then fi if test x$enable_glut = xyes; then -SRC_DIRS=$SRC_DIRS glut/glx +SRC_DIRS=$SRC_DIRS glut/glx glew GLUT_CFLAGS= if test x$GCC = xyes; then GLUT_CFLAGS=-fexceptions Actually demos don't build without your patches. I run make clean but it doesn't remove most of lib/ files so the progs/demos build succeed at first. Yes, that was the reason for the patch. -- Dan -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Maciej Cencora wrote: Actually demos don't build without your patches. I run make clean but it doesn't remove most of lib/ files so the progs/demos build succeed at first. Can you check that Mesa master/head is OK now? What's the deal with all those build systems? Can't we agree on one and drop the rest? We'll probably get there one day. I'm still pretty attached to the old static config file system. I've never been much of a fan of autoconf (for reasons I've listed in the past). Jose's been maintaining scons but I haven't used it too much myself yet. Scons seems simpler/nicer than autoconf and works on more platforms (Windows in particular) so that'd probably be my choice if there were a gun to my head... -Brian -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, Feb 13, 2009 at 8:35 AM, Maciej Cencora m.cenc...@gmail.com wrote: Head is OK now. What about make clean? Shouldn't it delete all files from lib/ directory? It never has before. You can run 'make realclean' if you want to obliterate everything. -- Dan -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On 08:58 Fri 13 Feb , Brian Paul wrote: Maciej Cencora wrote: What's the deal with all those build systems? Can't we agree on one and drop the rest? We'll probably get there one day. I'm still pretty attached to the old static config file system. I've never been much of a fan of autoconf (for reasons I've listed in the past). Jose's been maintaining scons but I haven't used it too much myself yet. Scons seems simpler/nicer than autoconf and works on more platforms (Windows in particular) so that'd probably be my choice if there were a gun to my head... This whole post is about why scons shouldn't become the only build system, so if you don't care about that, you can stop reading now. Scons has a lot of problems from a packager's point of view. For one, it ignores environment variables so PATH, CFLAGS, LDFLAGS, CC, and so on are ignored. It's most convenient for packagers to simply run a script and set up the environment, rather than having to edit or patch files, which is unreliable and can be tricky. KDE decided not to go with SCons because of lack of upstream support, difficulty of configuration, problems with OS X, etc: The KDE individuals who tried to bring SCons into a shape that made it fit for building such a huge project felt they didn't have any support from the upstream SCons developers. There were major problems building KDE on non-Linux platforms with SCons (e.g. on OS X); in general they felt it did not yet have a mature configuration system. The only option down that road was to create major SCons fixes and patches on their own. Since these changes would not likely be included in the upstream sources, it would require permanent maintenance of the fixes in a separate repository. In effect, this would have amounted to a fork of SCons. KDE developers would have had to maintain the new build system entirely on their own. -- http://lwn.net/Articles/188693/ My understanding is that MinGW runs nicely on Windows systems and will deal with autotools just fine. Is the requirement to build using the Microsoft compilers rather than to build and run on Windows? If so, that seems pretty odd and has little relationship to what the goals should be. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpopI0t66mVX.pgp Description: PGP signature -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, Feb 13, 2009 at 9:57 AM, Donnie Berkholz dberkh...@gentoo.org wrote: My understanding is that MinGW runs nicely on Windows systems and will deal with autotools just fine. Is the requirement to build using the Microsoft compilers rather than to build and run on Windows? If so, that seems pretty odd and has little relationship to what the goals should be. Of course, that statement doesn't quite hold for mesa since it only uses autoconf. In fact, it's libtool that does most of heavy lifting that makes building with mingw/darwin easy. Just to be clear. -- Dan -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Fri, 2009-02-13 at 09:57 -0800, Donnie Berkholz wrote: On 08:58 Fri 13 Feb , Brian Paul wrote: Maciej Cencora wrote: What's the deal with all those build systems? Can't we agree on one and drop the rest? We'll probably get there one day. I'm still pretty attached to the old static config file system. I've never been much of a fan of autoconf (for reasons I've listed in the past). Jose's been maintaining scons but I haven't used it too much myself yet. Scons seems simpler/nicer than autoconf and works on more platforms (Windows in particular) so that'd probably be my choice if there were a gun to my head... This whole post is about why scons shouldn't become the only build system, so if you don't care about that, you can stop reading now. Scons has a lot of problems from a packager's point of view. For one, it ignores environment variables so PATH, CFLAGS, LDFLAGS, CC, and so on are ignored. It's most convenient for packagers to simply run a script and set up the environment, rather than having to edit or patch files, which is unreliable and can be tricky. KDE decided not to go with SCons because of lack of upstream support, difficulty of configuration, problems with OS X, etc: The KDE individuals who tried to bring SCons into a shape that made it fit for building such a huge project felt they didn't have any support from the upstream SCons developers. There were major problems building KDE on non-Linux platforms with SCons (e.g. on OS X); in general they felt it did not yet have a mature configuration system. The only option down that road was to create major SCons fixes and patches on their own. Since these changes would not likely be included in the upstream sources, it would require permanent maintenance of the fixes in a separate repository. In effect, this would have amounted to a fork of SCons. KDE developers would have had to maintain the new build system entirely on their own. -- http://lwn.net/Articles/188693/ My understanding is that MinGW runs nicely on Windows systems and will deal with autotools just fine. Is the requirement to build using the Microsoft compilers rather than to build and run on Windows? If so, that seems pretty odd and has little relationship to what the goals should be. Gallium3D currently builds on Linux userland (gcc), Windows user-space (MSVC, MinGW, and MinGW cross-compilers) and Windows kernel-space (MSVC only unfortunately). Mesa3D/Gallium3D scons build system supports all those combinations, *today*. Jose -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Gallium3D currently builds on Linux userland (gcc), Windows user-space (MSVC, MinGW, and MinGW cross-compilers) and Windows kernel-space (MSVC only unfortunately). Mesa3D/Gallium3D scons build system supports all those combinations, *today*. Jose it supports building, I think Donnie's point is that its impossible to package something that uses scons, so makes it useless to people who downstream consume Mesa instead of developers doing builds. Dave. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
2009/2/10 Anders Juel Jensen andersjjen...@gmail.com: PS.: Oh, http://wiki.x.org/wiki/Development/git just became obsolete. Can someone knowledgable also give quick instructions on how to actually run gallium there? I can update the page (and others), as soon as I know... ...what would be supposed to be created when compiling the gallium drivers? I'm sure there are plenty of people jumping in to testing now that gallium was merged to master, but compiling the current master does not seem to generate eg. the i965_simple driver under lib/. Used ./configure --with-dri-drivers= to not create old DRI ones, which among else gives the line Driver dirs: softpipe failover trace i915simple i965simple. But: $ ls -R (under mesa/lib/ after compilation): .: demodriver.so libGL.so libGLU.so.1.3.070300 libGLw.so.1 galliumlibGL.so.1libglut.solibGLw.so.1.0.0 libEGL.so libGL.so.1.2 libglut.so.3 libEGL.so.1libGLU.so libglut.so.3.7.1 libEGL.so.1.0 libGLU.so.1 libGLw.so ./gallium: EGL_i915.so I see that eg. the static library src/gallium/drivers/i965simple/libi965simple.a is created, but is there something missing? Also make install installs only those files listed above, except that EGL_i915.so does not get installed. -Timo -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: On Tue, Feb 10, 2009 at 4:10 PM, Ian Romanick i...@paranormal-entertainment.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. OK, I think the gallium-master-merge branch is in pretty good shape now. I encourage people to grab it, build it and test. You should probably run 'make realclean' before building. If there's no issues I'll probably merge to master within 24 hours. There's an issue. The non-Gallium build is broken beyond all recognition. Configuring with './configure - --with-dri-driver=swrast,i915,i965' dies in src/gallium/drivers/nv04. If I'm not doing a Gallium build, why is it building src/gallium? If I'm not building the nouveau driver, why is it in drivers/nv04? Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Cheers, Jerome Glisse -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Wed, Feb 11, 2009 at 5:01 AM, Jerome Glisse gli...@freedesktop.org wrote: On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Yeah, I figured as much. It's no big deal. Jakub already pushed something out that has it mostly working. Do you know why the ASM_FLAGS were commented out? Does that conflict with gallium? -- Dan -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Wed, Feb 11, 2009 at 15:53, Dan Nicholson dbn.li...@gmail.com wrote: On Wed, Feb 11, 2009 at 5:01 AM, Jerome Glisse gli...@freedesktop.org wrote: On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Yeah, I figured as much. It's no big deal. Jakub already pushed something out that has it mostly working. Do you know why the ASM_FLAGS were commented out? Does that conflict with gallium? The gallium SSE generator has issues on AMD64. FWIW there are bugs in most assembly generation pieces in the mesa/gallium code so that's the first thing you might want to disable for debugging... Stephane -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Stephane Marchesin wrote: On Wed, Feb 11, 2009 at 15:53, Dan Nicholson dbn.li...@gmail.com wrote: On Wed, Feb 11, 2009 at 5:01 AM, Jerome Glisse gli...@freedesktop.org wrote: On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Yeah, I figured as much. It's no big deal. Jakub already pushed something out that has it mostly working. Do you know why the ASM_FLAGS were commented out? Does that conflict with gallium? The gallium SSE generator has issues on AMD64. FWIW there are bugs in most assembly generation pieces in the mesa/gallium code so that's the first thing you might want to disable for debugging... Can you be more specific about these bugs? The gallium x86 code generation should be working properly, though some shader constructs like loops/conditionals may not be fully supported yet and fall back to the TGSI interpreter. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Wed, 2009-02-11 at 08:27 -0800, Brian Paul wrote: Stephane Marchesin wrote: On Wed, Feb 11, 2009 at 15:53, Dan Nicholson dbn.li...@gmail.com wrote: On Wed, Feb 11, 2009 at 5:01 AM, Jerome Glisse gli...@freedesktop.org wrote: On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Yeah, I figured as much. It's no big deal. Jakub already pushed something out that has it mostly working. Do you know why the ASM_FLAGS were commented out? Does that conflict with gallium? The gallium SSE generator has issues on AMD64. FWIW there are bugs in most assembly generation pieces in the mesa/gallium code so that's the first thing you might want to disable for debugging... Can you be more specific about these bugs? The gallium x86 code generation should be working properly, though some shader constructs like loops/conditionals may not be fully supported yet and fall back to the TGSI interpreter. This is true for 32 bit, but the generating code will need to be reworked for x64 as the ABI and some of the instruction sequences are different there. This is where something nice like llvm swoops in and saves us from more x86 codegen work. Keith -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Wed, Feb 11, 2009 at 17:27, Brian Paul bri...@vmware.com wrote: Stephane Marchesin wrote: On Wed, Feb 11, 2009 at 15:53, Dan Nicholson dbn.li...@gmail.com wrote: On Wed, Feb 11, 2009 at 5:01 AM, Jerome Glisse gli...@freedesktop.org wrote: On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Yeah, I figured as much. It's no big deal. Jakub already pushed something out that has it mostly working. Do you know why the ASM_FLAGS were commented out? Does that conflict with gallium? The gallium SSE generator has issues on AMD64. FWIW there are bugs in most assembly generation pieces in the mesa/gallium code so that's the first thing you might want to disable for debugging... Can you be more specific about these bugs? Sure, on the gallium side the AMD64/linux calling convention used for SSE generation is wrong. On the mesa side one of the .S files has a bug, and another one has an extra instruction (but harmless one). I'll try to see if I still have the patches for that. Anyway, I never fixed those because each time I look at it I feel like I'd better spend time on the llvm stuff. Which, incidentally, I do. Stephane -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Wed, Feb 11, 2009 at 17:27, Brian Paul bri...@vmware.com wrote: Stephane Marchesin wrote: On Wed, Feb 11, 2009 at 15:53, Dan Nicholson dbn.li...@gmail.com wrote: On Wed, Feb 11, 2009 at 5:01 AM, Jerome Glisse gli...@freedesktop.org wrote: On Tue, 2009-02-10 at 16:47 -0800, Dan Nicholson wrote: Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan Sorry about that this was a patch i didn't want to push upstream IIRC. When i was hacking on gallium i found that DRI_DIRS was conflicting btw gallium and non gallium driver, don't remember the exact detail, my autoconf foo never was that good. Yeah, I figured as much. It's no big deal. Jakub already pushed something out that has it mostly working. Do you know why the ASM_FLAGS were commented out? Does that conflict with gallium? The gallium SSE generator has issues on AMD64. FWIW there are bugs in most assembly generation pieces in the mesa/gallium code so that's the first thing you might want to disable for debugging... Can you be more specific about these bugs? Sure, on the gallium side the AMD64/linux calling convention used for SSE generation is wrong. On the mesa side one of the .S files has a bug, and another one has an extra instruction (but harmless one). I'll try to see if I still have the patches for that. Anyway, I never fixed those because each time I look at it I feel like I'd better spend time on the llvm stuff. Which, incidentally, I do. Stephane -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? Brian, looking at the linux-gallium commit you seem to have included stuff that should have gone into the following commit that introduces libmesagallium. When I work on multiple stuff at the same time and want to separate commits up I use the interactive git add (git add - i). And confirm each change as they go in. Also newer version of gitk show the changes that are about to be committed. Git add interactive can show that with 6. Cheers Jakob. [1] http://cgit.freedesktop.org/mesa/mesa/commit/id=abbe96cb6e7581a52652030e40442b943a482840 [2] http://cgit.freedesktop.org/mesa/mesa/commit/id=270ce504052d415870a25ab59818b2309eb8ac13 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, 2009-02-10 at 04:21 -0800, Jakob Bornecrantz wrote: On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? I think I'd prefer either building all or none of the drivers in each case, rather than trying to tweak things up or down driver by driver. Given Dave's preference for building both legacy + gallium drivers from the existing linux-dri-* targets, I'd suggest adding some subdirectories to mesa/lib, along the lines of: mesa/lib mesa/lib/dri mesa/lib/gallium and having the build drivers land in one subdirectory or the other. Distros or whoever can then pluck out the ones they care about from either directory. Keith -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, 2009-02-09 at 11:24 -0700, Brian Paul wrote: Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. OK, I think the gallium-master-merge branch is in pretty good shape now. I encourage people to grab it, build it and test. The traditional r300 and swrast drivers seem to build and work for me with autoconf. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On 10 feb 2009, at 13.39, Keith Whitwell wrote: On Tue, 2009-02-10 at 04:21 -0800, Jakob Bornecrantz wrote: On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? I think I'd prefer either building all or none of the drivers in each case, rather than trying to tweak things up or down driver by driver. Well we need to pick the drivers that can actually be built with drm master. And currently having only DRI_DIRS is not enough since the radeon pipe and winsys doesn't build doesn't but the legacy version does. Which is why the subdirs commit is needed. It is also needed because it allows us to select state_trackers, since currently it is hard coded to glx in the Makefile. In the future we will need to select DRI1/2 ones to, but only for the linux-dri builds. Given Dave's preference for building both legacy + gallium drivers from the existing linux-dri-* targets, I'd suggest adding some subdirectories to mesa/lib, along the lines of: mesa/lib mesa/lib/dri mesa/lib/gallium and having the build drivers land in one subdirectory or the other. Distros or whoever can then pluck out the ones they care about from either directory. I am totally for this idea. The commit I proposed didn't solve this it solved something else. I can whip up a patch which does this. Cheers Jakob. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, 2009-02-10 at 05:41 -0800, Jakob Bornecrantz wrote: On 10 feb 2009, at 13.39, Keith Whitwell wrote: On Tue, 2009-02-10 at 04:21 -0800, Jakob Bornecrantz wrote: On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? I think I'd prefer either building all or none of the drivers in each case, rather than trying to tweak things up or down driver by driver. Well we need to pick the drivers that can actually be built with drm master. And currently having only DRI_DIRS is not enough since the radeon pipe and winsys doesn't build doesn't but the legacy version does. I'm not advocating turning on drivers that don't build by default. Which is why the subdirs commit is needed. It is also needed because it allows us to select state_trackers, since currently it is hard coded to glx in the Makefile. In the future we will need to select DRI1/2 ones to, but only for the linux-dri builds. Given Dave's preference for building both legacy + gallium drivers from the existing linux-dri-* targets, I'd suggest adding some subdirectories to mesa/lib, along the lines of: mesa/lib mesa/lib/dri mesa/lib/gallium and having the build drivers land in one subdirectory or the other. Distros or whoever can then pluck out the ones they care about from either directory. I am totally for this idea. The commit I proposed didn't solve this it solved something else. I can whip up a patch which does this. It sounds like we may have been talking at cross purposes. This is the only point I was trying to make it seems we're in agreement. Keith -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Jakob Bornecrantz wrote: On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? I'm not sure I'll fully understand how your solution works until I try it. How would I build the conventional DRI/Xlib drivers vs. the gallium drivers? Brian, looking at the linux-gallium commit you seem to have included stuff that should have gone into the following commit that introduces libmesagallium. When I work on multiple stuff at the same time and want to separate commits up I use the interactive git add (git add - i). And confirm each change as they go in. Also newer version of gitk show the changes that are about to be committed. Git add interactive can show that with 6. Yeah, I should have split things up better but I was in a rush to get things working. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On 12:39 Tue 10 Feb , Keith Whitwell wrote: I think I'd prefer either building all or none of the drivers in each case, rather than trying to tweak things up or down driver by driver. Given Dave's preference for building both legacy + gallium drivers from the existing linux-dri-* targets, I'd suggest adding some subdirectories to mesa/lib, along the lines of: mesa/lib mesa/lib/dri mesa/lib/gallium and having the build drivers land in one subdirectory or the other. Distros or whoever can then pluck out the ones they care about from either directory. Here is what would work well for me: -Choosing whether to build gallium, old drivers, or both on a global level -Choosing which drivers to build, regardless of which framework is used If you want to get more specific, like choosing different driver sets for each framework, that would also work but goes beyond my uses. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpvbIqr7diIY.pgp Description: PGP signature -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On 10 feb 2009, at 16.46, Brian Paul wrote: Jakob Bornecrantz wrote: On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? I'm not sure I'll fully understand how your solution works until I try it. How would I build the conventional DRI/Xlib drivers vs. the gallium drivers? With the attached patch set there is no difference. You simply build one of the linux-dri-* builds and it builds both legacy and gallium drivers. The variable you want to play around with is GALLIUM_WINSYS_DIRS and GALLIUM_WINSYS_DRM_DIRS, which is currently set to those drivers which build against drm.git master. Currently nouveau and intel (but there is currently no DRI there but the EGL one builds). The gallium based drivers ends up in lib/gallium while the legacy ones still goes in the old directory. Maybe that should be changed to lib/ dri as Keith suggested. There are currently no conflicts between the two sets of drivers since the i915 dri driver isn't built. But in the future things are bound to crop up. Brian, looking at the linux-gallium commit you seem to have included stuff that should have gone into the following commit that introduces libmesagallium. When I work on multiple stuff at the same time and want to separate commits up I use the interactive git add (git add - i). And confirm each change as they go in. Also newer version of gitk show the changes that are about to be committed. Git add interactive can show that with 6. Yeah, I should have split things up better but I was in a rush to get things working. Do the patches look good? Is it okay if I push? Cheers Jakob. 0001-Revert-mesa-added-new-linux-gallium-and-linux-gall.patch Description: Binary data 0002-Revert-cell-update-linux-cell-config.patch Description: Binary data 0003-gallium-Introduce-new-subdirs-build-variables.patch Description: Binary data 0004-gallium-Install-DRI-drivers-into-lib-gallium.patch Description: Binary data 0005-gallium-Don-t-rebuild-common-drm-code.patch Description: Binary data -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Jakob Bornecrantz wrote: On 10 feb 2009, at 16.46, Brian Paul wrote: Jakob Bornecrantz wrote: On 10 feb 2009, at 08.17, Michel Dänzer wrote: On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). It should definitely possible to build both at the same time especially now that the gallium intel dri drivers use the same drm as the legacy intel dri drivers. I think that even the nouveau use the same drm. Brian I have a patch on gallium-xorg-driver that lets us more fine tune the building of the gallium dri drivers. Is it okay if I revert: mesa: added new linux-gallium and linux-gallium-debug configs [1] from gallium-master-merge and apply: gallium: Introduce new subdirs build variables [2] from the gallium-xorg-driver branch? I'm not sure I'll fully understand how your solution works until I try it. How would I build the conventional DRI/Xlib drivers vs. the gallium drivers? With the attached patch set there is no difference. You simply build one of the linux-dri-* builds and it builds both legacy and gallium drivers. The variable you want to play around with is GALLIUM_WINSYS_DIRS and GALLIUM_WINSYS_DRM_DIRS, which is currently set to those drivers which build against drm.git master. Currently nouveau and intel (but there is currently no DRI there but the EGL one builds). The gallium based drivers ends up in lib/gallium while the legacy ones still goes in the old directory. Maybe that should be changed to lib/ dri as Keith suggested. There are currently no conflicts between the two sets of drivers since the i915 dri driver isn't built. But in the future things are bound to crop up. I'm not too concerned about the sub-lib/ dirs right now. We can fine tune that as needed. Brian, looking at the linux-gallium commit you seem to have included stuff that should have gone into the following commit that introduces libmesagallium. When I work on multiple stuff at the same time and want to separate commits up I use the interactive git add (git add - i). And confirm each change as they go in. Also newer version of gitk show the changes that are about to be committed. Git add interactive can show that with 6. Yeah, I should have split things up better but I was in a rush to get things working. Do the patches look good? Is it okay if I push? Yes. Thanks for the explanation. I'll let you know if I have questions. I'll document this stuff when we get it all sorted out. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Dan Nicholson wrote: On Mon, Feb 9, 2009 at 1:11 PM, Brian Paul bri...@vmware.com wrote: Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. thanks, Kristian Dan, I was hoping you'd offer to do that! :) In the long term, we'll probably want to build a mix of both traditional and gallium-based drivers at the same time. For the short-term something like --enable-gallium that would kind of throw a big switch would be OK (build gallium drivers but not the traditional ones). For Cell, it would be nice if we could auto-detect the presence of the Cell SDK headers/libs and build the gallium cell driver if they're present. Whatever you can manage would be appreciated. Sure. I'm not that familiar with what's actually being built under gallium, so it might take a couple days to get familiar with that. Taking a quick glance at gallium-master-merge, it looks like glisse added some support already to configure. Unfortunately, I think it will break the classic mesa build a bit. At least for DRI. I think it should be doable to start with a big --enable-gallium switch. I'm sure eventually we can get something to build classic + gallium in one shot. If anyone wants to shed any light on what's built and installed on gallium vs. classic, I'd appreciate that. I think I have a notional understanding of the pipe/state_tracker/winsys architecture of gallium, but I'm not quite visualizing how that gets built up. Yeah, there's more subdirs now. In general, each subdir we go into builds a .a archive or assembles a group of .a archives into a .so shared library. If you do a traditional 'make config' build then do a 'find . name *.a' you can get an idea of where things are. You might want to hold off on updating autoconf until we get things a bit more sorted out. Also, I've brought this up before, but I think it would be really helpful to require GNU make for building mesa. Building classic DRI or gallium already requires it, but I think it will become really ugly to keep all the build logic stashed in configure as the options continue to expand. What I'd like is some judicious use of conditionals: http://www.gnu.org/software/make/manual/make.html#Conditionals Just something to think about. I know there are some platforms where GNU make is not the default, but it is usually easily available. Well, some GNU make features are used for building gallium now, like $(foreach ...) so we might as well give in. We'll see if anyone complains... -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, Feb 10, 2009 at 8:33 AM, Brian Paul bri...@vmware.com wrote: Dan Nicholson wrote: On Mon, Feb 9, 2009 at 1:11 PM, Brian Paul bri...@vmware.com wrote: Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. thanks, Kristian Dan, I was hoping you'd offer to do that! :) In the long term, we'll probably want to build a mix of both traditional and gallium-based drivers at the same time. For the short-term something like --enable-gallium that would kind of throw a big switch would be OK (build gallium drivers but not the traditional ones). For Cell, it would be nice if we could auto-detect the presence of the Cell SDK headers/libs and build the gallium cell driver if they're present. Whatever you can manage would be appreciated. Sure. I'm not that familiar with what's actually being built under gallium, so it might take a couple days to get familiar with that. Taking a quick glance at gallium-master-merge, it looks like glisse added some support already to configure. Unfortunately, I think it will break the classic mesa build a bit. At least for DRI. I think it should be doable to start with a big --enable-gallium switch. I'm sure eventually we can get something to build classic + gallium in one shot. If anyone wants to shed any light on what's built and installed on gallium vs. classic, I'd appreciate that. I think I have a notional understanding of the pipe/state_tracker/winsys architecture of gallium, but I'm not quite visualizing how that gets built up. Yeah, there's more subdirs now. In general, each subdir we go into builds a .a archive or assembles a group of .a archives into a .so shared library. If you do a traditional 'make config' build then do a 'find . name *.a' you can get an idea of where things are. Yeah, that seems like it's probably the best way to get familiar. Actually, reading Jakob's patches has already enlightened me quite a bit. You might want to hold off on updating autoconf until we get things a bit more sorted out. Not to mention that more lurking is educational. :) I'll probably just start playing with the general big-switch stuff at first before worrying too much about particular drivers and architecture. Also, I've brought this up before, but I think it would be really helpful to require GNU make for building mesa. Building classic DRI or gallium already requires it, but I think it will become really ugly to keep all the build logic stashed in configure as the options continue to expand. What I'd like is some judicious use of conditionals: http://www.gnu.org/software/make/manual/make.html#Conditionals Just something to think about. I know there are some platforms where GNU make is not the default, but it is usually easily available. Well, some GNU make features are used for building gallium now, like $(foreach ...) so we might as well give in. We'll see if anyone complains... I think it would be best to enforce it in the top-level Makefile so there's no question about what's going on. default: check-gnu-make $(TOP)/configs/current .PHONY: check-gnu-make check-gnu-make: @if ! $(MAKE) --version | grep GNU /dev/null 21; then \ echo error: GNU make is required 2; \ exit 1; \ fi -- Dan -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Dan Nicholson wrote: On Tue, Feb 10, 2009 at 8:33 AM, Brian Paul bri...@vmware.com wrote: Dan Nicholson wrote: On Mon, Feb 9, 2009 at 1:11 PM, Brian Paul bri...@vmware.com wrote: Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. thanks, Kristian Dan, I was hoping you'd offer to do that! :) In the long term, we'll probably want to build a mix of both traditional and gallium-based drivers at the same time. For the short-term something like --enable-gallium that would kind of throw a big switch would be OK (build gallium drivers but not the traditional ones). For Cell, it would be nice if we could auto-detect the presence of the Cell SDK headers/libs and build the gallium cell driver if they're present. Whatever you can manage would be appreciated. Sure. I'm not that familiar with what's actually being built under gallium, so it might take a couple days to get familiar with that. Taking a quick glance at gallium-master-merge, it looks like glisse added some support already to configure. Unfortunately, I think it will break the classic mesa build a bit. At least for DRI. I think it should be doable to start with a big --enable-gallium switch. I'm sure eventually we can get something to build classic + gallium in one shot. If anyone wants to shed any light on what's built and installed on gallium vs. classic, I'd appreciate that. I think I have a notional understanding of the pipe/state_tracker/winsys architecture of gallium, but I'm not quite visualizing how that gets built up. Yeah, there's more subdirs now. In general, each subdir we go into builds a .a archive or assembles a group of .a archives into a .so shared library. If you do a traditional 'make config' build then do a 'find . name *.a' you can get an idea of where things are. Yeah, that seems like it's probably the best way to get familiar. Actually, reading Jakob's patches has already enlightened me quite a bit. You might want to hold off on updating autoconf until we get things a bit more sorted out. Not to mention that more lurking is educational. :) I'll probably just start playing with the general big-switch stuff at first before worrying too much about particular drivers and architecture. Also, I've brought this up before, but I think it would be really helpful to require GNU make for building mesa. Building classic DRI or gallium already requires it, but I think it will become really ugly to keep all the build logic stashed in configure as the options continue to expand. What I'd like is some judicious use of conditionals: http://www.gnu.org/software/make/manual/make.html#Conditionals Just something to think about. I know there are some platforms where GNU make is not the default, but it is usually easily available. Well, some GNU make features are used for building gallium now, like $(foreach ...) so we might as well give in. We'll see if anyone complains... I think it would be best to enforce it in the top-level Makefile so there's no question about what's going on. default: check-gnu-make $(TOP)/configs/current .PHONY: check-gnu-make check-gnu-make: @if ! $(MAKE) --version | grep GNU /dev/null 21; then \ echo error: GNU make is required 2; \ exit 1; \ fi Sounds like a good idea. I'll list this requirement in the docs too, of course. BTW everyone, I'm planning on merging gallium-master-merge to master this afternoon. Then I'll merge in the latest gallium-0.2 changes to get those. (OR, should I merge gallium-0.2 into gallium-master-merge first? Git gurus?) gallium-0.2 will be closed at that point. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, Feb 10, 2009 at 9:49 AM, Brian Paul bri...@vmware.com wrote: BTW everyone, I'm planning on merging gallium-master-merge to master this afternoon. Then I'll merge in the latest gallium-0.2 changes to get those. (OR, should I merge gallium-0.2 into gallium-master-merge first? Git gurus?) gallium-0.2 will be closed at that point. I don't think it matters much, but I would get the merge branch all up to date (merge gallium-0.2 into gallium-master-merge) and then merge that to master. That seems cleaner in my eyes: get all the gallium changes on one branch and then merge it to master. -- Dan -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
OK, the merge is done and pushed. Seems to have gone OK. Please report any problems found and we'll try to fix them ASAP. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: On Mon, 2009-02-09 at 13:10 -0800, Dave Airlie wrote: On Mon, 9 Feb 2009, Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. Maybe this is a dumb question, but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so I don't think people outside VMWare are using the build targets from configs any longer. I believe that most people are using the autoconf mechanism. or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. If we're ending up with multiple, identically named drivers for the same hardware, we've already lost. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmSGiwACgkQX1gOwKyEAw+hSwCfavIWf+3IHZqmhRPE5ybSETMq Gj0AoJ1XSgMBbdMz9QhSnRpl9XGaNE1F =pI3H -END PGP SIGNATURE- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Wed, Feb 11, 2009 at 01:22, Ian Romanick i...@paranormal-entertainment.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: On Mon, 2009-02-09 at 13:10 -0800, Dave Airlie wrote: On Mon, 9 Feb 2009, Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. Maybe this is a dumb question, but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so I don't think people outside VMWare are using the build targets from configs any longer. I believe that most people are using the autoconf mechanism. I for one use the configs too. Stephane -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. OK, I think the gallium-master-merge branch is in pretty good shape now. I encourage people to grab it, build it and test. You should probably run 'make realclean' before building. If there's no issues I'll probably merge to master within 24 hours. There's an issue. The non-Gallium build is broken beyond all recognition. Configuring with './configure - --with-dri-driver=swrast,i915,i965' dies in src/gallium/drivers/nv04. If I'm not doing a Gallium build, why is it building src/gallium? If I'm not building the nouveau driver, why is it in drivers/nv04? Please fix. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmSF3EACgkQX1gOwKyEAw9GogCfett+guqChsP4lgMws5A+iVul kP0AnisExElVHEQNUV35e7R7mpgt/OZC =DFy6 -END PGP SIGNATURE- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, Feb 10, 2009 at 4:10 PM, Ian Romanick i...@paranormal-entertainment.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. OK, I think the gallium-master-merge branch is in pretty good shape now. I encourage people to grab it, build it and test. You should probably run 'make realclean' before building. If there's no issues I'll probably merge to master within 24 hours. There's an issue. The non-Gallium build is broken beyond all recognition. Configuring with './configure - --with-dri-driver=swrast,i915,i965' dies in src/gallium/drivers/nv04. If I'm not doing a Gallium build, why is it building src/gallium? If I'm not building the nouveau driver, why is it in drivers/nv04? Jerome commented out the DRI_DIRS part and some other stuff in the gallium branch and that's been merged in. I was going to take a look at it a little later, but if you just want to get a non-gallium build, you may want to revert 14f79d46. http://cgit.freedesktop.org/mesa/mesa/commit/?id=14f79d46 -- Dan -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] merging gallium-0.2 branch to master
Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. OK, I think the gallium-master-merge branch is in pretty good shape now. I encourage people to grab it, build it and test. You should probably run 'make realclean' before building. If there's no issues I'll probably merge to master within 24 hours. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. -- Dan -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, 2009-02-09 at 10:24 -0800, Brian Paul wrote: Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. OK, I think the gallium-master-merge branch is in pretty good shape now. I encourage people to grab it, build it and test. You should probably run 'make realclean' before building. If there's no issues I'll probably merge to master within 24 hours. Karl, Thomas, I noticed you've been updating the VC8 project files. I've modified several of the examples in the gallium branch to use GLEW library, in order to get more demos building on Windows. You might want update your VC8 project files to build and link the glew library in src/glew after the merge. I also encourage you to try building the glut and the mesa examples for windows with scons. It builds with any MSVC version, MinGW, and MinGW cross compilers. To build it do: set GALLIUM=\path\to\mesa scons -C mesa debug=yes platform=windows scons -C mesa\progs debug=yes platform=windows Jose -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. thanks, Kristian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, 9 Feb 2009, Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. Maybe this is a dumb question, but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Dave. thanks, Kristian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. thanks, Kristian Dan, I was hoping you'd offer to do that! :) In the long term, we'll probably want to build a mix of both traditional and gallium-based drivers at the same time. For the short-term something like --enable-gallium that would kind of throw a big switch would be OK (build gallium drivers but not the traditional ones). For Cell, it would be nice if we could auto-detect the presence of the Cell SDK headers/libs and build the gallium cell driver if they're present. Whatever you can manage would be appreciated. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, 2009-02-09 at 13:10 -0800, Dave Airlie wrote: On Mon, 9 Feb 2009, Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. Maybe this is a dumb question, but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so No not the one we'd like. or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so I'd suspect we'd prefer this, then we can pick and choose at packaging time which drivers we want to ship in the OS. The 3rd option involves trying to define GALLIUM_DRIVERS/DRI_DRIVERS and making sure they don't intersect which just seems like a recipe for pain. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. Please disable radeon winsys and r300 pipe driver from building by default, as they are made of bonghits, insomnia, and fail at the moment. ~ C. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Corbin Simpson wrote: Brian Paul wrote: Over the next day or so we're going to merge the gallium-0.2 branch to master. master and gallium-0.2 are both development branches and keeping the core Mesa work synced between them is a bit of PITA. To work out the kinks I'll be pushing a short term gallium-master-merge branch for testing/fixing before going to master. In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. Please disable radeon winsys and r300 pipe driver from building by default, as they are made of bonghits, insomnia, and fail at the moment. Feel free to make that change. -Brian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Tue, 2009-02-10 at 01:57 +0100, Anders Juel Jensen wrote: On Monday 09 February 2009 22:15:44 Keith Whitwell wrote: but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Anything's possible -- I guess I'm not clear on which is preferable, so feedback is welcome. We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so Note that there are going to be multiple, different copies of xyz_dri.so in the second approach. Is there a third option? Keith It would be nice if it was possible to have both installed, and an easy way to switch between them in xorg.conf It's always been easier than that: Just point $LIBGL_DRIVERS_PATH to the directory (directories) containing the driver you want to use. Each application can use a different driver (of course, the 3D driver has to be compatible with the X driver). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
