Hello,

Here's the comparison of various drivers for LCG and LCSPX, performing
typical time-consuming console task (lots of scrolling and rendering):

LCG results were obtained on 4000/VLC at 1024x864, LCSPX results come
from 4000/90A at 180x1024. Michael Hitch was the man to do the testing,
thanks alot Mike !!!

LCG:
cat estruct.h - software render - 248.12 real 0.03 user 246.59 sys
cat estruct.h - hardware render - 170.38 real 0.02 user 169.14 sys
cat estruct.h - fifo     render -  83.87 real 0.04 user  81.31 sys
cat estruct.h - fifo     render -  82.21 real 0.04 user  81.72 sys
cat estruct.h - fifo     sleep  -  87.19 real 0.05 user   7.59 sys

LCSPX:
cat extruct.h - software render - 1589.11 real 0.00 user 1584.75 sys
cat estruct.h - hardware scroll -   85.07 real 0.01 user   84.92 sys

"Software render" means fonts was rendered in software (and scrolling
was done in software too, using memcpy/memset). "Fifo" among LCG results
means that HW acceleration was used (as was in the "hardware render"
case). "Hardware render" was (IIRC) with hardware scrolling and
rendering but FIFO was operating in short circuit mode (so kernel had to
sit idle until address generator was done). 4rd and 4th LCG result use
FIFO in normal mode and 5th result IIRC uses FIFO in normal mode and
interrupts to detect FIFO state so kernel doesn't just sit idle checking
FIFO status once it's filled up but can perform other tasks.

LCSPX results are really surprising; first one comes from ragge's old
LCSPX driver and second one comes from modified LCG-like driver (with
user-settable font support, full palette support, more stuff that deals
with interfacing to X, etc.) which renders fonts in software but uses
hardware for scrolling. Kernel sits idle (polling status) while address
generator is busy on LCSPX because i have no docs on LCSPX and i have
absolutely no idea as to whether that thing supports interrupt-driven
interface like LCG or not. 

I'll keep you guys posted. lcspx.c will be published on the vax-dev
webpage when i'm satisfied with it, shouldn't be that long even though
i'm takin ga couple of days break from coding now. It is a drop-in
replacement for existing lcspx.c so there should be no problems about
people using it instead (until it makes it into the kernel source tree).

Blaz Antonic
-- 
Hi! I'm a signature virus!
Copy me into your signature to help me spread!