Mark Vojkovich wrote:
>
>
>
> 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.
>
Mark,
I think I've proved what you expected. Sending data to the ViRGE for
color expansion without checking the FIFO can lead to lockups. On an
AGP ViRGE GX2 I was getting much more frequent lockups with color
expansion which seemed to make sense, since AGP should have higher
throughput than the PCI cards. (We don't seem to have much trouble with
the PCI cards, at least not nearly as reproducible.)
I went into xaa and added FIFO checking during the color expansion data
writes. That seems to have removed lockups. In a separate trial I sent
FIFO slot free info to the log file and was able to see the FIFO fill to
only one empty slot on a couple occasions. I didn't run that test to
lockup because I doubt I'd actually see the data.
How about if we add an option to xaa for color expansion and imagewrites
that allows FIFO checking on data writes? The ViRGE docs make it clear
that such writes are FIFO bound and not direct memory writes.
Of course, whether or not a PCI bus disconnect or retry should occur is
another issue. I don't know if we have any control over that.
Kevin
-- [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/
