Re: SIS 630E perf problems?

[Rob Landley]

On Tuesday 07 August 2001 11:16, Larry McVoy wrote:
> > I've used a few funky SIS chipsets, on and off, for a long time now, and
> > they always have one leeeetle problem...
> >
> > Try benchmarking it with a lower screen resolution (like 640x480x256
> > colors). If the video is sharing main memory, it's sharing the memory
> > bandwidth as well.  So you've basically got a constant
> > ultra-high-priority DMA going to the screen, sucking up bandwidth and
> > fighting with everything else. (Everything else MUST lose or the display
> > would sparkle.
> > 1280x1024x32bitsx70hz is HOW much bandwidth we're talking here?)
>
> OK, a copuple of updates on this:
>
> I wasn't running X when I ran the benchmarks.
>
> I played around with the bios settings enough to make the machine not
> pass POST anymore so I reset the CMOS.  Doing that, plus telling the
> system to autodetect DRAM clocks dropped the latencies down to 260ns
> outside of X and 281ns with X running.  Still not fantastic but good
> enough I suppose.

Text mode still comes out of main memory, and is still a fairly consistent 
DMA out of it.  I suspect that for every pixel displayed, text mode or not, 
it still has to hit main memory.  Text mode goes through a lookup table 
thingy to max the character against the pixel grid for that character, but I 
suspect it still re-reads the value from main memory each time.

Even if it doesn't and instead caches the value (which, this being SIS, is 
probably wishful thinking: if that was the case they'd just devote 16k or so 
to the text mode circuitry and not have text mode share main memory at ALL, 
which I'm almost certain is NOT the case.  Again, optimizing for text mode 
ain't what a "for windows" hardware company thinks about, even when it's 
easy...)

Anyway, it's still doing nasty things with opening/closing memory banks 
(fighting with what would otherwise be linear burst transfers: we interrupt 
this DMA to seek to somewhere else in memory.  Yes, SIMMS have something like 
a hard drive seek, sending new addresses and opening/closing banks.  Ars 
technica had a nice article on this a while back I could dig up a link to if 
anybody's bored.  It's 1000 times faster than a hard drive seek, but it's 
still there.  The old latency vs throughput issue. Locality of reference is a 
good thing no matter what's going on.  And yes, making this go away and doing 
prefetch (and branch predictions, etc) are half of what the L1 and L2 caches 
do.  And the bus interface units did at least a few bytes read ahead all the 
way back to the 8086, actually.  (6 bytes for the 8086, 4 bytes for the 
8088.  Yes, I'm still writing a book on computer history.  Research 
crystalizing into chapters Real Soon Now (tm).  If I could just stop finding 
MORE info leading to fresh tangents to go down for a bit...  Or if the UT 
library didn't close between midnight and 8 am over the summer session...)

Rob