Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
--- Marco Strack <[EMAIL PROTECTED]> wrote: > 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. regarding the 24 bpp stuff. I'm not sure why that isn't working. once problem might be that the layout of the GBD might be wrong in the driver. I assumed it was like prosavage, but it might be like savage4 or m7. I just made an educated guess when I added the code. still if it works at 16 bit, it should work at 24 bit. if you want you can try changing the BD setup for supersavage in savage_accel.c and savage_dri.c. I can explain in more detail or provide a patch. it may also be that you just don't have enough mem in 24 bpp. Alex > > 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 > > __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- 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=1470&alloc_id=3638&op=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=1470&alloc_id=3638&op=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
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=1470&alloc_id=3638&op=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. 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... > > > > 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 > > > > >
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. 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... > > 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=1470&alloc_id=3638&op=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
--- Felix Kühling <[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. 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... Alex > > 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] > > __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools --- 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=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
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_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
