Re: [Dri-devel] mesa-4-1-branch
I'm trying to decide when to merge the mesa-41 branch into the trunk. People have reported a number of problems, but for the most part, they seem to be present in the trunk as well. At this time, the only differences between the trunk and branch server code is in the indirect GLX rendering code. I don't see how that could be responsible for the server lock-ups that have been reported. It might make sense to merge to the trunk soon so that there's one code base to focus on. Everyone seems to want the mesa-41 work to get into XFree86 4.3. What do people think? -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
On Mon, Nov 25, 2002 at 09:15:59AM -0700, Brian Paul wrote: It might make sense to merge to the trunk soon so that there's one code base to focus on. That seems like a very good call. I'd also like to get mesa-41 merged so that I can bring it into the texmem branch. Everyone seems to want the mesa-41 work to get into XFree86 4.3. For me, there are three things that would make for an idea 4.3 release in terms of DRI: 1. Mesa 5.0 2. Back-port the cube map support from the R200 driver to the R100 driver. (it's been around the middle of my todo list since you announced its availability!) 3. Some of the smaller GLX versioning / extension changes that we've discussed. At this point, I suspect that only 1 and part of 3 will happen. :( -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
On Mon, 2002-11-25 at 17:15, Brian Paul wrote: I'm trying to decide when to merge the mesa-41 branch into the trunk. People have reported a number of problems, but for the most part, they seem to be present in the trunk as well. At this time, the only differences between the trunk and branch server code is in the indirect GLX rendering code. I don't see how that could be responsible for the server lock-ups that have been reported. It might make sense to merge to the trunk soon so that there's one code base to focus on. Everyone seems to want the mesa-41 work to get into XFree86 4.3. My thoughts exactly, plus I'm waiting for the merge for the next version of my Debian packages, so I vote for it to happen ASAP. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
Michel Dänzer wrote: On Mon, 2002-11-25 at 17:15, Brian Paul wrote: I'm trying to decide when to merge the mesa-41 branch into the trunk. People have reported a number of problems, but for the most part, they seem to be present in the trunk as well. At this time, the only differences between the trunk and branch server code is in the indirect GLX rendering code. I don't see how that could be responsible for the server lock-ups that have been reported. It might make sense to merge to the trunk soon so that there's one code base to focus on. Everyone seems to want the mesa-41 work to get into XFree86 4.3. My thoughts exactly, plus I'm waiting for the merge for the next version of my Debian packages, so I vote for it to happen ASAP. OK, I'll tag the trunk with a pre-merge tag and start the merge soon. Please hold off on committing changes to the DRI think for a while. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
Brian Paul wrote: Michel Dänzer wrote: On Mon, 2002-11-25 at 17:15, Brian Paul wrote: I'm trying to decide when to merge the mesa-41 branch into the trunk. People have reported a number of problems, but for the most part, they seem to be present in the trunk as well. At this time, the only differences between the trunk and branch server code is in the indirect GLX rendering code. I don't see how that could be responsible for the server lock-ups that have been reported. It might make sense to merge to the trunk soon so that there's one code base to focus on. Everyone seems to want the mesa-41 work to get into XFree86 4.3. My thoughts exactly, plus I'm waiting for the merge for the next version of my Debian packages, so I vote for it to happen ASAP. OK, I'll tag the trunk with a pre-merge tag and start the merge soon. Please hold off on committing changes to the DRI think for a while. Err, DRI trunk. -Brian --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
On Mon, 25 Nov 2002, Brian Paul wrote: It might make sense to merge to the trunk soon so that there's one code base to focus on. Everyone seems to want the mesa-41 work to get into XFree86 4.3. What do people think? I say go for it. If we can get it into the trunk then it will be likely more people will try it. In reality - more testing is the only way to ensure that it is golden and the more bug reports that are generated, the better the chances of narrowing down the issues involved (worse case scenerio there of course). -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
I'll be checking in the merge soon. I'm just doing a second build to double-check everything. Testing is going good so far. -Brian --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
Brian Paul wrote: I'll be checking in the merge soon. I'm just doing a second build to double-check everything. Testing is going good so far. OK, the merge is done. -Brian --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
On Sat, 23 Nov 2002 19:47:35 -0500 Garry Reisky [EMAIL PROTECTED] wrote: Switching resolutions in quake 3 based games seems to cause some problems. Also switching from fullscreen to windowed mode causes the same effect. I've tried q3a, wolfenstein, ut, fakk2. They all do the same thing for me. Screenshots http://chronoworx.dnsalias.org/~greisky/mesa-4-1-branch/ Thats the same effect I see. Im on a radeon 9000, CVS 'head'? (whatever you get if you dont specify a branch) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch: Which is the right xf86PciData.c version?
That file is symlinked from xf86ScanPci.c, it shouldn't exist. Do a clean checkout. Alan. On Fri, Nov 22, 2002 at 02:37:35PM +0100, Dieter Nützel wrote: M xc/programs/Xserver/hw/xfree86/scanpci/xf86PciData.c But latest version. The current is much older. /* $XFree86: xc/programs/Xserver/hw/xfree86/scanpci/xf86ScanPci.c,v 1.12 2002/07/15 20:46:0 4 dawes Exp $ */ /* * Display the Subsystem Vendor Id and Subsystem Id in order to identify * the cards installed in this computer * * Copyright 1995-2002 by The XFree86 Project, Inc. * * A lot of this comes from Robin Cutshaw's scanpci * */ Merge problem? -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
On Mit, 2002-11-20 at 16:56, Adam K Kirchhoff wrote: On 20 Nov 2002, Michel [ISO-8859-1] Dänzer wrote: On Mit, 2002-11-20 at 00:38, Adam K Kirchhoff wrote: heretic2 has some problems, but they also show up in the trunk :-) Basically, any sort of flashing (like if my character throws a fireball), causes a huge drop in the framerate. It uses the Quake 2 engine, right? As has been discussed here before, it has an inefficient implementation of dynamic lighting with multitexturing. Try set gl_ext_multitexture 0 or set gl_dynamic 0 set gl_ext_multitexture 0 didn't work. I forgot to try gl_dynamic before I left for work. I'll hopefully be able to give it a whirl tonight. You've let me know in private that it does the trick. set gl_ext_multitexture 0 might have required a restart, of the renderer at least. I've also given it a shot under FreeBSD. The results with GL applications (both native and linux through the binary compatability layer) are the same. *However* the X server itself seems rather unstable. At first, I couldn't figure it out; everytime I went to start X, the server would start up for a split second and then die. After some experimenting, I discovered that the problem was gkrellm, which was in my .xinitrc. More specifically, it seems to be any gtk-2.0 application. In addition, when I switched to kde3 as my window manager, the same thing happened. So, I can run enlightenment without any problem. However, if I start any gtk-2.0 apps, or kde3 apps (maybe it's qt?), the X server will die :-) There have been reports of crashes in the TrueType font renderers, could it be that? Hmmm... I guess that's a possibility. I tried another experiment this morning and the results kind of surprised me. If I start X with xinit /usr/X11R6/bin/xterm and then launch metacity from the xterm, the server will crash. If, however, I start X with xinit /usr/X11R6/bin/metacity, the server starts up and runs fine. Weird. I'm including the last 60 lines of /var/log/XFree86.0.log. You'll notice that there's an unresolved symbol in libGLcore.a Yes, and you'll also notice the disclaimer before the crash. :) AFAICS there are no OpenGL apps involved so I doubt the unresolved symbol is relevant. A backtrace (with more information than all '??' :) would be interesting. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
On Mit, 2002-11-20 at 22:04, Martin Spott wrote: Brian wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc Do a CVS update again in case you didn't get my latest check-ins. I just ran FlightGear with this branch (instead of employing binary snapshots) on my Radeon7500. Everything is quite fast, the colours look perfect, the previously known feature of everything appearing too dark has gone ! Great, unfortunately lighting is still broken with pulsar -light, so that doesn't seem to be the same problem. The airplane's control panel looks a bit strange - but this might be a different subject. Unfortunately the X server crashes before I get an opportunity to create a screenshot ;-) It seemed to run longer if not indefinitely with some debugging output enabled... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
Hi! I've done some more testing on the mesa-4-1-branch (checked out and compiled yesterday) All in all everything runs quite nicely and stable. I successfully tested: -quake (quakeforge-0.5.2): works, but quite sluggish, especially when there are lots of light effects -quake2 (quakeIIforge 0.1): works stable and fast, but only with dynamic lighting disabled, as suggested earlier with dynamic lighting and multitexturing it's hardly playable -quake3 (1.32): nice, fast and stable ;-) -return to castle wolfenstein (1.3): now works stable for me, as far as I can tell, but performance is a bit weird: it's fast most of the time, but sometime framerates drop to almost 0 for a little while, mostly when opening doors, entering new rooms etc. (but that could also be related to low system ram, i only got 256 MB, and I'm playing at max. details) -tuxracer -tuxkart -gltron -glxgears ;-) -half-life (using winex): seemed stable, but not very fast. switching on your flashlight for example hugely affects performance (goes down to ~5fps or s.th.) Apps that I had problems with: -flightgear: after some left- and right-clicking in the fgfs-window my keyboard wasn't responsive anymore. This happened once only, but i didn't really test fgfs, as i don't have a clue about how to play it :) General prolems/issues: Changing resolution in wolfenstein, q3a, q2 etc. does not work. It will not crash the box, but give garbage pictures on the screen. Software-TCL produces flickering/missing textures in wolfenstein (q3a is fine) I did the testing with a r200 (8500 QL), amd athlon XP, via kt266a-mainboard, using debian-unstable and linux-2.4.20-rc1. It seems that now AGP4x is also fairly stable for me, but I have to do some longer testing do definitely confirm this, most of the testing was done at AGP1x. Fastwrites are disabled, pageflipping is enabled Thanks for the nice work, Stefan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
I just ran FlightGear with this branch (instead of employing binary snapshots) on my Radeon7500. Everything is quite fast, the colours look perfect, the previously known feature of everything appearing too dark has gone ! Hmmm, today I had to realize that this is still dependend on the direction you look at. But still better than before, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
On Mit, 2002-11-20 at 00:38, Adam K Kirchhoff wrote: heretic2 has some problems, but they also show up in the trunk :-) Basically, any sort of flashing (like if my character throws a fireball), causes a huge drop in the framerate. It uses the Quake 2 engine, right? As has been discussed here before, it has an inefficient implementation of dynamic lighting with multitexturing. Try set gl_ext_multitexture 0 or set gl_dynamic 0 I've also given it a shot under FreeBSD. The results with GL applications (both native and linux through the binary compatability layer) are the same. *However* the X server itself seems rather unstable. At first, I couldn't figure it out; everytime I went to start X, the server would start up for a split second and then die. After some experimenting, I discovered that the problem was gkrellm, which was in my .xinitrc. More specifically, it seems to be any gtk-2.0 application. In addition, when I switched to kde3 as my window manager, the same thing happened. So, I can run enlightenment without any problem. However, if I start any gtk-2.0 apps, or kde3 apps (maybe it's qt?), the X server will die :-) There have been reports of crashes in the TrueType font renderers, could it be that? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
On 20 Nov 2002, Michel [ISO-8859-1] Dänzer wrote: On Mit, 2002-11-20 at 00:38, Adam K Kirchhoff wrote: heretic2 has some problems, but they also show up in the trunk :-) Basically, any sort of flashing (like if my character throws a fireball), causes a huge drop in the framerate. It uses the Quake 2 engine, right? As has been discussed here before, it has an inefficient implementation of dynamic lighting with multitexturing. Try set gl_ext_multitexture 0 or set gl_dynamic 0 set gl_ext_multitexture 0 didn't work. I forgot to try gl_dynamic before I left for work. I'll hopefully be able to give it a whirl tonight. I've also given it a shot under FreeBSD. The results with GL applications (both native and linux through the binary compatability layer) are the same. *However* the X server itself seems rather unstable. At first, I couldn't figure it out; everytime I went to start X, the server would start up for a split second and then die. After some experimenting, I discovered that the problem was gkrellm, which was in my .xinitrc. More specifically, it seems to be any gtk-2.0 application. In addition, when I switched to kde3 as my window manager, the same thing happened. So, I can run enlightenment without any problem. However, if I start any gtk-2.0 apps, or kde3 apps (maybe it's qt?), the X server will die :-) There have been reports of crashes in the TrueType font renderers, could it be that? Hmmm... I guess that's a possibility. I tried another experiment this morning and the results kind of surprised me. If I start X with xinit /usr/X11R6/bin/xterm and then launch metacity from the xterm, the server will crash. If, however, I start X with xinit /usr/X11R6/bin/metacity, the server starts up and runs fine. I'm including the last 60 lines of /var/log/XFree86.0.log. You'll notice that there's an unresolved symbol in libGLcore.a Adam --- (II) RADEON(0): Acceleration enabled (==) RADEON(0): Backing store disabled (II) RADEON(0): Using hardware cursor (scanline 1442) (II) RADEON(0): Largest offscreen area available: 1920 x 6748 (**) Option dpms off (**) RADEON(0): DPMS enabled (II) RADEON(0): X context handle = 0x0001 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 5 (II) RADEON(0): [drm] Initialized kernel agp heap manager, 62914560 (II) RADEON(0): Direct rendering enabled Symbol xf86strncat from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (**) Option Protocol Auto (**) Mouse1: Protocol: Auto (**) Option CorePointer (**) Mouse1: Core Pointer (**) Option Device /dev/sysmouse (**) Option Buttons 5 (**) Option ZAxisMapping 4 5 (**) Mouse1: ZAxisMapping: buttons 4 and 5 (**) Mouse1: Buttons: 5 (II) Keyboard Keyboard1 handled by legacy driver (II) XINPUT: Adding extended input device Mouse1 (type: MOUSE) (II) Mouse1: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse1: SetupAuto: protocol is SysMouse (**) Option BaudRate 1200 Warning: font renderer for .pfa registered more than once Warning: font renderer for .pfb registered more than once GetModeLine - scrn: 0 clock: 157500 GetModeLine - hdsp: 1280 hbeg: 1344 hend: 1504 httl: 1728 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1072 flags: 5 GetModeLine - scrn: 0 clock: 157500 GetModeLine - hdsp: 1280 hbeg: 1344 hend: 1504 httl: 1728 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1072 flags: 5 *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. -- --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED]
Re: [Dri-devel] Mesa-4-1-branch
Brian wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc Do a CVS update again in case you didn't get my latest check-ins. I just ran FlightGear with this branch (instead of employing binary snapshots) on my Radeon7500. Everything is quite fast, the colours look perfect, the previously known feature of everything appearing too dark has gone ! The airplane's control panel looks a bit strange - but this might be a different subject. Unfortunately the X server crashes before I get an opportunity to create a screenshot ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch (and trunk)
Heh.. I actually noticed it a couple days ago on the texmem branch, but I figured that I was doing something odd/wrong. Guess not :-) Adam On Tue, 19 Nov 2002, Urs Schroffenegger wrote: Well, I didn't find what's wrong, but i encountered exactly the same thing at exactly the same point (blabla/xfree/imput/) from yesterday's cvs grabbed from the trunk (as explained in the compilation guide); and i found the same kind of message on dri-users dated from nov. 17th, but also unanswered i'm on a suse 7.2, gcc 2.95.3, and a 2.4.19 kernel, hope this helps a bit further pinning down the problem... urs Adam K Kirchhoff wrote: SNIP make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 SNIP --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian Still no go. Dies at the same place with the same error. Adam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
Adam K Kirchhoff wrote: On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian Still no go. Dies at the same place with the same error. Look at xc/programs/Xserver/hw/xfree86/Imakefile, near line 80. Do you see this: #if BuildXInputExt defined(XInputDrivers) INPUTDIR = input #endif David recently checked in a fix (check for XInputDrivers) for exactly this problem. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
Alan Hourihane wrote: On Tue, Nov 19, 2002 at 01:04:54PM -0500, Adam K Kirchhoff wrote: On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian Still no go. Dies at the same place with the same error. Try updating xc/config/host.def. David fixed a build problem here. I just checked in this change to the mesa41 branch. I missed it before. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
Hold on a sec. I've got too many different branches of the DRI on my machine (the texmem branch, the mesa-4.1 branch, and the trunk) so now I'm beginning to second guess what I've updated and what I haven't. I'm gonna clean everything off and do a fresh pull of the mesa-4.1 branch. Adam On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian Still no go. Dies at the same place with the same error. Look at xc/programs/Xserver/hw/xfree86/Imakefile, near line 80. Do you see this: #if BuildXInputExt defined(XInputDrivers) INPUTDIR = input #endif David recently checked in a fix (check for XInputDrivers) for exactly this problem. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
Adam K Kirchhoff wrote: On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian Still no go. Dies at the same place with the same error. I just checked it out (2h ago), and it compiled fine. It also seems to run quite nicely. No crashes with wolfenstein or q3a, but I only tested quickly. you could try to erase your local cvs-copy and check it out completely, maybe that helps? btw: the flickering/missing textures with software tcl issue is still present after the merge from trunk, so it's probably an issue with the mesa-4.1 respectively mesa-5.0 code. Not that it really matters a lot, though... regards Stefan Adam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
Adam K Kirchhoff wrote: Alright, after clearing out my local copy of the mesa-4.1 branch, I pulled everything again and was able to build that branch without any problems. I've done some basic testing so far. This is on a dual proc, 1ghz., PIII. Via chipset. 2x AGP, 64 meg aperature. 512 megs of RAM. Radeon 8500 (128 meg version) It looks like I'm seeing some speedups across the board. Nothing huge, but glxgears is reporting an extra 300 fps or so and most games that I've tried so far just feel smoother. Quake3Arena dies when it goes to load a level to play: Loading vm file vm/ui.qvm. VM file ui compiled to 594408 bytes of code ui loaded in 1963008 bytes on the hunk 35 arenas parsed 32 bots parsed Loading vm file vm/cgame.qvm. VM file cgame compiled to 786818 bytes of code cgame loaded in 5380768 bytes on the hunk drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) UT and Rune run just fine. gltron displays/plays fine, as does tuxkart. I haven't tried tuxracer yet. heretic2 has some problems, but they also show up in the trunk :-) Basically, any sort of flashing (like if my character throws a fireball), causes a huge drop in the framerate. I've also given it a shot under FreeBSD. The results with GL applications (both native and linux through the binary compatability layer) are the same. *However* the X server itself seems rather unstable. At first, I couldn't figure it out; everytime I went to start X, the server would start up for a split second and then die. After some experimenting, I discovered that the problem was gkrellm, which was in my .xinitrc. More specifically, it seems to be any gtk-2.0 application. In addition, when I switched to kde3 as my window manager, the same thing happened. So, I can run enlightenment without any problem. However, if I start any gtk-2.0 apps, or kde3 apps (maybe it's qt?), the X server will die :-) I'll continue testing when I have the chance. Thanks for testing! I'll try to look into the Q3A failure this week. I wouldn't expect any speed-ups from the 5.0 Mesa code. But I'm sure nobody will complain if that's the case. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: Alright, after clearing out my local copy of the mesa-4.1 branch, I pulled everything again and was able to build that branch without any problems. I've done some basic testing so far. This is on a dual proc, 1ghz., PIII. Via chipset. 2x AGP, 64 meg aperature. 512 megs of RAM. Radeon 8500 (128 meg version) It looks like I'm seeing some speedups across the board. Nothing huge, but glxgears is reporting an extra 300 fps or so and most games that I've tried so far just feel smoother. Quake3Arena dies when it goes to load a level to play: Loading vm file vm/ui.qvm. VM file ui compiled to 594408 bytes of code ui loaded in 1963008 bytes on the hunk 35 arenas parsed 32 bots parsed Loading vm file vm/cgame.qvm. VM file cgame compiled to 786818 bytes of code cgame loaded in 5380768 bytes on the hunk drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) UT and Rune run just fine. gltron displays/plays fine, as does tuxkart. I haven't tried tuxracer yet. heretic2 has some problems, but they also show up in the trunk :-) Basically, any sort of flashing (like if my character throws a fireball), causes a huge drop in the framerate. I've also given it a shot under FreeBSD. The results with GL applications (both native and linux through the binary compatability layer) are the same. *However* the X server itself seems rather unstable. At first, I couldn't figure it out; everytime I went to start X, the server would start up for a split second and then die. After some experimenting, I discovered that the problem was gkrellm, which was in my .xinitrc. More specifically, it seems to be any gtk-2.0 application. In addition, when I switched to kde3 as my window manager, the same thing happened. So, I can run enlightenment without any problem. However, if I start any gtk-2.0 apps, or kde3 apps (maybe it's qt?), the X server will die :-) I'll continue testing when I have the chance. Thanks for testing! I'll try to look into the Q3A failure this week. I wouldn't expect any speed-ups from the 5.0 Mesa code. But I'm sure nobody will complain if that's the case. Let's put it this way... The speedups certainly aren't so dramatic that they can't be explained by other factors (less processes running in the background, for example), which very well may be the case. Adam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
