Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
Alan Cox <[EMAIL PROTECTED]> wrote: > What chipset. My problems are AGP 1x on AMD 75x series Mine runs on a Via Apollo Pro (ASUS P3V 4X), AGP 1x crashes as well as AGP 4x. I tried playing "EnablePageflip", but this does not make any difference either, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Mon, 2003-02-24 at 01:45, hy0 wrote: > > Anyway, basically most registers belonging to 2D and 3D engines are FIFOed, > while the registers belonging to the display engine (like crtc, dac, cursor, > fp, palette, overlay...) are not. Thanks. I suspect there's no simple rule as with Mach64 then, which is a pity because that would make it easy for a register write macro or function to always do the right thing. -- 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] Radeon 9000Pro hangs with current DRM
Alan Cox <[EMAIL PROTECTED]> writes: > On Mon, 2003-02-24 at 22:14, Jaakko Niemi wrote: >> Just a data point, things seem stable with my 9100 with XFree86 4.3-pre >> and drm from cvs head. Bots were whacking each other in one q3 mod for >> 18 hours.. > > What chipset. My problems are AGP 1x on AMD 75x series VIA KT266 on soyo dragon+ motherboard, and AGP 4x. --j --- 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] Radeon 9000Pro hangs with current DRM
On Mon, 2003-02-24 at 22:14, Jaakko Niemi wrote: > Just a data point, things seem stable with my 9100 with XFree86 4.3-pre > and drm from cvs head. Bots were whacking each other in one q3 mod for > 18 hours.. What chipset. My problems are AGP 1x on AMD 75x series --- 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] Radeon 9000Pro hangs with current DRM
Martin Spott <[EMAIL PROTECTED]> writes: > Alan Cox <[EMAIL PROTECTED]> wrote: > >> With a 747 it starts up, I get a cockpit, I turn up the engines taxi down >> the runway and embed the nose in the ground. I can't fly a 747 but I don't >> see the problem you reported > > Thanks for the test. Maybe we have too look at the differences between a > Radeon7500 (mine) and a '9000 Just a data point, things seem stable with my 9100 with XFree86 4.3-pre and drm from cvs head. Bots were whacking each other in one q3 mod for 18 hours.. --j --- 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] Radeon 9000Pro hangs with current DRM
Alan Cox <[EMAIL PROTECTED]> wrote: > With the older code I could play cube for hours, with the texture upload > that fixes the hang on fg, its a matter of mintues Oh, I know, some of the CVS branches that were floating around have been quite stable with FlightGear. Ian's 'texmem-0-0-1' was quite usuable shortly _before_ he merged the trunk into it. Though he made so many changes that I was unable to determine which one decreased stability with FlightGear, 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] Radeon 9000Pro hangs with current DRM
On Mon, 2003-02-24 at 19:20, Michel Dänzer wrote: > Please clarify what you mean by 'texture upload changes'. I'm not aware > of any such changes that are related to the COMMIT_RING() change (of > which there's only been a single one recently). Unrelated but I changed both so I wanted to make sure it wasn't the easy to revert change 8). --- 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] Radeon 9000Pro hangs with current DRM
On Mon, 2003-02-24 at 21:04, Alan Cox wrote: > On Mon, 2003-02-24 at 17:24, Alan Cox wrote: > > On Mon, 2003-02-24 at 13:43, Martin Spott wrote: > > > Absolutely the same effect as over here. Unfortunately it gets stuck on > > > startup with the B747, immediately after writing some message like > > > "Reading electrical system model from [...]", > > > > With a 747 it starts up, I get a cockpit, I turn up the engines taxi down > > the runway and embed the nose in the ground. I can't fly a 747 but I don't > > see the problem you reported > > I also tried adding back the extra apparently surplus read in COMMIT_RING > that vanished with the change the texture uploading. That doesn't change > anything I still see random segfault/trace trap errors which look like > memory corruption. > > With the older code I could play cube for hours, with the texture upload > that fixes the hang on fg, its a matter of mintues Please clarify what you mean by 'texture upload changes'. I'm not aware of any such changes that are related to the COMMIT_RING() change (of which there's only been a single one recently). -- 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] Radeon 9000Pro hangs with current DRM
On Mon, 2003-02-24 at 17:24, Alan Cox wrote: > On Mon, 2003-02-24 at 13:43, Martin Spott wrote: > > Absolutely the same effect as over here. Unfortunately it gets stuck on > > startup with the B747, immediately after writing some message like > > "Reading electrical system model from [...]", > > With a 747 it starts up, I get a cockpit, I turn up the engines taxi down > the runway and embed the nose in the ground. I can't fly a 747 but I don't > see the problem you reported I also tried adding back the extra apparently surplus read in COMMIT_RING that vanished with the change the texture uploading. That doesn't change anything I still see random segfault/trace trap errors which look like memory corruption. With the older code I could play cube for hours, with the texture upload that fixes the hang on fg, its a matter of mintues Alan --- 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] Radeon 9000Pro hangs with current DRM
Alan Cox <[EMAIL PROTECTED]> wrote: > With a 747 it starts up, I get a cockpit, I turn up the engines taxi down > the runway and embed the nose in the ground. I can't fly a 747 but I don't > see the problem you reported Thanks for the test. Maybe we have too look at the differences between a Radeon7500 (mine) and a '9000 Martin. P.S.: It should be easy to get a B747 off the ground, you just have to wait until the runway ends and pull up a few seconds before. It's much more difficult to touchdown right on the runway after flight ;-) -- 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] Radeon 9000Pro hangs with current DRM
On Mon, 2003-02-24 at 13:43, Martin Spott wrote: > Absolutely the same effect as over here. Unfortunately it gets stuck on > startup with the B747, immediately after writing some message like > "Reading electrical system model from [...]", With a 747 it starts up, I get a cockpit, I turn up the engines taxi down the runway and embed the nose in the ground. I can't fly a 747 but I don't see the problem you reported --- 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] Radeon 9000Pro hangs with current DRM
Alan Cox <[EMAIL PROTECTED]> wrote: > I updated the radeon DRM to include the texture upload changes. My > radeon hang with flightgear now happens every two hours instead of > instantly. Would you please be so kind to try the B747 ? Please run FG with the option: --aircraft=747-yasim > When it dies X is stuck, the mouse pointer works. The 3D app is burning > a lot of CPU and the system is otherwise running. At the point the 3D > is killed (kill -9 etc) the box hangs solid Absolutely the same effect as over here. Unfortunately it gets stuck on startup with the B747, immediately after writing some message like "Reading electrical system model from [...]", 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] Radeon 9000Pro hangs with current DRM
> On Sam, 2003-02-22 at 23:04, Leif Delgass wrote: > > On 22 Feb 2003, Michel Dänzer wrote: > > > > > On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > > > > On 22 Feb 2003, Michel Dänzer wrote: > > > > > > > > > > I do wonder if the register writes in RADEONSetCursorPosition() could > > > > > interfere with the CP to cause FIFO overflows. Does anyone have an idea > > > > > how to determine whether writes to certain registers go through the > > > > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > > > > > indication that these might not is that I'd expect it to cause problems > > > > > much more frequently if they did. > > > > > > > > IIRC, at least on mach64, hardware cursor position updates don't go > > > > through the draw engine FIFO > > > > > > Good, that makes a lot of sense of course. > > > > > > > (any registers below dword offset 0x040 don't use the FIFO), > > > > > > Where did you find this information? Have you found anything similar > > > about Radeons anywhere? > > > > It's in the register reference and programmer's guide. I don't have docs > > on Radeons, so I don't know if there is a similar convention there. > > I can't find any in the docs I have unfortunately. The SDK PDF says 'The > file REGDEF.H specifically outlines the registers are "FIFOed", and > identifies the registers that can be read directly', but I don't see any > such information in that file either. :( Maybe I'm blind... No, you're not:) Some of reference files in the Programming Guide do not match the actual files correctly. Anyway, basically most registers belonging to 2D and 3D engines are FIFOed, while the registers belonging to the display engine (like crtc, dac, cursor, fp, palette, overlay...) are not. Hui > > -- > 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: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Sam, 2003-02-22 at 23:04, Leif Delgass wrote: > On 22 Feb 2003, Michel Dänzer wrote: > > > On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > > > On 22 Feb 2003, Michel Dänzer wrote: > > > > > > > > I do wonder if the register writes in RADEONSetCursorPosition() could > > > > interfere with the CP to cause FIFO overflows. Does anyone have an idea > > > > how to determine whether writes to certain registers go through the > > > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > > > > indication that these might not is that I'd expect it to cause problems > > > > much more frequently if they did. > > > > > > IIRC, at least on mach64, hardware cursor position updates don't go > > > through the draw engine FIFO > > > > Good, that makes a lot of sense of course. > > > > > (any registers below dword offset 0x040 don't use the FIFO), > > > > Where did you find this information? Have you found anything similar > > about Radeons anywhere? > > It's in the register reference and programmer's guide. I don't have docs > on Radeons, so I don't know if there is a similar convention there. I can't find any in the docs I have unfortunately. The SDK PDF says 'The file REGDEF.H specifically outlines the registers are "FIFOed", and identifies the registers that can be read directly', but I don't see any such information in that file either. :( Maybe I'm blind... -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On 22 Feb 2003, Michel Dänzer wrote: > On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > > On 22 Feb 2003, Michel Dänzer wrote: > > > > > On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > > > > > > I do wonder if the register writes in RADEONSetCursorPosition() could > > > interfere with the CP to cause FIFO overflows. Does anyone have an idea > > > how to determine whether writes to certain registers go through the > > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > > > indication that these might not is that I'd expect it to cause problems > > > much more frequently if they did. > > > > IIRC, at least on mach64, hardware cursor position updates don't go > > through the draw engine FIFO > > Good, that makes a lot of sense of course. > > > (any registers below dword offset 0x040 don't use the FIFO), > > Where did you find this information? Have you found anything similar > about Radeons anywhere? It's in the register reference and programmer's guide. I don't have docs on Radeons, so I don't know if there is a similar convention there. > > so locking isn't necessary. However, we do lock the DRM when updating > > the cursor image, since it blits the image to the framebuffer through > > the host data FIFO. > > The radeon driver writes it to the framebuffer directly. Actually, looking at it again, so does mach64 (I was thinking of an XAA function). However, the DDX does an XAA sync before writing the cursor image to synchronize the framebuffer access. Since we do the 3D/2D sync in the XAA sync, I had to put a DRILock/Unlock around it. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
The cursor still moves therefore either 1. The cursor doesnt go via the FIFO 2. The FIFO is not full .. --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > On 22 Feb 2003, Michel Dänzer wrote: > > > On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > > > > I do wonder if the register writes in RADEONSetCursorPosition() could > > interfere with the CP to cause FIFO overflows. Does anyone have an idea > > how to determine whether writes to certain registers go through the > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > > indication that these might not is that I'd expect it to cause problems > > much more frequently if they did. > > IIRC, at least on mach64, hardware cursor position updates don't go > through the draw engine FIFO Good, that makes a lot of sense of course. > (any registers below dword offset 0x040 don't use the FIFO), Where did you find this information? Have you found anything similar about Radeons anywhere? > so locking isn't necessary. However, we do lock the DRM when updating > the cursor image, since it blits the image to the framebuffer through > the host data FIFO. The radeon driver writes it to the framebuffer directly. -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On 22 Feb 2003, Michel Dänzer wrote: > On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > > I updated the radeon DRM to include the texture upload changes. My > > radeon hang with flightgear now happens every two hours instead of > > instantly. > > Is that exactly every two hours? :) > > By texture upload changes do you mean my radeon_cp_dispatch_texture() > fix? If so, are you sure that makes the difference? I merely fixed it > not to leave out parts of big textures. I'd rather expect the > COMMIT_RING() change to make a difference. > > > When it dies X is stuck, the mouse pointer works. > > Because it's SIGIO driven. > > I do wonder if the register writes in RADEONSetCursorPosition() could > interfere with the CP to cause FIFO overflows. Does anyone have an idea > how to determine whether writes to certain registers go through the > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > indication that these might not is that I'd expect it to cause problems > much more frequently if they did. IIRC, at least on mach64, hardware cursor position updates don't go through the draw engine FIFO (any registers below dword offset 0x040 don't use the FIFO), so locking isn't necessary. However, we do lock the DRM when updating the cursor image, since it blits the image to the framebuffer through the host data FIFO. When I was first working on 2D/3D sync, we did the sync on every EnterServer, which slowed things down considerably since the sync happened on every cursor position update. Now we only do the sync for blits and XAA operations and I've never seen a lockup because of the hardware cursor. > Anyway, Alan, can you try if disabling Silken mouse or even using SW > cursor (make sure you have the fix for crashes with SW cursor and DRI > though :) makes a difference? > > > The 3D app is burning a lot of CPU and the system is otherwise running. > > At the point the 3D is killed (kill -9 etc) the box hangs solid > > Classical chip crash or lockup. :\ > > > -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > I updated the radeon DRM to include the texture upload changes. My > radeon hang with flightgear now happens every two hours instead of > instantly. Is that exactly every two hours? :) By texture upload changes do you mean my radeon_cp_dispatch_texture() fix? If so, are you sure that makes the difference? I merely fixed it not to leave out parts of big textures. I'd rather expect the COMMIT_RING() change to make a difference. > When it dies X is stuck, the mouse pointer works. Because it's SIGIO driven. I do wonder if the register writes in RADEONSetCursorPosition() could interfere with the CP to cause FIFO overflows. Does anyone have an idea how to determine whether writes to certain registers go through the FIFO? I asked ATI devrel about this but didn't get a reply. :( The only indication that these might not is that I'd expect it to cause problems much more frequently if they did. Anyway, Alan, can you try if disabling Silken mouse or even using SW cursor (make sure you have the fix for crashes with SW cursor and DRI though :) makes a difference? > The 3D app is burning a lot of CPU and the system is otherwise running. > At the point the 3D is killed (kill -9 etc) the box hangs solid Classical chip crash or lockup. :\ -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 9000Pro hangs with current DRM
I updated the radeon DRM to include the texture upload changes. My radeon hang with flightgear now happens every two hours instead of instantly. When it dies X is stuck, the mouse pointer works. The 3D app is burning a lot of CPU and the system is otherwise running. At the point the 3D is killed (kill -9 etc) the box hangs solid Radeon 9000Pro -- Alan Cox <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 9000pro
Hi, is Radeon 9000pro supported under DRI? Simon --- 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
