[Dri-devel] Mach64 3D capabilities
Hi dri-devel, There has been some discussion in the dri-user mailing list about the 3D capabilities of the Mach64 driver so I thought that maybe some of you guys working on the dri driver have a word about it :-) Has the Mach64 chipset onboard of ATI Mobility cards hardware accelerated 3D functions? If so, how they compare with other ATI chipsets like Rage 128 or Radeon? thank you!! -- Pilluli. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
On 2001.12.10 23:17 Sergey V. Udaltsov wrote: Try the tunnel demo. For me it went from 0.7fps to 25fps. For me, numbers are similar. Though, there are problems with fog: tunnel cannot turn it on (in fact, nothing happens on f - the fog is always off). For pre-pre-pre-alpha, this is not crucual though... Just one question to gurus: I'm no guru, but this is what I've know from a thread in this list at the time I was also trying to build the mach64 branch myself, about a month ago. Suppose, I took mach64-0-0-2-bramch tag. Are these actions correct: 1. Set in config/cf/site.def #define ProjectRoot /usr/X11R6-DRI 2. Do make World 3. Do make install Is it everything I need? How I can ask compiler use existing XFree headers and libraries? How I can build the kernel modules? Not really. Before you 'make install' you must make a mirror with symbolic link of your existing /usr/X11R6 to /usr/X11R6-DRI using the 'lndir' command for that: mkdir /usr/X11R6-DRI lndir /usr/X11R6 /usr/X11R6-DRI Setting the ProjectRoot in /usr/X11R6-DRI isn't even necessary since is the default already. If you have RedHat 7.x you also have to add the patch that is attached because of a problem in the gcc-2.96 code optimization leading to modules that can't be loaded by the X server. The kernel modules are built and installed at the same time. Any info (or references to documents in XFree tree) would be highly appreciated... Sorry, I was so dumb I could not find the answers at dri.sourceforge.net. Unfortunatly the only reference is the DRI Compilation Guide which has not been updated recently to include this. Someone really should do that because there has been a lot of people trying to test the cvs tree (especially the mach64 branch). Cheers, Sergey Regards, Jose Fonseca *** xc.old/xc/config/cf/host.def Tue Dec 4 17:14:35 2001 --- xc/xc/config/cf/host.def Tue Dec 4 17:15:45 2001 *** *** 16,19 --- 16,24 #endif + #define NeedModuleRanlib YES + #define ModuleCFlags $(CDEBUGFLAGS) $(CCOPTIONS) -fno-merge-constants \ + $(THREAD_CFLAGS) $(ALLDEFINES) + #define ModuleRanlibCmd RanlibCmd + #define BuildXFree86ConfigTools NO
Re: [Dri-devel] Mach64 driver
mkdir /usr/X11R6-DRI lndir /usr/X11R6 /usr/X11R6-DRI It's already done, thanks to binaries you gave me:) Setting the ProjectRoot in /usr/X11R6-DRI isn't even necessary since is the default already. Really? In which file? site.def contains ProjectRoot /usr/X11R6 but host.def contains /usr/X11R6-DRI. Which one is really used? If you have RedHat 7.x you also have to add the patch that is attached because of a problem in the gcc-2.96 code optimization leading to modules that can't be loaded by the X server. Thanks. Unfortunatly the only reference is the DRI Compilation Guide which has not been updated recently to include this. Someone really should do that because there has been a lot of people trying to test the cvs tree (especially the mach64 branch). Probably I'll be able to write little 10 lines HOWTO and post it here. When I finish the process...:) Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
On Tue, 2001-12-11 at 10:54, Michael Thaler wrote: On Mon, Dec 10, 2001 at 03:09:35PM +, Jose Fonseca wrote: I don't know what particular version of XFree 4.10 you have used but you must also install the X server from the mach64 build tree. The usual way is to 'lndir' your /usr/X11R6/ dir to /usr/X11R6-DRI/ and then 'make install'. This way you avoid file duplication. O.K. I tried to compile it and got a lot of errors. What I did was: mkdir DRI-CVS cd DRI-CVS/ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co xc cd xc cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri update -P -d -r mach64-0-0-2-branch I don't know much about cvs but usually I just do: cvs -z3 [EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I don't know if updating a branch after checking out the trunk you get everything all right. Perhaps some one in the list could enlighten this... ln -s xc XFree40 mkdir build cd build lndir -silent -ignorelinks ../XFree40 cd ~/DRI-CVS/build/xc/ make World World.LOG I think I did everything like described in the compilation guide but I go a lot of errors. It seems I do something terribly wrong. I got the following errors: /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status You should have included the command that generated this error. Anyway something wrong must have happened before when building Xext. The rest of the errors are the consequence of this one... + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[5]: *** [libGL.so.1.2] Error 1 make[5]: Target `all' not remade because of errors. make[5]: Leaving directory `/home/michi/DRI-CVS/build/xc/lib/GL/GL' making all in lib/GL/mesa/src/OSmesa... /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status + rm -f libOSMesa.so.3 + ln -s libOSMesa.so.3.3 libOSMesa.so.3 + rm -f ../../../../../exports/lib/libOSMesa.so.3 + cd ../../../../../exports/lib + ln -s ../../lib/GL/mesa/src/OSmesa/libOSMesa.so.3 . rm -f libOSMesa.so.3.3 mv -f libOSMesa.so.3.3~ libOSMesa.so.3.3 mv: cannot stat `libOSMesa.so.3.3~': No such file or directory make[5]: *** [libOSMesa.so.3.3] Error 1 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status + rm -f libOSMesa.so.3 + ln -s libOSMesa.so.3.3 libOSMesa.so.3 + rm -f ../../../../../exports/lib/libOSMesa.so.3 + cd ../../../../../exports/lib + ln -s ../../lib/GL/mesa/src/OSmesa/libOSMesa.so.3 . rm -f libOSMesa.so.3.3 mv -f libOSMesa.so.3.3~ libOSMesa.so.3.3 mv: cannot stat `libOSMesa.so.3.3~': No such file or directory make[5]: *** [libOSMesa.so.3.3] Error 1 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [gamma_dri.so] Error 1 make[6]: Target `all' not remade because of errors. make[6]: Target `all' not remade because of errors. make[6]: Leaving directory `/home/michi/DRI-CVS/build/xc/lib/GL/mesa/src/drv/gamma' /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [mach64_dri.so] Error 1 usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [mga_dri.so] Error 1 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [i810_dri.so] Error 1 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [r128_dri.so] Error 1 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [radeon_dri.so] Error 1 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[6]: *** [sis_dri.so] Error 1 Yesterday I build everything from the mach64-0-0-1-branch and I did not get this errors. Anyone has a hint what I am doing wrong here? Have I forgot something? You forgot to CC the dri-devel ML. :) Greetings, Michael Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
On Tue, 2001-12-11 at 10:45, Sergey V. Udaltsov wrote: mkdir /usr/X11R6-DRI lndir /usr/X11R6 /usr/X11R6-DRI It's already done, thanks to binaries you gave me:) Setting the ProjectRoot in /usr/X11R6-DRI isn't even necessary since is the default already. Really? In which file? site.def contains ProjectRoot /usr/X11R6 but host.def contains /usr/X11R6-DRI. Which one is really used? host.def has precedence. It's included before the conditional definition of ProjectRoot in site.def If you have RedHat 7.x you also have to add the patch that is attached because of a problem in the gcc-2.96 code optimization leading to modules that can't be loaded by the X server. Thanks. Unfortunatly the only reference is the DRI Compilation Guide which has not been updated recently to include this. Someone really should do that because there has been a lot of people trying to test the cvs tree (especially the mach64 branch). Probably I'll be able to write little 10 lines HOWTO and post it here. When I finish the process...:) Cheers, Sergey Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
On Tue, Dec 11, 2001 at 11:52:59AM +, Jose Fonseca wrote: cvs -z3 [EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I don't have a login so I can only download as an anonymous user. I followed the instructions of the compilation guide but I am not familiar with CVS so maybe something went wrong. I don't know if updating a branch after checking out the trunk you get everything all right. Perhaps some one in the list could enlighten this... I am not sure, either. The command provided by the CVS webpage on dri.sourceforge.net did not work. I had to change the order of the options. Maybe this is wrong. You should have included the command that generated this error. Anyway something wrong must have happened before when building Xext. The rest of the errors are the consequence of this one... Sorry, you are right. make[5]: Entering directory `/home/michi/DRI-CVS/build/xc/lib/GL/GL' rm -f libGL.so.1.2~ + cd . + gcc -o ./libGL.so.1.2~ -shared -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/glapinoop.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glapi_x86.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -L/usr/X11R6-DRI/lib -lXext -lX11 -ldl -lc /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[5]: *** [libGL.so.1.2] Error 1 You forgot to CC the dri-devel ML. :) Already done;-) It would be nice if someone writes a little guide how to compile the Mach64 drivers. As soon as I get it working myself I will write a litte doc how I have done it. But I am not an expert in these things;-) Thanks, Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
On Tue, 2001-12-11 at 12:14, Michael Thaler wrote: On Tue, Dec 11, 2001 at 11:52:59AM +, Jose Fonseca wrote: cvs -z3 [EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I don't have a login so I can only download as an anonymous user. I followed the instructions of the compilation guide but I am not familiar with CVS so maybe something went wrong. Me neither. That's not a problem, just login as anonymous: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login Press enter for password and then cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I don't know if updating a branch after checking out the trunk you get everything all right. Perhaps some one in the list could enlighten this... I am not sure, either. The command provided by the CVS webpage on dri.sourceforge.net did not work. I had to change the order of the options. Maybe this is wrong. You should have included the command that generated this error. Anyway something wrong must have happened before when building Xext. The rest of the errors are the consequence of this one... Sorry, you are right. make[5]: Entering directory `/home/michi/DRI-CVS/build/xc/lib/GL/GL' rm -f libGL.so.1.2~ + cd . + gcc -o ./libGL.so.1.2~ -shared -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/glapinoop.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glapi_x86.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -L/usr/X11R6-DRI/lib -lXext -lX11 -ldl -lc /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[5]: *** [libGL.so.1.2] Error 1 I've checked and Xext is not built after all. It must be already available. For that you need to make the 'lndir' stuff _before_ building so that the linker finds it (note the -L/usr/X11R6-DRI/lib in the command line). You forgot to CC the dri-devel ML. :) Already done;-) It would be nice if someone writes a little guide how to compile the Mach64 drivers. As soon as I get it working myself I will write a litte doc how I have done it. But I am not an expert in these things;-) I agree. Thanks, Michael Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock on mesa-4-0 and mesa-3-5 branches radeon drv?
Keith Whitwell wrote: Jorge Luis Williams wrote: Hello, I've run into what appears to be a dead-lock while running tessellation demo by David Blythe which is included in the Glut-3.7 source distribution (glut-3.7/progs/advanced/tes.c) I've been able to reproduce the problem on two different Intel Pentium III SMP machines (550, 850) both using radeon 64mb DDR cards. And I've been able to reproduce it in both the mesa-3-5 and mesa-4-0 branches. I've been unable to reproduce this. Maybe it's an SMP thing? Can you try booting one of your machines UP and try to reproduce? Actually, scratch that. I'm seeing the lockup now. Keith _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
On Tue, Dec 11, 2001 at 12:45:59PM +, Jose Fonseca wrote: Me neither. That's not a problem, just login as anonymous: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login Press enter for password and then cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I start to feel really stupid. I tryed it again and again I got errors. I followed your instructions and did: mkdir DRI-CVS cd DRI-CVS cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc ln -s xc XFree40 mkdir build cd build lndir -silent -ignorelinks ../XFree40 cd ~/DRI-CVS/build/xc/ make World World.LOG + gcc -o ./libGL.so.1.2~ -shared -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/glapinoop.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glapi_x86.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -L/usr/X11R6-DRI/lib -lXext -lX11 -ldl -lc /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[5]: *** [libGL.so.1.2] Error 1 I've checked and Xext is not built after all. It must be already available. For that you need to make the 'lndir' stuff _before_ building so that the linker finds it (note the -L/usr/X11R6-DRI/lib in the command line). How do I have to do that? I don't think that lndir'ing from /usr/X11R6 to /usr/X11R6-DRI will do any good. As soon as I managed to compile this I will write a short compilation guide because I think the compilation guide on the webpage is really outdated and there are probably a lot of people who want to get the mach64 working. Thanks for your help, Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock on mesa-4-0 and mesa-3-5 branches radeon drv?
Keith Whitwell wrote: Keith Whitwell wrote: Jorge Luis Williams wrote: Hello, I've run into what appears to be a dead-lock while running tessellation demo by David Blythe which is included in the Glut-3.7 source distribution (glut-3.7/progs/advanced/tes.c) I've been able to reproduce the problem on two different Intel Pentium III SMP machines (550, 850) both using radeon 64mb DDR cards. And I've been able to reproduce it in both the mesa-3-5 and mesa-4-0 branches. I've been unable to reproduce this. Maybe it's an SMP thing? Can you try booting one of your machines UP and try to reproduce? Actually, scratch that. I'm seeing the lockup now. I've committed a fix that should stop strips being emitted with 3 vertices. Keith _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] gl extensions on/off
Hi all Is it possible to turn on/off some particular GL extenstions in Mach64 driver? Is mesa.conf in any help here? I would like to play with texture-related extensions (probable, turning GL_ARB_multitextures off would solve my problems in celestia?) Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock on mesa-4-0 and mesa-3-5 branches radeondrv?
On Tue, 2001-12-11 at 09:06, Keith Whitwell wrote: Keith Whitwell wrote: Keith Whitwell wrote: Jorge Luis Williams wrote: Hello, I've run into what appears to be a dead-lock while running tessellation demo by David Blythe which is included in the Glut-3.7 source distribution (glut-3.7/progs/advanced/tes.c) I've been able to reproduce the problem on two different Intel Pentium III SMP machines (550, 850) both using radeon 64mb DDR cards. And I've been able to reproduce it in both the mesa-3-5 and mesa-4-0 branches. I've been unable to reproduce this. Maybe it's an SMP thing? Can you try booting one of your machines UP and try to reproduce? Actually, scratch that. I'm seeing the lockup now. I've committed a fix that should stop strips being emitted with 3 vertices. Keith Thanx Keith, Did you commit the change to the mesa-4-0 branch? Is the patch applicable to the mesa-3-5-branch? jOrGe W. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock on mesa-4-0 and mesa-3-5 branches radeon drv?
On Tue, Dec 11, 2001 at 01:27:12PM -0600, Jorge Luis Williams wrote: On Tue, 2001-12-11 at 09:06, Keith Whitwell wrote: Keith Whitwell wrote: Keith Whitwell wrote: Jorge Luis Williams wrote: Hello, I've run into what appears to be a dead-lock while running tessellation demo by David Blythe which is included in the Glut-3.7 source distribution (glut-3.7/progs/advanced/tes.c) I've been able to reproduce the problem on two different Intel Pentium III SMP machines (550, 850) both using radeon 64mb DDR cards. And I've been able to reproduce it in both the mesa-3-5 and mesa-4-0 branches. I've been unable to reproduce this. Maybe it's an SMP thing? Can you try booting one of your machines UP and try to reproduce? Actually, scratch that. I'm seeing the lockup now. I've committed a fix that should stop strips being emitted with 3 vertices. Keith Thanx Keith, Did you commit the change to the mesa-4-0 branch? Is the patch applicable to the mesa-3-5-branch? Keith committed it to the mesa-4-0-branch too. The mesa-3-5-branch is no longer being developed, everything has moved to the mesa-4-0-branch. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
El Mar 11 Dic 2001 15:51, Michael Thaler escribió: On Tue, Dec 11, 2001 at 12:45:59PM +, Jose Fonseca wrote: Me neither. That's not a problem, just login as anonymous: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login Press enter for password and then cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I start to feel really stupid. I tryed it again and again I got errors. I followed your instructions and did: mkdir DRI-CVS cd DRI-CVS cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc ln -s xc XFree40 mkdir build cd build lndir -silent -ignorelinks ../XFree40 cd ~/DRI-CVS/build/xc/ make World World.LOG + gcc -o ./libGL.so.1.2~ -shared -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/glapinoop.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glapi_x86.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -L/usr/X11R6-DRI/lib -lXext -lX11 -ldl -lc /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[5]: *** [libGL.so.1.2] Error 1 I've checked and Xext is not built after all. It must be already available. For that you need to make the 'lndir' stuff _before_ building so that the linker finds it (note the -L/usr/X11R6-DRI/lib in the command line). How do I have to do that? I don't think that lndir'ing from /usr/X11R6 to /usr/X11R6-DRI will do any good. Xext is not builded in the DRI compilation process. This is because the dri trunk (branch) is a stripped-out version of the XFree source code. This is because you MUST lndir your existing XFree distro files to the /usr/X11R6-DRI directory, where DRI compilation is trying to find the libs, as you can read in the line: ... -L/usr/X11R6-DRI/lib -lXext ... So, the first thing that you have to do is check if there is a libXext.so.* in your /usr/X11R6-DRI/lib. If you have that library there, I don't understand your problem, and in the other case, you know what to do now. As soon as I managed to compile this I will write a short compilation guide because I think the compilation guide on the webpage is really outdated and there are probably a lot of people who want to get the mach64 working. I think that compiling the mach64 branch is as difficult as compiling another branch or the trunk. All of them are stripped-source versions (I'm not sure now about the mach64-0-0-1, perhaps this was a complete X source tree ) and you need an starting XFree install. Best regards. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
Sergey V. Udaltsov wrote: Hi all Is it possible to turn on/off some particular GL extenstions in Mach64 driver? Is mesa.conf in any help here? I would like to play with texture-related extensions (probable, turning GL_ARB_multitextures off would solve my problems in celestia?) You can call the _mesa_enable/disable_extension() functions in the context-init code in the driver, like other DRI drivers do, to enable or disable various extensions. I'm not sure the mesa.conf stuff works anymore. -Brian _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] comments for agpgart.h needed
Hi folks,
could someone take 1 minute and run through agpgart.h,
just taking a look at the structs for the ioctls,
and add comments for which page fields are ADDRESSES, vs which
page fields are INDEXES/page-counts. My head's beginning to spin.
I'll narrow it down for ya:
typedef struct _agp_segment {
off_t pg_start; /* starting page to populate*/
size_t pg_count;/* number of pages */
typedef struct _agp_bind {
off_t pg_start; /* starting page to populate*/
typedef struct _agp_allocate {
size_t pg_count;/* number of pages */
[Is this really number of pages, or is it actually
amount of memory? If really number of pages,
then WHY ISNT IT AN INT?!!]
typedef struct _agp_info {
size_t pg_used; /* current pages used */
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
On Tue, Dec 11, 2001 at 07:28:54PM -0500, Leif Delgass wrote:
I think the point is (but I could be wrong) whether this is
user-configurable without recoding/recompiling anything, and it seems the
answer is no. The driver can enable/disable extensions for all apps using
the driver, or an app using GL through the driver can choose to enable or
disable extensions supported by the driver. So it's up to the application
(in this case celstia) to let the user configure which are used, right?
Make the enable/disable configurable by an environment variable, like
so:
if ( getenv( LIBGL_DISABLE_MULTITEXTURE ) ) {
gl_extensions_disable( ctx, GL_ARB_multitexture );
}
if ( getenv( LIBGL_ENABLE_TEXTURE_ENV_ADD ) ) {
gl_extensions_enable( ctx, GL_EXT_texture_env_add );
gl_extensions_enable( ctx, GL_ARB_texture_env_add );
}
Then, a user/app can just do something equivalent to:
export LIBGL_DISABLE_MULTITEXTURE=1
./my_app
And you're done. Variable naming left as an exercise for the user.
-- Gareth
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] gl extensions on/off
Make the enable/disable configurable by an environment variable, like
so:
if ( getenv( LIBGL_DISABLE_MULTITEXTURE ) ) {
gl_extensions_disable( ctx, GL_ARB_multitexture );
}
if ( getenv( LIBGL_ENABLE_TEXTURE_ENV_ADD ) ) {
gl_extensions_enable( ctx, GL_EXT_texture_env_add );
gl_extensions_enable( ctx, GL_ARB_texture_env_add );
}
Then, a user/app can just do something equivalent to:
export LIBGL_DISABLE_MULTITEXTURE=1
./my_app
And you're done. Variable naming left as an exercise for the user.
-- Gareth
Extensions do get detected by browsing a lengthy string.
Entry point adresses are retrived via a single GL API call.
Extensions constants and alikes simply get used and
will possibly get hounoured by the misc GL calls.
Therefore i would call this hide and reveal in the first row
when some intermediate layer does remove or add
the repsective strings or bases addresses.
Regards, Alex.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
