> 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
