Hello,

I've picked up my work with LCG HW acceleration where i left it few
months ago; i can now inject command packets into FIFO (at least small
number of them, i haven't tried to fill the FIFO entirely yet to see
whether it wraps around correctly) and i have two basic functions
working - one is block copy (memcpy(), except that it can handle visual
blocks of framebuffer memory, such as rectangles on the screen, not just
linear memory like memcpy() does) and the other one is bitwise rasterops
function (it can perform any of the 16 basic operations on a rectangle
with stencil, like copy, clear, set, AND, OR, XOR, etc.).

Block copy function is good enough for console scrolling use (since our
rectangle always starts at the start of each line) but i have yet to
figure out how to copy blocks around the screen (like moving windows
under GUI). Bitwise ops seem work perfectly though, i just set address
of top left pixel of rectangle, its dimensions, stencil to be used and
operation to be performed and it just works, which means blanking (or
setting, etc. depending on the operation to be executed) a rectangle in
the middle of the screen is just as easy as blanking entire screen.

In plain english: this means VS 4000 VLC and model 60 will have HW
acceleration support added to console code which should (hopefully)
speed up scrolling, blanking, etc., the most commonly used operations on
large amounts of data that were now performed by the CPU. I have
absolutely no experience with X servers so i cannot integrate any of
that stuff into one (or write one from scratch). If anybody happens to
have 4000 VLC/M60 and is willing to do X server work i can send him the
relevant information. I suppose console driver will have to provide
access to FIFO to external applications (like it does now for
framebuffer memory to wscons X server) and X server will either scriblle
in framebuffer or (when speedup can be achieved) send command packet
sequence to do the work for it.

There is a matter on which opinions would be welcome: one obvious use
for block copy is also to save the time rendering font glyps; there
should be enough off-screen framebuffer memory to store pre-rendered
font glyps there and just copy them in when needed. However, each
command packet sequence that does something useful is 16-20 longwords in
size which means up to 80 bytes of data that has to be sent to the FIFO
in order to copy a single glyph; i have found functions that don't do
block copy (byte for byte) but seem to render text directly - bitmap (as
opposed to "bytemap" for direct copy mentioned above) must be supplied
and glyph is apparently rendered using foreground and background color -
i haven't even tried those one out yet so i'm not sure whether (and how)
it works. This will therefore have to wait - do you guys think it's
worth pursuing this at all, considering the fact that even the LR model
(with only 1 MB of framebuffer memory) has 160 KB of off-screen
framebuffer memory, 640 bytes per font glyph in 256-entry set ? The
biggest console fonts i could ever desire on my box are 32x16, this
would still leave 20% of off-screen memory free. And no, i don't have
any benchmarks yet so i don't know whether byte for byte copy is faster
than in-hardware rendering.

Speaking of benchmarks, i found like 3 copy functions so far, i'm not
sure which one to use :) They are quite similar, except for few flags
(and that one takes # of bits to be copied rather than # of bytes as
parameter). I don't know which one is faster and with my kludgy
implemenattion at the moment i have no way of testing them out.

Last, but not the least: could somebody please fix a bug in
arch/vax/include/lcgreg.h ? Look for LCG_REG_RESIDUE_LW0 and LW1, their
addresses are incorrect. LW0 is at offset d04, LW1 is at offset d08 and
LW2 is (correctly set) at offset d0c. There is nothing at offset d00, to
the best of my knowledge.

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