On Sun, 26 Nov 2000, Kevin Brosius wrote:
> 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.
>
I don't have time, nor do I have any ViRGE hardware. I'm not sure
this is even fixable. You can use the indirect color expansion method
(the scanline stuff) like most of the other drivers do. Render into
system memory and then copy over manually in the SubsequentColorExpandScanline
function while making sure there's enough room in the fifo to take
that data. Hopefully, the fifo actually shows the progress of the
engine as it's taking the data in. If if doesn't that would suck.
Mark.
-- [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/
