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
