Mark Vojkovich wrote:
>
>
>
> On Sun, 26 Nov 2000, Kevin Brosius wrote:
>
> >
> > I suppose we could add an option, something like 'early_sync' (or maybe
> > something more descriptive) which changes the accelerator sync behavior
> > in 4.0.x drivers to make them behave more like 3.3.6. I'd be willing to
> > make a trial s3virge driver with a change like this so you could test
> > it.
>
> I think the biggest problem is that color expansion data with
> the Virge driver is *always* sent to the hardware without making
> sure there is enough room in the fifo for it. The engine seems
> to be designed to rely on retries for this type of operation.
>
Really? That might explain why the ViRGE GX2 still has lockup trouble
with the accel. color expansion functions. I was just about to disable
them for GX2 until/if we could fix them. Do you have any time to look
at this for Virge? I'll take a look myself, as I have a GX2 card I'd
like to see stabilized.
> >
> > Mark,
> > I'm thinking of adding AccelSync commands to all the Subsequent
> > accelerated primitives and enabling them on an option. That should get
> > us close to the 3.3.6 architecture in a switchable way.
>
> All the rest of the routines seem to be waiting for the fifo
> just fine. I expect you'd get rid of most of the symptoms by
> just disabling color expansion.
>
> Mark.
>
So they could add an:
Option "XaaNoCPUToScreenColorExpandFill"
For testing purposes and see if the problem goes away. (I've been
testing color expansion lockup cases on GX2.)
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
