Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland [EMAIL PROTECTED] To: Felix Khling [EMAIL PROTECTED] Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), and have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16-front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters wrong, leading to an incomprehensible display (even after quitting). Thanks, Steve The code i'm running is also about 2-3 days old. I've got the same Hardware (T23 - supersavage IX/SDR). What he means with corruption occurs when changing the display mode on-the-fly. Then the screen is corrupted. Switching back to the old resolution normalizes the screen again. This won't happen when starting initialy with the new setting. So setting XF86Config to a new res and restart X everything is fine. Acceleration stuff : -only works in 16 bpp (2d/3d) -in 24bpp there is no 2d nor any 3d accelleration. -2D accell worked with tims driver on 24bpp. Tuxracer is still fine. But blender didn't change. The screen is clean but all fonts are corrupted. It seems to me that the fonts in blender are also gl, but that's just an assumption. Besides that you did a _GREAT_ work, and the driver speeded up in the last 2-3 Months as gar as i can see. With savage-2-0-0 i had about 270 fps in the beginning of working dri-support for my chip. Than it got from 325 to 378. And with the last code in the savage branch it reached 408. That stayed with the HEAD Branch since then. regards marco --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
On Thu, 11 Mar 2004 20:13:44 +0100 Marco Strack [EMAIL PROTECTED] wrote: [snip] Tuxracer is still fine. But blender didn't change. The screen is clean but all fonts are corrupted. It seems to me that the fonts in blender are also gl, but that's just an assumption. The font corruption should be solved since about last weekend. Can you try with current CVS. If it's still broken then maybe the SuperSavage uses a different tiling format for certain texel formats. Right now the driver assumes the same formats on SuperSavage as on ProSavage. If fonts are still broken then the current code makes it quite easy to experiment with tiling formats. You just have to change a few numbers in the beginning of savagetex.c. I could guide you through them so you can find the right numbers for the SuperSavage. Besides that you did a _GREAT_ work, and the driver speeded up in the last 2-3 Months as gar as i can see. With savage-2-0-0 i had about 270 fps in the beginning of working dri-support for my chip. Than it got from 325 to 378. And with the last code in the savage branch it reached 408. That stayed with the HEAD Branch since then. Not sure where that comes from. The 3D driver changes that may have had a positive effect on the performance were done on the Mesa trunk: - reorganized state management (I could hardly measure any speedup) - use smaller vertex formats where possible - more efficient texture upload (has no effect on glxgears) Did you change any compiler options? Changing optimizations from -O0 to -O3 gave me a good speed boost. regards marco Felix --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
My apologies for being horribly slow to respond. The mode switching problem occurs with bpp=24 (bpp=32 didn't work at all for me). Hardware is SuperSavage/IXC SDR (ThinkPad T23). I do get the message: (==) SAVAGE(0): Using video BIOS to set modes But I get this regardless of whether I have the UseBIOS option set or not in XF86Config. At this point the display always seems to be corrupted (bad mode) if I select 24 bpp (before it worked fine until I started tuxracer). The corrupted display shows the right colors, but the pixel arrangement is off. What should be the vertical left/right border of the screen is actually at a 30 degree angle to the horizontal, wrapping around from left to right (goes down and to the right). Moving the mouse down makes the pixels representing the pointer go down and to the right. Moving the mouse to the right makes them go up and to the right. I have also noticed a problem with loading the kernel driver. Even after I added: /sbin/modprobe agpgart /sbin/modprobe savage to /etc/rc.d/rc.local, the X server did not start with DRI enabled. The reason seems to be that some time is needed between the 'modprobe agpgart' and the 'modprobe savage'. Changing rc.local to: /sbin/modprobe agpgart sleep 1 /sbin/modprobe savage sleep 1 Solved the problem and now I get the message kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: SuperSavage IX/C SDR on bootup. HOWEVER, I noticed general system instability (random lockups) when operating in the original case, that is when both agpgart.o and savage.o were loaded, but savage not properly initialized. Thanks, Steve On Fri, 2004-02-27 at 15:21, Alex Deucher wrote: -- Felix Khling [EMAIL PROTECTED] wrote: Forwarding to dri-devel. Some of this (mode switching problem) looks like a 2D issue. Alex? I'll have to double check, but I don't recall having any problems with mode switching in tuxracer last time I played with it. Steve, what chip are you running on? bios or non-bios mode setting? it also might be an issue with the backbuffer overwriting the front buffer. see below. I don't know why drawpix to the backbuffer works for me but not for you. I'll look into this some time. But it's no priority right now. Hmm, I was just wondering if you have enough memory for 3D in 32bpp mode with 1400x1050. Front, back and depth buffers need a bit more than 16 MB in this mode. If your chip uses shared memory you'd have to reserve 32MB of shared memory for it to work. One of these days, maybe this weekend, I'll put a quick check in the buffer allocation code in savage_accel.c to make sure there is enough memory for 3D in the current mode/depth. OT I haven't really been testing the trunk to much lately, as I've been messing around with duoview support. I've just about got it working. I can set up the second controller and dot clock, I just can't get it to produce a signal. it's driving me nuts.../OT Alex Regards, Felix Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland [EMAIL PROTECTED] To: Felix Khling [EMAIL PROTECTED] Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), and have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16-front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters wrong, leading to an incomprehensible display (even after quitting). Thanks, Steve On Tue, 2004-02-24 at 07:13, Felix Khling wrote: On Mon, 23 Feb 2004 14:18:53 -0600 Steve Holland [EMAIL PROTECTED] wrote: [snip] __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
--- Steve Holland [EMAIL PROTECTED] wrote: My apologies for being horribly slow to respond. The mode switching problem occurs with bpp=24 (bpp=32 didn't work at all for me). Hardware is SuperSavage/IXC SDR (ThinkPad T23). I do get the message: (==) SAVAGE(0): Using video BIOS to set modes But I get this regardless of whether I have the UseBIOS option set or not in XF86Config. At this point the display always seems to be corrupted (bad mode) if I select 24 bpp (before it worked fine until I started tuxracer). The corrupted display shows the right colors, but the pixel arrangement is off. What should be the vertical left/right border of the screen is actually at a 30 degree angle to the horizontal, wrapping around from left to right (goes down and to the right). Moving the mouse down makes the pixels representing the pointer go down and to the right. Moving the mouse to the right makes them go up and to the right. I have also noticed a problem with loading the kernel driver. Even after I added: /sbin/modprobe agpgart /sbin/modprobe savage to /etc/rc.d/rc.local, the X server did not start with DRI enabled. The reason seems to be that some time is needed between the 'modprobe agpgart' and the 'modprobe savage'. Changing rc.local to: /sbin/modprobe agpgart sleep 1 /sbin/modprobe savage sleep 1 Solved the problem and now I get the message kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: SuperSavage IX/C SDR on bootup. HOWEVER, I noticed general system instability (random lockups) when operating in the original case, that is when both agpgart.o and savage.o were loaded, but savage not properly initialized. Steve, If you haven't already please try again with the DRI/mesa trunks rather than savage-2-0-0-branch. There have been quite a few updates since the branch was merged. Also how much videoram does your card have? You will need almost 17 MB for 1400x1050x24bpp (24bpp is really 32 bpp as far as the driver is concerned). The new driver disables the DRI if there is not enough ram. Before my changes to check available videoram, the front/back/depth buffers would be arbitrarily allocated and if you only have 16MB of video ram, the back buffer would overflow into the front buffer. Alex Thanks, Steve On Fri, 2004-02-27 at 15:21, Alex Deucher wrote: -- Felix Khling [EMAIL PROTECTED] wrote: Forwarding to dri-devel. Some of this (mode switching problem) looks like a 2D issue. Alex? I'll have to double check, but I don't recall having any problems with mode switching in tuxracer last time I played with it. Steve, what chip are you running on? bios or non-bios mode setting? it also might be an issue with the backbuffer overwriting the front buffer. see below. I don't know why drawpix to the backbuffer works for me but not for you. I'll look into this some time. But it's no priority right now. Hmm, I was just wondering if you have enough memory for 3D in 32bpp mode with 1400x1050. Front, back and depth buffers need a bit more than 16 MB in this mode. If your chip uses shared memory you'd have to reserve 32MB of shared memory for it to work. One of these days, maybe this weekend, I'll put a quick check in the buffer allocation code in savage_accel.c to make sure there is enough memory for 3D in the current mode/depth. OT I haven't really been testing the trunk to much lately, as I've been messing around with duoview support. I've just about got it working. I can set up the second controller and dot clock, I just can't get it to produce a signal. it's driving me nuts.../OT Alex Regards, Felix Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland [EMAIL PROTECTED] To: Felix Khling [EMAIL PROTECTED] Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), and have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16-front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters wrong, leading to an incomprehensible display (even after quitting). Thanks, Steve On Tue, 2004-02-24 at 07:13, Felix Khling wrote: On Mon, 23 Feb 2004 14:18:53 -0600 Steve Holland [EMAIL PROTECTED] wrote: [snip] __ Do you Yahoo!? Yahoo! Search - Find what youre looking
Fw: Re: [Dri-devel] savage-2-0-0 test notes
Forwarding to dri-devel. Some of this (mode switching problem) looks like a 2D issue. Alex? I don't know why drawpix to the backbuffer works for me but not for you. I'll look into this some time. But it's no priority right now. Hmm, I was just wondering if you have enough memory for 3D in 32bpp mode with 1400x1050. Front, back and depth buffers need a bit more than 16 MB in this mode. If your chip uses shared memory you'd have to reserve 32MB of shared memory for it to work. Regards, Felix Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland [EMAIL PROTECTED] To: Felix Kühling [EMAIL PROTECTED] Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), and have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16-front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters wrong, leading to an incomprehensible display (even after quitting). Thanks, Steve On Tue, 2004-02-24 at 07:13, Felix Kühling wrote: On Mon, 23 Feb 2004 14:18:53 -0600 Steve Holland [EMAIL PROTECTED] wrote: [snip] --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Wed, 25 Feb 2004 09:23:16 -0700 Brian Paul [EMAIL PROTECTED] wrote: Felix Kühling wrote: [snip] I don't have tuxracer handy - I'll have to download it later. Do you happen to know which fog mode is used, and if the GL_FOG_HINT is set? I don't know which fog mode it uses. The Savage driver can only do vertex for ATM. I tried --fog-fastest and --fog-nicest in flightgear, both looked the same. I think I've fixed the problem. Update from Mesa CVS and try again. Yes, it works. Thanks. I'll commit the _tnl_allow_pixel/vertex_fog thing to the savage driver now. -Brian Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
Felix Kühling wrote: On Wed, 25 Feb 2004 09:23:16 -0700 Brian Paul [EMAIL PROTECTED] wrote: Felix Kühling wrote: [snip] I don't have tuxracer handy - I'll have to download it later. Do you happen to know which fog mode is used, and if the GL_FOG_HINT is set? I don't know which fog mode it uses. The Savage driver can only do vertex for ATM. I tried --fog-fastest and --fog-nicest in flightgear, both looked the same. I think I've fixed the problem. Update from Mesa CVS and try again. Yes, it works. Thanks. I'll commit the _tnl_allow_pixel/vertex_fog thing to the savage driver now. And I've updated the other DRI drivers. -Brian --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Mon, 23 Feb 2004 14:18:53 -0600 Steve Holland [EMAIL PROTECTED] wrote: Felix Kühling wrote: If the span stuff is all that's needed then it should be working. Incidentally I tested the drawpix demo yesterday. It worked ok as long as it drew to the back buffer. Drawing to the front buffer was broken, though. It started scribbling all over the screen. Maybe that's all that needs to be fixed. drawpix does NOT work for me when drawing to the back buffer (just black window, no scribbling). Drawing to the front buffer causes scribbling all over the screen. (SuperSavage IX/C SDR) I'm at 16bit 1400x1050. Strange. It works on ProSavageDDR and SavageIX here. But I tested with the new driver on the DRI/Mesa trunk. Could you try updating? (question of # of args to do_unmap) Must be something about how fedora patches their kernels. I didn't need this to build on a stock 2.4.21 kernel from kernel.org. Unless you know a safe way to detect a fedora-patched kernel at build time I'm not going to change it in CVS. But it's good to know in case others stumble over the same problem. How about #ifdef DO_MUNMAP_4_ARGS (this is set by Makefile.linux)? Ok. I'll use that macro then. - The 'make install' does not create TLS versions of libGL, so it is necessary under Fedora Core 1 to remove the copies of libGL in /usr/X11R6/lib/tls/ to prevent using the old libGL (glxinfo reports indirect rendering even with DRI enabled). This should be added to the new building guide (see below) if it's not there already. It's not in there right now. Might it be better to have the 'make install' do this, or remove/rename the tls versions? I'm not an expert for this kind of problem. Personally I think this would be too much intelligence for a make install. As this is not a savage-specific problem, what do other developers think? Thanks again, Steve Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
Gregory Davis wrote: On Sunday 22 February 2004 03:15 pm, Steve Holland wrote: I downloaded and tested the savage-2-0-0 branch yesterday. This is on an IBM ThinkPad T23 with a SuperSavage IX/C SDR. It works really well! Congratulations and thanks, guys! A few notes (savage-2-0-0 branch 2/21/04): - tuxracer runs great! Well, glFog() seems to be screwed up for me, 2/23/04 from trunk. I built according to the new build instructions and pointed to the Mesa cvs tree in host.def. However, tuxracer foreground stuff is all white when fog is turned on (sometimes I can see a little texture, so its almost like the fog factor is set way too high). Tuxracer is linked against the current X11R6 GL and GLU libraries. The code is in src/fog.c of the tuxracer-0.61 tarball. The chip is a Savage4 on a creative labs motherboard: ... (II) SAVAGE(0): [agp] Mode 0x1b000213 [AGP 0x10b9/0x1647; Card 0x5333/0x8a22] ... Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I checked in this change to the r200 driver as an experiment. If it works there then the other drivers should be updated too. -Brian --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Tue, 24 Feb 2004 09:56:29 -0700 Brian Paul [EMAIL PROTECTED] wrote: Gregory Davis wrote: [snip] Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I just tried this. Now there is no fog at all in tuxracer. I checked in this change to the r200 driver as an experiment. If it works there then the other drivers should be updated too. -Brian Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Tue, 24 Feb 2004 19:33:16 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Tue, 24 Feb 2004 09:56:29 -0700 Brian Paul [EMAIL PROTECTED] wrote: Gregory Davis wrote: [snip] Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I just tried this. Now there is no fog at all in tuxracer. But fog looks ok in flightgear now. So this fix is ok but there's probably another problem with fog in tuxracer. With Mesa 5.0 (on the savage-2-0-0-branch) fog was ok in tuxracer too. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
Felix Kühling wrote: On Tue, 24 Feb 2004 19:33:16 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Tue, 24 Feb 2004 09:56:29 -0700 Brian Paul [EMAIL PROTECTED] wrote: Gregory Davis wrote: [snip] Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I just tried this. Now there is no fog at all in tuxracer. But fog looks ok in flightgear now. So this fix is ok but there's probably another problem with fog in tuxracer. With Mesa 5.0 (on the savage-2-0-0-branch) fog was ok in tuxracer too. I don't have tuxracer handy - I'll have to download it later. Do you happen to know which fog mode is used, and if the GL_FOG_HINT is set? -Brian --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Tue, Feb 24, 2004 at 02:01:39PM -0700, Brian Paul wrote: Felix Kühling wrote: On Tue, 24 Feb 2004 19:33:16 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Tue, 24 Feb 2004 09:56:29 -0700 Brian Paul [EMAIL PROTECTED] wrote: Gregory Davis wrote: [snip] Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I just tried this. Now there is no fog at all in tuxracer. But fog looks ok in flightgear now. So this fix is ok but there's probably another problem with fog in tuxracer. With Mesa 5.0 (on the savage-2-0-0-branch) fog was ok in tuxracer too. I don't have tuxracer handy - I'll have to download it later. Do you happen to know which fog mode is used, and if the GL_FOG_HINT is set? Brian, It uses NICEST. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Tue, 24 Feb 2004 14:01:39 -0700 Brian Paul [EMAIL PROTECTED] wrote: Felix Kühling wrote: On Tue, 24 Feb 2004 19:33:16 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Tue, 24 Feb 2004 09:56:29 -0700 Brian Paul [EMAIL PROTECTED] wrote: Gregory Davis wrote: [snip] Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I just tried this. Now there is no fog at all in tuxracer. But fog looks ok in flightgear now. So this fix is ok but there's probably another problem with fog in tuxracer. With Mesa 5.0 (on the savage-2-0-0-branch) fog was ok in tuxracer too. I don't have tuxracer handy - I'll have to download it later. Do you happen to know which fog mode is used, and if the GL_FOG_HINT is set? I don't know which fog mode it uses. The Savage driver can only do vertex for ATM. I tried --fog-fastest and --fog-nicest in flightgear, both looked the same. -Brian Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] savage-2-0-0 test notes
I downloaded and tested the savage-2-0-0 branch yesterday. This is on an IBM ThinkPad T23 with a SuperSavage IX/C SDR. It works really well! Congratulations and thanks, guys! A few notes (savage-2-0-0 branch 2/21/04): - tuxracer runs great! - glDrawPixels doesn't seem to work (may be copying pixels to wrong place -- there were hints of corruption elsewhere) - glutBitmapCharacter doesn't seem to work either (calls glBitmap) - Polygon and line drawing work fine. - agpgart must be insmod'd before starting the X server. - something (insmod, I think) gives a system log message kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: SuperSavage IX/C SDR even though this is actually savage 2.0.0 branch - On my kernel (fedora core 1 2.4.22-1.2129.nptl) I had to change in savage_drv.c: #if 0 (LINUX_VERSION_CODE = KERNEL_VERSION(2,4,18)) if ( do_munmap(current-mm,cont_mem.linear,size,1)!=0) #else if ( do_munmap(current-mm,cont_mem.linear,size)!=0) #endif to #if (LINUX_VERSION_CODE = KERNEL_VERSION(2,4,18)) if ( do_munmap(current-mm,cont_mem.linear,size,1)!=0) #else if ( do_munmap(current-mm,cont_mem.linear,size)!=0) #endif - The 'make install' does not create TLS versions of libGL, so it is necessary under Fedora Core 1 to remove the copies of libGL in /usr/X11R6/lib/tls/ to prevent using the old libGL (glxinfo reports indirect rendering even with DRI enabled). - The build instructions in the Wiki (doc/DRIcompile.html) refer to the wrong CVS server (cvs.dri.sourceforge.net/cvsroot/dri instead of dri.freedesktop.org/cvs/dri) and also don't mention how to get a particular branch. - They also suggest building a new kernel, which is generally unnecessary these days, as well as disabling DRM in that kernel (caused my build of the DRI kernel modules to fail). - The build instructions claim that kernel modules are built as part of make World. This doesn't seem to be the case. Overall, it works very, very nicely! Great work! Steve --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Sun, 22 Feb 2004 14:15:30 -0600 Steve Holland [EMAIL PROTECTED] wrote: I downloaded and tested the savage-2-0-0 branch yesterday. This is on an IBM ThinkPad T23 with a SuperSavage IX/C SDR. It works really well! Congratulations and thanks, guys! A few notes (savage-2-0-0 branch 2/21/04): - tuxracer runs great! - glDrawPixels doesn't seem to work (may be copying pixels to wrong place -- there were hints of corruption elsewhere) - glutBitmapCharacter doesn't seem to work either (calls glBitmap) - Polygon and line drawing work fine. Hmm, the driver lacks the *pixel.[ch] files that for instance the mga driver has. The r128 driver seems to have some pixel drawing stuff in r128_span.[ch]. Which demo did you use to test glDrawPixels and glBitmap? I can't promise that I'll fix it very soon. If you need it feel free to submit a patch. - agpgart must be insmod'd before starting the X server. - something (insmod, I think) gives a system log message kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: SuperSavage IX/C SDR even though this is actually savage 2.0.0 branch That version number has nothing to do with the branch name. ATM it is pretty meaningless. When we start moving bits into the kernel it'll change to reflect new features and incompatibilities. - On my kernel (fedora core 1 2.4.22-1.2129.nptl) I had to change in savage_drv.c: #if 0 (LINUX_VERSION_CODE = KERNEL_VERSION(2,4,18)) if ( do_munmap(current-mm,cont_mem.linear,size,1)!=0) #else if ( do_munmap(current-mm,cont_mem.linear,size)!=0) #endif to #if (LINUX_VERSION_CODE = KERNEL_VERSION(2,4,18)) if ( do_munmap(current-mm,cont_mem.linear,size,1)!=0) #else if ( do_munmap(current-mm,cont_mem.linear,size)!=0) #endif Must be something about how fedora patches their kernels. I didn't need this to build on a stock 2.4.21 kernel from kernel.org. Unless you know a safe way to detect a fedora-patched kernel at build time I'm not going to change it in CVS. But it's good to know in case others stumble over the same problem. - The 'make install' does not create TLS versions of libGL, so it is necessary under Fedora Core 1 to remove the copies of libGL in /usr/X11R6/lib/tls/ to prevent using the old libGL (glxinfo reports indirect rendering even with DRI enabled). This should be added to the new building guide (see below) if it's not there already. - The build instructions in the Wiki (doc/DRIcompile.html) refer to the wrong CVS server (cvs.dri.sourceforge.net/cvsroot/dri instead of dri.freedesktop.org/cvs/dri) and also don't mention how to get a particular branch. You found the old build instructions from pre-Wiki times. I've marked them outdated now and referred to the new build instructions. Note that I merged the savage driver into Mesa and DRI trunk over the weekend. You don't need to get a branch any more. - They also suggest building a new kernel, which is generally unnecessary these days, as well as disabling DRM in that kernel (caused my build of the DRI kernel modules to fail). There have been people who complained that the build failed because they didn't have kernel sources matching their running kernel installed. Also a kernel source tree needs to have seen at least a make dep, otherwise the DRM module build would fail. Compiling their own kernel first is the safest way to guarantee all that without worrying about particular distributions. - The build instructions claim that kernel modules are built as part of make World. This doesn't seem to be the case. The new build instructions reflect that. Overall, it works very, very nicely! Great work! Steve Thanks for your the feedback. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Mon, Feb 23, 2004 at 11:58:25AM +0100, Felix Kühling wrote: Hmm, the driver lacks the *pixel.[ch] files that for instance the mga driver has. The r128 driver seems to have some pixel drawing stuff in r128_span.[ch]. span files have the software stuff and pixel files have some AGP glReadPixels() stuff but I think it's disabled (maybe broken?). The span stuff is straightforward to add because there are some templates. I'm not sure if the AGP glReadPixels() stuff is actually very useful since reading from AGP aperture with the CPU is also very slow. I've been wondering why we can't enable caching on the AGP aperture. Write combining already needs to do some sort of flush after writing so I don't understand why we can't use write-back caching instead and just make sure to flush the cache before reading stuff. Someone care to enlighten me? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Mon, 23 Feb 2004 14:16:07 +0200 Ville Syrjälä [EMAIL PROTECTED] wrote: On Mon, Feb 23, 2004 at 11:58:25AM +0100, Felix Kühling wrote: Hmm, the driver lacks the *pixel.[ch] files that for instance the mga driver has. The r128 driver seems to have some pixel drawing stuff in r128_span.[ch]. span files have the software stuff and pixel files have some AGP glReadPixels() stuff but I think it's disabled (maybe broken?). The span stuff is straightforward to add because there are some templates. If the span stuff is all that's needed then it should be working. Incidentally I tested the drawpix demo yesterday. It worked ok as long as it drew to the back buffer. Drawing to the front buffer was broken, though. It started scribbling all over the screen. Maybe that's all that needs to be fixed. [snip] Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Sunday 22 February 2004 03:15 pm, Steve Holland wrote: I downloaded and tested the savage-2-0-0 branch yesterday. This is on an IBM ThinkPad T23 with a SuperSavage IX/C SDR. It works really well! Congratulations and thanks, guys! A few notes (savage-2-0-0 branch 2/21/04): - tuxracer runs great! Well, glFog() seems to be screwed up for me, 2/23/04 from trunk. I built according to the new build instructions and pointed to the Mesa cvs tree in host.def. However, tuxracer foreground stuff is all white when fog is turned on (sometimes I can see a little texture, so its almost like the fog factor is set way too high). Tuxracer is linked against the current X11R6 GL and GLU libraries. The code is in src/fog.c of the tuxracer-0.61 tarball. The chip is a Savage4 on a creative labs motherboard: ... (II) SAVAGE(0): [agp] Mode 0x1b000213 [AGP 0x10b9/0x1647; Card 0x5333/0x8a22] ... Greg Davis --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Mon, Feb 23, 2004 at 01:38:34PM +0100, Felix Kühling wrote: span files have the software stuff and pixel files have some AGP glReadPixels() stuff but I think it's disabled (maybe broken?). The span stuff is straightforward to add because there are some templates. If the span stuff is all that's needed then it should be working. I think so. The SetBuffer() function in there should take care of buffer selection for all software reading and writing operations. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
