Re: [r300] [patches] debugging lockups
On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Perhaps. I don't think it's just the pacifier sequence, though. I've been running applications with RADEON_DEBUG=sync, which causes idle calls between cmdbuf calls, and I've been seeing lockups where the read pointer sits after the beginning of what cmdbuf emits and long before the first rendering commands. I dont know if packet3 was issued before since I tweaked isosurf to dump each frame portion of RADEON_DEBUG info into files using freopen. But DISCARD BUF was really the only key difference in these logs. This indicates that at least one lockup is cause by one of the following: - intial pacifier sequence in r300_cp_cmdbuf - emission of cliprects or Cliprects seem to be little off scale when compairing progs/samples/logo against software rendering. Perhaps near plane is negative ? - initial unchecked_state commands sent by the client This is bad as you can see from first frame drawn by texwrap... Sticking: r300_setup_textures(ctx); r300_setup_rs_unit(ctx); r300SetupVertexShader(rmesa); r300SetupPixelShader(rmesa); or resethwstate to r300_run_vb_render should fix it. -- Aapo Tahkola --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Friday 03 June 2005 10:28, Aapo Tahkola wrote: On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Perhaps. I don't think it's just the pacifier sequence, though. I've been running applications with RADEON_DEBUG=sync, which causes idle calls between cmdbuf calls, and I've been seeing lockups where the read pointer sits after the beginning of what cmdbuf emits and long before the first rendering commands. I dont know if packet3 was issued before since I tweaked isosurf to dump each frame portion of RADEON_DEBUG info into files using freopen. But DISCARD BUF was really the only key difference in these logs. This indicates that at least one lockup is cause by one of the following: - intial pacifier sequence in r300_cp_cmdbuf - emission of cliprects or Cliprects seem to be little off scale when compairing progs/samples/logo against software rendering. Perhaps near plane is negative ? - initial unchecked_state commands sent by the client This is bad as you can see from first frame drawn by texwrap... Sticking: r300_setup_textures(ctx); r300_setup_rs_unit(ctx); r300SetupVertexShader(rmesa); r300SetupPixelShader(rmesa); or resethwstate to r300_run_vb_render should fix it. I'm not sure we're talking about the same thing here. This happens when the client sends a command buffer where all the state blocks (from r300-hw) are sent to the hardware *anyway*. It's actually the *order* of emission (e.g. the order in which insert_at_tail is called for state bits) that can make a difference. The thing is, while the order definitely *does* affect the probability of lockups, lockups will not go away completely even if I use the exact same order that fglrx uses. So I'm beginning to believe that we can't trust radeon_do_cp_idle to completely idle the chip, or that whatever is wrong is pretty fundamentally wrong (some wrong bits in how the memory is configured?). cu, Nicolai pgprQzzlJLfsA.pgp Description: PGP signature
Re: [r300] [patches] debugging lockups
On Friday 03 June 2005 00:25, Benjamin Herrenschmidt wrote: You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Here it is: radeonWaitIrq: drmRadeonIrqWait: -16 Have you tried David Airlie's or my latest DRM IRQ fixes ? It is unlikely that the problem is related, especially when X locks up, too. If you see this message and X is continuing to run fine (i.e. no complete lockup), you should indeed consider looking at the IRQ code. However, if X locks up completely, the most likely reason for this message is simply that the R300 locks up before it encounters the IRQ EMIT command in the ring buffer. It just happens then that the DRI client waits for an IRQ instead of busy-looping for the chip to idle. So it is perfectly likely that this message appears even when the IRQ handling code is working fine. Nevertheless, testing that patch can't hurt. cu, Nicolai pgp5KDqFMYqUZ.pgp Description: PGP signature
Re: [r300] [patches] debugging lockups
On Fri, 3 Jun 2005 14:57:37 +0200 Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 03 June 2005 10:28, Aapo Tahkola wrote: On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Perhaps. I don't think it's just the pacifier sequence, though. I've been running applications with RADEON_DEBUG=sync, which causes idle calls between cmdbuf calls, and I've been seeing lockups where the read pointer sits after the beginning of what cmdbuf emits and long before the first rendering commands. I dont know if packet3 was issued before since I tweaked isosurf to dump each frame portion of RADEON_DEBUG info into files using freopen. But DISCARD BUF was really the only key difference in these logs. This indicates that at least one lockup is cause by one of the following: - intial pacifier sequence in r300_cp_cmdbuf - emission of cliprects or Cliprects seem to be little off scale when compairing progs/samples/logo against software rendering. Perhaps near plane is negative ? - initial unchecked_state commands sent by the client This is bad as you can see from first frame drawn by texwrap... Sticking: r300_setup_textures(ctx); r300_setup_rs_unit(ctx); r300SetupVertexShader(rmesa); r300SetupPixelShader(rmesa); or resethwstate to r300_run_vb_render should fix it. I'm not sure we're talking about the same thing here. This happens when the client sends a command buffer where all the state blocks (from r300-hw) are sent to the hardware *anyway*. It's actually the *order* of emission (e.g. the order in which insert_at_tail is called for state bits) that can make a difference. The thing is, while the order definitely *does* affect the probability of lockups, lockups will not go away completely even if I use the exact same order that fglrx uses. So I'm beginning to believe that we can't trust radeon_do_cp_idle to completely idle the chip, or that whatever is wrong is pretty fundamentally wrong (some wrong bits in how the memory is configured?). Remember that because of reemiting, those states arent in perfect order. Fortunately taking out lines 206-212 of r300_context.c doesnt seem to have any side effects on rv350. -- Aapo Tahkola --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) -- Aapo Tahkola cb_pacify.patch Description: Binary data
Re: [r300] [patches] debugging lockups
Vladimir Dergachev wrote: On Wed, 1 Jun 2005, Adam K Kirchhoff wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: I just gave it a shot with UnrealTournament. I'll try with Q3A in a little bit * cold restart * start one of 3d programs measure time before lockup 2 minutes... That's with just twm, an xterm, and UT running. I'm not even using half of my systems memory at the time of the lockup (about 400 megs of the 1 gig). Nothing being swapped. * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. Less than 30 seconds. This time I have KDE, openoffice, abiword, gimp, gv, epiphany, mozilla, firefox, thunderbird, and a few other apps running in the background. Amazingly, I still wasn't swapping. When the lockup occurred, I was using 1021364k of 1034532k according to top. Now to see if I can repeat the results with Q3A. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) I think you're going in the right direction. ut2004demo, which previously always locked up the moment the menu appeared, now locks up after 6-20 seconds or so. Also, a lock up that happened to me with running other programs with glxgears, opening their popup menus and pressing icons takes longer too. Adding patch.remove-userspace-pacifiers to this one causes almost immediate lock ups. I get the feeling the mouse (even with silken mouse off) has some effect. It's as if the more I move it the faster the lock up appears. Boris Peterbarg --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Vladimir Dergachev wrote: Adam, Great, thank you very much ! No, the system did not need to be actively swapping in fact this would probably have confused the results. (this is why I asked for passive apps) Could you also let me know the following information: Output of free At the moment: [ [EMAIL PROTECTED] - ~ ]: free total used free sharedbuffers cached Mem: 1034532 483876 550656 0 113452 154604 -/+ buffers/cache: 215820 818712 Swap: 2038136 02038136 If you want the output after/during a lockup, I'll get it this afternoon. Output of cat /proc/pci Doesn't exist any more :-) However: :00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02) :00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02) :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) :00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02) :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) :00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] :01:00.1 Display controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] (Secondary) :02:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) :02:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) :02:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a) :02:0a.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26) :02:0b.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08) :02:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) :02:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) :02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Output of cat /proc/interrupts [ [EMAIL PROTECTED] - ~ ]: cat /proc/interrupts CPU0 CPU1 0:8326778 0IO-APIC-edge timer 1:519 0IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 4: 7 0IO-APIC-edge serial 8: 1 0IO-APIC-edge rtc 12: 4214 0IO-APIC-edge i8042 14: 46373 0IO-APIC-edge ide0 15: 74596 0IO-APIC-edge ide1 16: 211299 0 IO-APIC-level uhci_hcd, uhci_hcd, [EMAIL PROTECTED]::01:00.0 18: 0 0 IO-APIC-level uhci_hcd 19: 0 0 IO-APIC-level uhci_hcd 20: 8 0 IO-APIC-level ohci1394, bttv0 21: 4545 0 IO-APIC-level EMU10K1, eth0 22: 64 0 IO-APIC-level sym53c8xx 23: 54207 0 IO-APIC-level ehci_hcd, Ensoniq AudioPCI NMI: 0 0 LOC:83266788326673 ERR: 0 MIS: 0 Output of cat /proc/iomem [ [EMAIL PROTECTED] - /home/adamk ]: cat /proc/iomem -0009ebff : System RAM 0009ec00-0009 : reserved 000a-000b : Video RAM area 000c-000ccfff : Video ROM 000d-000d3fff : Adapter ROM 000f-000f : System ROM 0010-3fed : System RAM 0010-00322922 : Kernel code 00322923-00402a7f : Kernel data 3fee-3fee2fff : ACPI Non-volatile Storage 3fee3000-3fee : ACPI Tables 3fef-3fef : reserved 3ff0-3ff003ff : :00:1f.1 d800-dfff : :00:00.0 e000-efff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeon e800-efff : :01:00.1 f000-f1ff : PCI Bus #01 f100-f100 : :01:00.0 f100-f100 : radeon f101-f101 : :01:00.1 f300-f3003fff : :02:03.0 f3004000-f30040ff : :02:0a.0 f3004000-f30040ff : sym53c8xx f3005000-f3005fff : :02:0a.0 f3005000-f3005fff : sym53c8xx f3006000-f30067ff : :02:03.0 f3006000-f30067ff : ohci1394 f3007000-f30070ff : :02:0d.0 f3007000-f30070ff : 8139too f400-f4000fff : :02:0c.0 f400-f4000fff : bttv0 f4001000-f4001fff : :02:0c.1 f410-f41003ff : :00:1d.7 f410-f41003ff : ehci_hcd fec0- : reserved Anything special about your computer (is it SMP ?) Dual Xeon (HT is disabled). 1 gig of RAM. Intel i875 chipset. Adam
Re: [r300] [patches] debugging lockups
Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) Well, there's no point in stopping now. I'll give it a shot when I get home. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Being a fool, I typed 'dmesg' before writing down the error. Of course nothing showed up in dmesg, and the error from X (or Q3A) was no longer in the buffer. There was no lockup. I started X up again (without rebooting). Went another thirty minutes playing Q3A. Same thing happened, except that the terminal never came back up. I ssh'ed in, and neither Q3A nor X were running. So I rebooted. And here I sit. Another thing I noticed. When playing Q3A with a window manager running, every 10-30 seconds the screen goes black for a second. The game continues, even in darkness, but this doesn't happen when running without a window manager. I have no idea if it's related, but I thought I'd pass it along. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Being a fool, I typed 'dmesg' before writing down the error. Of course nothing showed up in dmesg, and the error from X (or Q3A) was no longer in the buffer. There was no lockup. I started X up again (without rebooting). Went another thirty minutes playing Q3A. Same thing happened, except that the terminal never came back up. I ssh'ed in, and neither Q3A nor X were running. So I rebooted. And here I sit. Another thing I noticed. When playing Q3A with a window manager running, every 10-30 seconds the screen goes black for a second. The game continues, even in darkness, but this doesn't happen when running without a window manager. I have no idea if it's related, but I thought I'd pass it along. Adam One more thing... No matter what patches I apply, or what other X programs and X clients I have running, I've never been able to get more than 3-4 minutes out of UnrealTournament. I was able to play Q3A for an hour without a single X lockup (just Q3A crashing), but UT still locked up within 30 seconds or so. So either UT is more likely to cause this bug, or it's causing an entirely different bug. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Here it is: radeonWaitIrq: drmRadeonIrqWait: -16 Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Thu, 02 Jun 2005 17:23:34 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: One more thing... No matter what patches I apply, or what other X programs and X clients I have running, I've never been able to get more than 3-4 minutes out of UnrealTournament. I was able to play Q3A for an hour without a single X lockup (just Q3A crashing), but UT still locked up within 30 seconds or so. So either UT is more likely to cause this bug, or it's causing an entirely different bug. Adam Same on R200. Q3A sometimes works for an hour, but UT locks up within the first 30secs. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Here it is: radeonWaitIrq: drmRadeonIrqWait: -16 Have you tried David Airlie's or my latest DRM IRQ fixes ? Ben. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Tue, 2005-05-31 at 21:52 +0200, Nicolai Haehnle wrote: Hello everybody, today's lockup-chasing wrapup follows :) BTW. Look at the removing radeon_acknowledge_irqs hack.. thread and my reply to David more specifically. I think we may be losing interrupts. I don't know if that can explain the lockups though. Ben. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Wed, 2005-06-01 at 16:39 +0200, Nicolai Haehnle wrote: On Wednesday 01 June 2005 09:22, Benjamin Herrenschmidt wrote: On Tue, 2005-05-31 at 21:52 +0200, Nicolai Haehnle wrote: Hello everybody, today's lockup-chasing wrapup follows :) BTW. Look at the removing radeon_acknowledge_irqs hack.. thread and my reply to David more specifically. I think we may be losing interrupts. I don't know if that can explain the lockups though. I agree. There may have been an issue on old Radeon cards, but it's highly unlikely that the same problem still exists in the R3xx family. Also, I have seen no regressions with your patch (no improvements either, but that's not unexpected). I really can't see what issue may have made that hack necessary, this was clearly bogus imho. So unless there are any objections, I'm going to apply your patch and the patch.drm-cmdbuf-more-pacifiers that I posted yesterday to the r300 CVS soon. cu, Nicolai --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Wed, 1 Jun 2005, Adam K Kirchhoff wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: * cold restart * start one of 3d programs measure time before lockup * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. If there is a marked difference, it may have to do with using PCI transfers to write age from scratch registers. thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: I just gave it a shot with UnrealTournament. I'll try with Q3A in a little bit * cold restart * start one of 3d programs measure time before lockup 2 minutes... That's with just twm, an xterm, and UT running. I'm not even using half of my systems memory at the time of the lockup (about 400 megs of the 1 gig). Nothing being swapped. * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. Less than 30 seconds. This time I have KDE, openoffice, abiword, gimp, gv, epiphany, mozilla, firefox, thunderbird, and a few other apps running in the background. Amazingly, I still wasn't swapping. When the lockup occurred, I was using 1021364k of 1034532k according to top. Now to see if I can repeat the results with Q3A. Adam Sorry for sending the previous e-mail from my work address. Not quite sure how that happened. Anyway, I've repeated the test with Quake3... Cold restart, no other X apps (not even twm or xterm): 10 minutes before a lockup. Cold restart, X, vncserver, gimp, abiword, openoffice, mozilla, etc.: 10 seconds. Again, it still wasn't swapping when the lockup happened according to top, but loading up the memory definitely seems to have an impact. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam, Great, thank you very much ! No, the system did not need to be actively swapping in fact this would probably have confused the results. (this is why I asked for passive apps) Could you also let me know the following information: Output of free Output of cat /proc/pci Output of cat /proc/interrupts Output of cat /proc/iomem Anything special about your computer (is it SMP ?) thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: I just gave it a shot with UnrealTournament. I'll try with Q3A in a little bit * cold restart * start one of 3d programs measure time before lockup 2 minutes... That's with just twm, an xterm, and UT running. I'm not even using half of my systems memory at the time of the lockup (about 400 megs of the 1 gig). Nothing being swapped. * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. Less than 30 seconds. This time I have KDE, openoffice, abiword, gimp, gv, epiphany, mozilla, firefox, thunderbird, and a few other apps running in the background. Amazingly, I still wasn't swapping. When the lockup occurred, I was using 1021364k of 1034532k according to top. Now to see if I can repeat the results with Q3A. Adam Sorry for sending the previous e-mail from my work address. Not quite sure how that happened. Anyway, I've repeated the test with Quake3... Cold restart, no other X apps (not even twm or xterm): 10 minutes before a lockup. Cold restart, X, vncserver, gimp, abiword, openoffice, mozilla, etc.: 10 seconds. Again, it still wasn't swapping when the lockup happened according to top, but loading up the memory definitely seems to have an impact. Adam Beware that some applications use widget toolkits try to use libGL (QT and maybe GTK?), and they may influence the result (like concurrent apps using OpenGL). -- Pedro Ramalhais --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] [patches] debugging lockups
Hello everybody,
today's lockup-chasing wrapup follows :)
Two observations about the lockups I've been seeing:
(1) Lockups are more likely to occur when the ring buffer is filled with
packet2s for alignment (see the attached experimental
patch.drm-align-ring).
(2) Lockups are a lot less likely to occur when additional synchronisation
measures are taken (like waiting for the read pointer to catch up with the
write pointer after every ADVANCE_RING).
If we assume that the (most) lockups are caused by a race in memory
accesses, then both observations make sense: Filling the ring buffer with
packet2s causes the CP to request new batches from the ring buffer more
often, and waiting for the ring buffer to catch up means that less stuff
happens in parallel. Of course there may be a number of other
interpretations.
Another observation:
(3) On my system, lockups involving simple programs (like glxgears) are a
lot more likely to happen when multiple 3D clients are running in parallel.
In particular, starting glean while running glxgears means an almost
certain lockup, at least with the patch.remove-userspace-pacifiers that I
posted earlier. (The background for that patch was that fglrx never emits a
pacifier sequence in between 3D commands)
I have written a very unintrusive debugging facility for the DRM that
basically logs which parts of the code emit commands to the ring buffer.
When a lockup is detected, it prints this information out (via printk)
along with a dump of the relevant part of the ring buffer. I have attached
this patch, it is called patch.drm-debug-lockups-enabled (this logging
facility can be disabled at compile time via the RADEON_DEBUG_LOCKUPS
define in radeon_drv.h).
Using this patch, I have made another observation:
(4) All the lockups that happen for me occur when two cmdbuf ioctls are
processed immediately after another, without an idle ioctl or similar
inbetween.
So I have compared what our driver does at the boundary of 3D commands to
what fglrx does, and I've come up with the attached
patch.drm-cmdbuf-more-pacifiers, which adds an additional wait command to
the end of r300_do_cp_cmdbuf. Using this patch, glean no longer locks up
immediately when glxgears is running at the same time. Unfortunately, not
all lockups have gone away yet...
What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers,
and report if there are any regressions (I don't believe there are any)
and/or if it removes certain lockups you are seeing.
If you're feeling adventurous, I'd appreciate it if you could also try this
patch in combination with the patch.remove-userspace-pacifiers patch I
posted earlier, though this patch appears to be dangerous still (even
though I do not understand why).
cu,
Nicolai
Index: drm/shared-core/radeon_drv.h
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_drv.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 radeon_drv.h
--- drm/shared-core/radeon_drv.h 3 Mar 2005 04:40:21 - 1.12
+++ drm/shared-core/radeon_drv.h 31 May 2005 17:36:01 -
@@ -985,14 +985,37 @@ do { \
#define RING_LOCALS int write, _nr; unsigned int mask; u32 *ring;
+#define ALIGN_RING() do { \
+ int _nr = 32 - (dev_priv-ring.tail 31); \
+ int _write; \
+ if (dev_priv-ring.space = (_nr+1) * sizeof(u32)) { \
+ COMMIT_RING(); \
+ radeon_wait_ring( dev_priv, (_nr+1) * sizeof(u32) ); \
+ }\
+ _write = dev_priv-ring.tail; \
+ if (_write 1) { \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv-ring.tail_mask; \
+ _nr--; \
+ }\
+ while( _nr = 2 ) { \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv-ring.tail_mask; \
+ _nr -= 2; \
+ }\
+ dev_priv-ring.tail = _write; \
+} while (0)
+
#define BEGIN_RING( n ) do { \
+ ALIGN_RING(); /* TEST TEST */ \
if ( RADEON_VERBOSE ) { \
DRM_INFO( BEGIN_RING( %d ) in %s\n, \
n, __FUNCTION__ );\
}\
- if ( dev_priv-ring.space = (n) * sizeof(u32) ) { \
+ if ( dev_priv-ring.space = dev_priv-ring.size/2 /*(n+1) * sizeof(u32)*/ ) { \
COMMIT_RING(); \
- radeon_wait_ring( dev_priv, (n) * sizeof(u32) ); \
+ radeon_wait_ring( dev_priv, dev_priv-ring.size/2/*(n+1) * sizeof(u32)*/ ); \
}\
_nr = n; dev_priv-ring.space -= (n) * sizeof(u32); \
ring = dev_priv-ring.start; \
Index: drm/shared-core/radeon_cp.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_cp.c,v
retrieving revision 1.7
diff -u -3 -p -r1.7 radeon_cp.c
--- drm/shared-core/radeon_cp.c 19 Apr 2005 21:05:18 - 1.7
+++ drm/shared-core/radeon_cp.c 31 May 2005 19:29:50 -
@@ -846,6 +847,126 @@ static void
