Re: X11R6.8.2 maintenance release plans and call for comments.
Dieter Nützel wrote: Am Samstag, 30. Oktober 2004 19:01 schrieb Brian Paul: To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. For XFree86 DRI it could looks like this: Since you seem to be almost the only person still interested in seeing DRI CVS build :), would you like to have CVS access? I forget what the magic incantation is to add someone to a CVS access list on sf.net. Anyone remember? --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
Ian Romanick wrote: Dieter Nützel wrote: Am Samstag, 30. Oktober 2004 19:01 schrieb Brian Paul: To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. For XFree86 DRI it could looks like this: Since you seem to be almost the only person still interested in seeing DRI CVS build :), would you like to have CVS access? I forget what the magic incantation is to add someone to a CVS access list on sf.net. Anyone remember? The general concept behind having DRI or Xorg track Mesa CVS directly was to help us over the hump of a fairly involved code reorg. I think now we should be looking at importing (or tracking I guess) the Mesa stable branch in these external trees. Keith --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
Am Montag, 1. November 2004 19:22 schrieb Ian Romanick: Dieter Nützel wrote: Am Samstag, 30. Oktober 2004 19:01 schrieb Brian Paul: To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. For XFree86 DRI it could looks like this: Since you seem to be almost the only person still interested in seeing DRI CVS build :), As long as I have to stay on SuSE 9.0...8-) would you like to have CVS access? Yes, please. I'll see if I get it going (Mesa/DRI CVS) without my hack in texcompress_s3tc.c, too. --- src/mesa/main/texcompress_s3tc.c2004-11-01 20:57:53.591644937 +0100 +++ src/mesa/main/texcompress_s3tc.c.Dieter 2004-10-18 15:27:41.0 +0200 @@ -29,7 +29,11 @@ */ #ifndef USE_EXTERNAL_DXTN_LIB +#if defined(XFree86LOADER) defined(IN_MODULE) #define USE_EXTERNAL_DXTN_LIB 0 +#else +#define USE_EXTERNAL_DXTN_LIB 1 +#endif #endif I have some more fixes, too. I forget what the magic incantation is to add someone to a CVS access list on sf.net. Anyone remember? ;-) Greetings, Dieter --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
Dieter Nützel wrote: Am Montag, 1. November 2004 19:22 schrieb Ian Romanick: Dieter Nützel wrote: Am Samstag, 30. Oktober 2004 19:01 schrieb Brian Paul: To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. For XFree86 DRI it could looks like this: Since you seem to be almost the only person still interested in seeing DRI CVS build :), As long as I have to stay on SuSE 9.0...8-) would you like to have CVS access? Yes, please. I'll see if I get it going (Mesa/DRI CVS) without my hack in texcompress_s3tc.c, too. --- src/mesa/main/texcompress_s3tc.c2004-11-01 20:57:53.591644937 +0100 +++ src/mesa/main/texcompress_s3tc.c.Dieter 2004-10-18 15:27:41.0 +0200 @@ -29,7 +29,11 @@ */ #ifndef USE_EXTERNAL_DXTN_LIB +#if defined(XFree86LOADER) defined(IN_MODULE) #define USE_EXTERNAL_DXTN_LIB 0 +#else +#define USE_EXTERNAL_DXTN_LIB 1 +#endif #endif I have some more fixes, too. I forget what the magic incantation is to add someone to a CVS access list on sf.net. Anyone remember? I can do if if you forward me your sourceforge user id. Keith --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
thanks, with sharedObjects_xorg.diff (send in attach) fix the compile problem. With compilesavage.diff, I delete unicrome, i810 and radeon dri drives because they have compile problems. So I can compile Xorg cvs with last Mesa cvs source with no problem. Btw: last update on savage today resolve the unresolved symbols (==) Log file: /var/log/Xorg.0.log, Time: Sun Oct 31 20:08:33 2004 --- (==) Log file: /var/log/Xorg.0.log, Time: Sun Oct 31 20:51:05 2004 799,801d798 Symbol SavageInitStreamsOld from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol SavageInitStreams2000 from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol SavageInitStreamsNew from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! 857,858d853 (II) SAVAGE(0): [drm] removed 1 reserved context for kernel (II) SAVAGE(0): [drm] unmapping 8192 bytes of SAREA 0xce9f2000 at 0x4000c000 thanks, On Sat, 2004-10-30 at 21:17, Dieter Nützel wrote: Am Samstag, 30. Oktober 2004 19:01 schrieb Brian Paul: To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. Sérgio Monteiro Basto wrote: Sorry I have to correct this information but with last Mesa CVS this is not correct and I can't compile Mesa anymore. I get this error that can't workaround GL/mesa/GLcore/libGLcore.a(state.o)(.text+0xf7c): In function `_mesa_init_exec_table': : undefined reference to `_mesa_DeleteObjectARB' -- Sérgio M. B. --- xc/lib/GL/mesa/shader/Imakefile.inc.orig 2004-06-16 10:27:56.0 +0100 +++ xc/lib/GL/mesa/shader/Imakefile.inc 2004-10-31 18:48:35.0 + @@ -15,7 +15,8 @@ $(MESASHADERBUILDDIR)nvfragparse.c \ $(MESASHADERBUILDDIR)nvvertexec.c \ $(MESASHADERBUILDDIR)nvvertparse.c \ - $(MESASHADERBUILDDIR)program.c + $(MESASHADERBUILDDIR)program.c \ + $(MESASHADERBUILDDIR)shaderobjects.c #ifdef NeedToLinkMesaSrc LinkSourceFile(arbprogparse.c, $(MESASRCDIR)/src/mesa/shader) @@ -44,6 +45,8 @@ LinkSourceFile(grammar_syn.h, $(MESASRCDIR)/src/mesa/shader) LinkSourceFile(program.c, $(MESASRCDIR)/src/mesa/shader) LinkSourceFile(program.h, $(MESASRCDIR)/src/mesa/shader) +LinkSourceFile(shaderobjects.c, $(MESASRCDIR)/src/mesa/shader) +LinkSourceFile(shaderobjects.h, $(MESASRCDIR)/src/mesa/shader) #endif MESA_SHADER_OBJS = $(MESASHADERBUILDDIR)arbprogparse.o \ @@ -55,7 +58,8 @@ $(MESASHADERBUILDDIR)nvfragparse.o \ $(MESASHADERBUILDDIR)nvvertexec.o \ $(MESASHADERBUILDDIR)nvvertparse.o \ - $(MESASHADERBUILDDIR)program.o + $(MESASHADERBUILDDIR)program.o \ + $(MESASHADERBUILDDIR)shaderobjects.o #if defined(DoSharedLib) DoSharedLib MESA_SHADER_UOBJS = $(MESASHADERBUILDDIR)unshared/arbprogparse.o \ @@ -67,7 +71,8 @@ $(MESASHADERBUILDDIR)unshared/nvfragparse.o \ $(MESASHADERBUILDDIR)unshared/nvvertexec.o \ $(MESASHADERBUILDDIR)unshared/nvvertparse.o \ - $(MESASHADERBUILDDIR)unshared/program.o + $(MESASHADERBUILDDIR)unshared/program.o \ + $(MESASHADERBUILDDIR)unshared/shaderobjects.o #else MESA_SHADER_UOBJS = $(MESA_SHADER_OBJS) #endif @@ -81,7 +86,8 @@ $(MESASHADERBUILDDIR)debugger/nvfragparse.o \ $(MESASHADERBUILDDIR)debugger/nvvertexec.o \ $(MESASHADERBUILDDIR)debugger/nvvertparse.o \ - $(MESASHADERBUILDDIR)debugger/program.o + $(MESASHADERBUILDDIR)debugger/program.o \ + $(MESASHADERBUILDDIR)debugger/shaderobjects.o MESA_SHADER_POBJS = $(MESASHADERBUILDDIR)profiled/arbprogparse.o \ $(MESASHADERBUILDDIR)profiled/arbprogram.o \ @@ -92,4 +98,5 @@ $(MESASHADERBUILDDIR)profiled/nvfragparse.o \ $(MESASHADERBUILDDIR)profiled/nvvertexec.o \ $(MESASHADERBUILDDIR)profiled/nvvertparse.o \ - $(MESASHADERBUILDDIR)profiled/program.o + $(MESASHADERBUILDDIR)profiled/program.o \ + $(MESASHADERBUILDDIR)profiled/shaderobjects.o --- xc/config/cf/xorg.cf.orig 2004-10-30 03:26:27.0 +0100 +++ xc/config/cf/xorg.cf 2004-10-30 06:17:56.0 +0100 @@ -406,16 +406,16 @@ # endif # ifndef DevelDRIDrivers -# define DevelDRIDrivers ffb mach64 savage unichrome +# define DevelDRIDrivers ffb mach64 savage # endif # ifndef DriDrivers # ifndef ia64Architecture -# define i386DRIDrivers i810 i915 +# define i386DRIDrivers i915 # else # define i386DRIDrivers /**/ # endif -# define DriDrivers gamma i386DRIDrivers mga r128 radeon r200 \ +# define DriDrivers gamma i386DRIDrivers mga r128 r200 \ sis tdfx # endif #endif
Re: X11R6.8.2 maintenance release plans and call for comments.
To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. -Brian Sérgio Monteiro Basto wrote: Sorry I have to correct this information but with last Mesa CVS this is not correct and I can't compile Mesa anymore. I get this error that can't workaround GL/mesa/GLcore/libGLcore.a(state.o)(.text+0xf7c): In function `_mesa_init_exec_table': : undefined reference to `_mesa_DeleteObjectARB' GL/mesa/GLcore/libGLcore.a(state.o)(.text+0xf86): In function `_mesa_init_exec_table': : undefined reference to `_mesa_GetHandleARB' etc ... but Xorg should update Mesa with Mesa 6.2 at least, because Mesa 6.2 is a stable release which just fixes bugs since the 6.1 release. thanks, On Sat, 2004-10-30 at 00:26, Sérgio wrote: On Thu, 2004-10-28 at 21:59, Mike Mestnik wrote: -- Srgio M. Basto [EMAIL PROTECTED] wrote: There is another problem with the Xorg(stable or unstable) tree getting too far ahead of the Mesa/drm trees, AKA can't build Mesa with latesed Xorg. I compile Xorg cvs tree with last Mesa/drm, just do two symbolic link, I just do it now cd /opt/xorgcvs/xc/extras/ mv Mesa drm ../../ ( you will those directory for update Xorg cvs, better than delete it and download again) ln -s /opt/trunk/drm ln -s /opt/trunk/Mesa/ rm -Rf build; mkdir build; cd build; lndir ../xc ; make World makeworld.log ; sleep 1 ; tail -f makeworld.log (lndir doens't work well with symbolic links of mesa, so we have to delete all and make it again ) and I compile and built xorg just fine with no problems, I just have to delete via from build/lib/GL/mesa/drivers/dri/Makefile because doesn't compile but is a reported problem on via drive. thanks, --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
Am Samstag, 30. Oktober 2004 19:01 schrieb Brian Paul: To fix this, somebody just has to add mesa/src/shaders/shaderobjects.c to the Makefiles. For XFree86 DRI it could looks like this: --- xc/lib/GL/mesa/shader/Imakefile.inc 2004-10-30 22:14:42.735599211 +0200 +++ xc/lib/GL/mesa/shader/Imakefile.inc.Dieter 2004-10-30 20:26:44.0 +0200 @@ -15,7 +15,8 @@ $(MESASHADERBUILDDIR)nvfragparse.c \ $(MESASHADERBUILDDIR)nvvertexec.c \ $(MESASHADERBUILDDIR)nvvertparse.c \ - $(MESASHADERBUILDDIR)program.c + $(MESASHADERBUILDDIR)program.c \ + $(MESASHADERBUILDDIR)shaderobjects.c #ifdef NeedToLinkMesaSrc LinkSourceFile(arbprogparse.c, $(MESASRCDIR)/src/mesa/shader) @@ -44,6 +45,9 @@ LinkSourceFile(grammar_syn.h, $(MESASRCDIR)/src/mesa/shader) LinkSourceFile(program.c, $(MESASRCDIR)/src/mesa/shader) LinkSourceFile(program.h, $(MESASRCDIR)/src/mesa/shader) +LinkSourceFile(shaderobjects.c, $(MESASRCDIR)/src/mesa/shader) +LinkSourceFile(shaderobjects.h, $(MESASRCDIR)/src/mesa/shader) + #endif MESA_SHADER_OBJS = $(MESASHADERBUILDDIR)arbprogparse.o \ @@ -55,7 +59,8 @@ $(MESASHADERBUILDDIR)nvfragparse.o \ $(MESASHADERBUILDDIR)nvvertexec.o \ $(MESASHADERBUILDDIR)nvvertparse.o \ - $(MESASHADERBUILDDIR)program.o + $(MESASHADERBUILDDIR)program.o \ + $(MESASHADERBUILDDIR)shaderobjects.o #if defined(DoSharedLib) DoSharedLib MESA_SHADER_UOBJS = $(MESASHADERBUILDDIR)unshared/arbprogparse.o \ @@ -67,7 +72,8 @@ $(MESASHADERBUILDDIR)unshared/nvfragparse.o \ $(MESASHADERBUILDDIR)unshared/nvvertexec.o \ $(MESASHADERBUILDDIR)unshared/nvvertparse.o \ - $(MESASHADERBUILDDIR)unshared/program.o + $(MESASHADERBUILDDIR)unshared/program.o \ + $(MESASHADERBUILDDIR)shaderobjects.o #else MESA_SHADER_UOBJS = $(MESA_SHADER_OBJS) #endif @@ -81,7 +87,8 @@ $(MESASHADERBUILDDIR)debugger/nvfragparse.o \ $(MESASHADERBUILDDIR)debugger/nvvertexec.o \ $(MESASHADERBUILDDIR)debugger/nvvertparse.o \ - $(MESASHADERBUILDDIR)debugger/program.o + $(MESASHADERBUILDDIR)debugger/program.o \ + $(MESASHADERBUILDDIR)shaderobjects.o MESA_SHADER_POBJS = $(MESASHADERBUILDDIR)profiled/arbprogparse.o \ $(MESASHADERBUILDDIR)profiled/arbprogram.o \ @@ -92,4 +99,5 @@ $(MESASHADERBUILDDIR)profiled/nvfragparse.o \ $(MESASHADERBUILDDIR)profiled/nvvertexec.o \ $(MESASHADERBUILDDIR)profiled/nvvertparse.o \ - $(MESASHADERBUILDDIR)profiled/program.o + $(MESASHADERBUILDDIR)profiled/program.o \ + $(MESASHADERBUILDDIR)shaderobjects.o Cheers, Dieter Sérgio Monteiro Basto wrote: Sorry I have to correct this information but with last Mesa CVS this is not correct and I can't compile Mesa anymore. I get this error that can't workaround GL/mesa/GLcore/libGLcore.a(state.o)(.text+0xf7c): In function `_mesa_init_exec_table': : undefined reference to `_mesa_DeleteObjectARB' --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
On Thu, 2004-10-28 at 21:59, Mike Mestnik wrote: -- Srgio M. Basto [EMAIL PROTECTED] wrote: There is another problem with the Xorg(stable or unstable) tree getting too far ahead of the Mesa/drm trees, AKA can't build Mesa with latesed Xorg. I compile Xorg cvs tree with last Mesa/drm, just do two symbolic link, I just do it now cd /opt/xorgcvs/xc/extras/ mv Mesa drm ../../ ( you will those directory for update Xorg cvs, better than delete it and download again) ln -s /opt/trunk/drm ln -s /opt/trunk/Mesa/ rm -Rf build; mkdir build; cd build; lndir ../xc ; make World makeworld.log ; sleep 1 ; tail -f makeworld.log (lndir doens't work well with symbolic links of mesa, so we have to delete all and make it again ) and I compile and built xorg just fine with no problems, I just have to delete via from build/lib/GL/mesa/drivers/dri/Makefile because doesn't compile but is a reported problem on via drive. thanks, -- Sérgio M. B. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
Hello, On Wed, 2004-10-27 at 09:28, Ely Levy wrote: I supported it then and I still think it's a great idea, It would let people feel that they have influance and let us see what people want (but we said it all in the thread there). what I would like to see, is two trees one for testings (stable) and one for development (unstable) The one for developing should have also development of Mesa and drm (that it is now on trunk tree) and the test tree should be updated ( drives , dri-drives, Mesa, drm and whatever ) only when is consolidated the development. Conclusion in my point of view: The development tree should be, what is now the trunk tree and xorg tree should be more stable, if someone want try experimental code can do it in trunk (of course trunk has to be one xorgR6.8.1). thats my opinion. thats, -- Sérgio M. B. --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
--- Sérgio M. Basto [EMAIL PROTECTED] wrote: Hello, On Wed, 2004-10-27 at 09:28, Ely Levy wrote: I supported it then and I still think it's a great idea, It would let people feel that they have influance and let us see what people want (but we said it all in the thread there). what I would like to see, is two trees one for testings (stable) and one for development (unstable) The one for developing should have also development of Mesa and drm (that it is now on trunk tree) and the test tree should be updated ( drives , dri-drives, Mesa, drm and whatever ) only when is consolidated the development. There is another problem with the Xorg(stable or unstable) tree getting too far ahead of the Mesa/drm trees, AKA can't build Mesa with latesed Xorg. As A solution I propose that branch tags be added to the Xorg tree for Mesa/drm developement. 1. These branchs should have corrisponding statik/regular tags in the Mesa and drm trees. 2. This way if you look for the tag(in Mesa) for the last tag-id your CO had, you could CO that branch from Xorg and it would allways(IAPW) build. 3. When Mesa development needs another feature(or bugfix from another Xorg branch) added to there branch it's easy. 4. These changes would be folded into Xorg's unstable whenever Mesa's code is knowen to build with it... The Xorg branch gets mearged to unstable. Another Xorg branch is created. The Mesa and drm trees get taged with the new tag-id used in Xorg's CVS. Conclusion in my point of view: The development tree should be, what is now the trunk tree and xorg tree should be more stable, if someone want try experimental code can do it in trunk (of course trunk has to be one xorgR6.8.1). thats my opinion. thats, -- Sérgio M. B. --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
