Re: dropped polygons on savage
Nope. Toggling that option back and forth does not change things. The synchronize graphics hardware and floating point depth buffer options don't seem to do anything either. I have a modified testcase that reproducibly generates the same dropped polygons (on my hardware) every time it's run and without user interaction: http://69.5.151.193:81/~sdh4/aviascene_savagebug.tar.gz ( type 'make' followed by 'aviascene castle_demo.cfg' ) Steve On Sun, 2005-05-01 at 15:28 +0200, Felix Kühling wrote: Am Samstag, den 30.04.2005, 22:53 -0500 schrieb Steve Holland: I find that the current savage snapshot (20050430) seems to randomly drop individual polygons or polygon strips (they become transparent to background). Hardware is SuperSavage/IXC (IBM Thinkpad T23) on FC3/linux 2.6.11.2. I noticed this sometimes too, but I was never able to reproduce it reliably. Does the problem go away if you set the enable_fastpath option to false? Testcase: Aviascene http://69.5.151.193:81/~sdh4/aviascene (problem is most severe with texturing off (press t)) Screenshot: http://69.5.151.193:81/~sdh4/savagebug.png Problem did not occur with 20041108 snapshot or prior, or with direct rendering disabled, or with other DRI drivers. Lots of changes have occurred in the driver since 2004. It can't be a DMA problem because the driver can't use DMA on SuperSavages. The fastpath is my next suspect (see above). Rerendering a frame a second time gives exactly the same polygons dropped as in the original render. That's good, makes the problem slightly easier to debug. Thanks, Steve Regards, Felix --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
dropped polygons on savage
I find that the current savage snapshot (20050430) seems to randomly drop individual polygons or polygon strips (they become transparent to background). Hardware is SuperSavage/IXC (IBM Thinkpad T23) on FC3/linux 2.6.11.2. Testcase: Aviascene http://69.5.151.193:81/~sdh4/aviascene (problem is most severe with texturing off (press t)) Screenshot: http://69.5.151.193:81/~sdh4/savagebug.png Problem did not occur with 20041108 snapshot or prior, or with direct rendering disabled, or with other DRI drivers. Rerendering a frame a second time gives exactly the same polygons dropped as in the original render. Thanks, Steve --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon/x86-64 drm loading failure and solution
I had a dri failure-to-load with Radeon in a 64 bit Opteron system
(fedora core 2). Card is a Radeon RV250 (9000). (I did not find it in
drm_pciids.txt -- pci id 0x1002 0x496e -- but that's a separate issue)
The symptoms were kernel messages on modprobe:
radeon: Ignoring new-style parameters in presence of obsolete ones
[drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory!
[drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART!
radeon: probe of :05:00.0 failed with error -22
The problem turned out to be the check on line 78 of drm_bufs.h
(CVS 10/21/04) and the following patch disabling the check fixed the
problem.
--- /tmp/drm_bufs.h 2004-10-22 14:14:49.581824144 -0500
+++ /tmp/updated/drm_bufs.h 2004-10-22 14:16:34.911497648 -0500
@@ -68,19 +68,19 @@
int DRM(initmap)( drm_device_t *dev, unsigned int offset, unsigned int size, int
type, int flags )
{
drm_map_t *map;
drm_map_list_t *list;
DRM_DEBUG(\n);
if ( (offset (~PAGE_MASK)) || (size (~PAGE_MASK)) )
return -EINVAL;
-#if !defined(__sparc__) !defined(__alpha__)
+#if 0 !defined(__sparc__) !defined(__alpha__)
if ( offset + size offset || offset virt_to_phys(high_memory) )
return -EINVAL;
#endif
if ( !(list = DRM(alloc)( sizeof(*list), DRM_MEM_MAPS )))
return -ENOMEM;
memset(list, 0, sizeof(*list));
if ( !(map = DRM(alloc)( sizeof(*map), DRM_MEM_MAPS ))) {
DRM(free)(list, sizeof(*list), DRM_MEM_MAPS);
I added debug printfs and found that offset=0xff5f, size=0x1,
and virt_to_phys(high_memory)=0x4000, so the check really shouldn't
have failed, but I suspect a 64 bit sign extension bug. DRI loads and
works fine once this check is disabled. I also wonder if this check
is still useful in these days of complicated memory maps and 64 bit
architectures. (The machine in question has 4GB main memory, 1GB of
which is shifted above the 4GB boundary to leave space for PCI and
GART/IOMMU address space). Shouldn't offset be a 64 bit quantity?
Also, I noticed that the a failure at this point caused general system
instability after one or two modprobe/rmmod cycles. Perhaps the error
path needs to be investigated.
Steve
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage test notes/glDrawPixels problem
Your fix works!
Thanks, Alex.
On Tue, 2004-10-05 at 14:20, Alex Deucher wrote:
On Tue, 5 Oct 2004 15:07:22 -0400, Alex Deucher [EMAIL PROTECTED] wrote:
On Wed, 29 Sep 2004 13:16:44 -0500, Steve Holland [EMAIL PROTECTED] wrote:
I downloaded the latest savage and common snapshots today, and I have a
few notes (thanks for the great work!):
- The snapshots do not work out-of-the-box on 2.6 kernels -- the 2.6
DRM must be downloaded from CVS installed separately (this does not seem
to be documented)
- My previously reported problem with glDrawPixels is still happens.
Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The
problem seems to be that glDrawPixels doesn't work to the back buffer.
For example, the 'drawpix' demo shows blackness until the 'f' key is
pressed to switch drawing to the front buffer. Drawpix works normally
when LIBGL_ALWAYS_INDIRECT is set.
It would appear that glDrawPixels is copying pixels to the wrong place.
For example, see http://69.5.151.193/~sdh4/dribug.png. The black and
colored stripes in this picture are texture portions corrupted by
glDrawPixels. (There is supposed to be a map display in the lower right.
The glDrawPixels() is supposed to copy this into the back buffer,
instead it ends up splattered over the textures). In addition, if you
look at the word 'East -76.' in the picture (under 'Marine park'),
that text was written with glutBitmapCharacter() (translates to
glBitmap()) to the (2D orthogonal) back buffer.
I think I tracked this down. On supersavages (I don't know about
other savage4 based chips, I'll test it out tonight if I get a chance)
you need to shift the framebuffer offset passed to the tiled surface
registers by 6 rather than 5 (in savage_dri.c):
} else {
if(pSAVAGEDRI-cpp == 2)
{
value |= (((pSAVAGEDRI-width + 0x3F) 0xFFC0) 6) 20;
value |= 230;
} else {
value |= (((pSAVAGEDRI-width + 0x1F) 0xFFE0) 5) 20;
value |= 330;
}
OUTREG(TILED_SURFACE_REGISTER_0, value|(pSAVAGEDRI-frontOffset
5) ); /* front */
OUTREG(TILED_SURFACE_REGISTER_1, value|(pSAVAGEDRI-backOffset
5) ); /* back */
OUTREG(TILED_SURFACE_REGISTER_2, value|(pSAVAGEDRI-depthOffset
5) ); /* depth */
}
}
Change the shift above from 5 to 6 and see if that fixes it for you.
the front buffer doesn't show any problems because the offset is 0. I
noticed this while debugging dualhead support on supersavage chips.
To be clear, just change it for the OUTREG lines, not the lines above that.
Alex
Alex
Thanks,
Steve
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
savage test notes/glDrawPixels problem
I downloaded the latest savage and common snapshots today, and I have a few notes (thanks for the great work!): - The snapshots do not work out-of-the-box on 2.6 kernels -- the 2.6 DRM must be downloaded from CVS installed separately (this does not seem to be documented) - My previously reported problem with glDrawPixels is still happens. Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The problem seems to be that glDrawPixels doesn't work to the back buffer. For example, the 'drawpix' demo shows blackness until the 'f' key is pressed to switch drawing to the front buffer. Drawpix works normally when LIBGL_ALWAYS_INDIRECT is set. It would appear that glDrawPixels is copying pixels to the wrong place. For example, see http://69.5.151.193/~sdh4/dribug.png. The black and colored stripes in this picture are texture portions corrupted by glDrawPixels. (There is supposed to be a map display in the lower right. The glDrawPixels() is supposed to copy this into the back buffer, instead it ends up splattered over the textures). In addition, if you look at the word 'East -76.' in the picture (under 'Marine park'), that text was written with glutBitmapCharacter() (translates to glBitmap()) to the (2D orthogonal) back buffer. Thanks, Steve --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ 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
[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
