Am Samstag, 03. Januar 2004 04:52 schrieb Felix Kühling:
> Hi,
>
> this is referring to the a very reproducable lockup that occurred with
> glaxium on r100 hardware. Several months ago I tracked it down to
> emission of state changes and introduced a workaround that waits for 3D
> idle before state changes. Now I had a new idea about a possible cause
> of trouble: the order in which state atoms are emitted. And it appears I
> was right. :) I made a small hack that forces state attoms to be emitted
> in a fixed order and dropped the wait for 3D idle. The lockups are still
> gone and frame rates have increased significantly.
>
> A patch is attached. The order in which state atoms are emitted now is
> pretty arbitrary. It may be worth finding out exactly which permutations
> of state changes trigger the lockup. In the interest of security we
> could detect them in the DRM driver and emit a 3D idle to prevent an
> engine lockup. Finding all these permutations would take a lot of time
> (and reboots) though and it may even be too late to prevent a lockup
> when such a condition is detected. But maybe someone with hardware docs
> has a good guess, like dependencies of different state change commands
> that could cause inconsistencies if certain pairs of them are emitted in
> the wrong order.
>
> On the other hand we may just clean up my hack and be content with it.
> How do people feel about this?
Do you think that this could be useful for r200, too?
Greetings,
Dieter
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
