newcons fb driver

[Bruce Evans]

On Tue, 4 Mar 2014, Justin Hibbits wrote:

> On Mon, Mar 3, 2014 at 2:33 PM, Bruce Evans <brde at optusnet.com.au> wrote:
>> Is newcons so much worse than syscons that it doesn't even have a
>> backing buffer?  Backing buffers are a fundamental part of virtual
>> consoles.  ...
>>
>> Why would newcons need to start supporting bytewise i/o now?  Hardware
>> was rarely broken enough to need it even in FreeBSD-1, and syscons has
>> always been sloppy about it.  ...
>
> Newcons does have a backing text buffer.  I'm not even sure how we got
> on topic of a text buffer, when my question was regarding the frame
> buffer (sys/dev/vt/hw/fb/vt_fb.c), specifically vt_fb_bitbltchr(), and
> consists of only the following:

Since it takes very large hardware pessimizations to give slowness
with a correctly implemented backing text buffer.  Newcons doesn't
seem to have one of those, even for vga (sys/dev/vt/hw/vga/vga.c)
where it has a character output routine.  vga supports text mode
using slow code, but I think it is only 2 times slower than syscons
in most cases.  Bitmapped mode with 16x8 characters and 256 colors
takes 128 bytes/character (most wasted for coloring individual pixels
in characters), so it is inherently 64 times slower than text mode.
vt_fb_bitbltchr() supports this.  It doesn't seem to be especially
pessimal, except for its per-char interface.  It seems to use bytewise
accesses a bit too much for simplicity, although it sometimes does
32-bit.  This should only give a further slowness factor of 2, 4 or 8
unless the frame buffer hardware is stupid.

vt_fb_setpixel() is an example of a really slow interface.  I thought
at first that vt_fb_bitbltchr() was much faster, but now see that it
is not much more than a wrapper around a manually inlined
vt_fb_setpixel().  The problems are easier to see in it.  Setting
pixels one at a time is too slow.  For 16x8 characters, that is at
least 128 memory accesses per character, and the interface prevents
merging these accesses.  vt_fb_bitbltchr() could do some merging, but
doesn't seem to do any.  Anyway, the support seems to be limited to
modes with 2**8, 2**16 or 2**32 colors, so that there are 1, 2 or 4
bytes per pixel.  For modes with < 8 bits per pixel, vt_fb_setpixel()
is even worse.  Maybe I misremember how colors are packed, but this
is very hardware dependent and I think vt only supports 1 simple type
of packing.

A correctly implemented backing text buffer consists of characters
(and possibly attributes) stored in fast memory in a form for copying
to a frame buffer, with the frame buffer in text mode.  A not so
correctly implemented backing text buffer is the same, except with
the frame buffer in pixel mode.  This is much more needed if the
frame buffer doesn't support text mode.

> * Does newcons support a background image, or is the mask there simply
> for drawing the text?
> * If it does support a background image, would it be good to
> double-buffer this, writing to the frame buffer only after the text is
> blitted?
> * If it doesn't support an image, would it be acceptable to prime the
> word to lay down with the background, and modify the pixels in the
> word accordingly?

I don't know what the mask does.  How would you lay down the background
much faster than with blitting?

> Without some kind of optimization, newcons on powerpc is unacceptably slow.

How slow is that exactly?  If the frame buffer speed is 50MB/S, then
16x8 characters with 256 colors can be written at 390K/S.  This is
acceptable.  If the frame buffer is much slower than that, then it is
too slow, at least without hardware scrolling.  Sample frame buffer
speeds:

my first PC (1982): 1MB/sec (slower through the CPU)
ISA ET4000: 2.4MB/sec read, 5.9MB/sec write
VLB ET4000/W32i: 6.8MB/sec read, 25.5MB/sec write
PCI S3/868: 3.5MB/sec read, 23.1MB/sec write
PCI S3/Virge: 4.1MB/sec read, 40.0MB/sec write
PCI S3/Savage: 3.3MB/sec read, 25.8MB/sec write
PCI Xpert: 5.3MB/sec read, 21.8MB/sec write
PCI R9200SE: 5.8MB/sec read, 60.2MB/sec write (but 120MB/sec through FPU)

I stopped measuring these speeds often about 20 years ago when they became
fast enough for simple i/o in text mode.  The last 2 are newer.  Read
speeds are still much lower for some reason (just the usual PCI slowness?).
This would amplify any slowness from the hardware doing read-modify-write
accesses for to convert to aligned 32/64/128/...-bit accesses.  I
think bit blitting can't do any better than the hardware by doing the
read cycles itself.  Everything needs to be buffered in fast memory
just to avoid reading slow memory.

Bruce