newcons fb driver

[Justin Hibbits]

On Mon, Mar 3, 2014 at 2:33 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Mon, 3 Mar 2014, Poul-Henning Kamp wrote:
>
>> In message
>> <CAHSQbTBTq6EKD_crn=rvbeUcAEBn7E+=U8wRHeqchazF1LhjwQ at mail.gmail.com>
>> , Justin Hibbits writes:
>>>
>>> On Mon, Mar 3, 2014 at 8:49 AM, Kurt Lidl <lidl at pix.net> wrote:
>>
>>
>>> All great knowledge, but really only answers half of what I'm looking
>>> for (always good to know potential pitfalls).  Assuming a
>>> tunable/sysctl is added, what's the best way to optimize from my
>>> original post?  Use a backing buffer (potentially with a tunable to
>>> not)?  Or assume we don't support background images, and write the
>>> background color in the masked pixels?
>>
>>
>> You should probably drop sos@ aka Søren Schmidt an email, he did
>> syscons and has 10+ years experience in this stuff.
>>
>> One advantage of a backing buffer is that you can implement things
>> like the 1000 line scroll buffer syscons did etc, I personally use
>> that a lot to see dmesg output etc.
>
>
> 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.  Only one virtual console at a time uses the frame buffer,
> and the output to the others is virtual.  Output to the one using the
> frame buffer is not much different to output for others when they are
> switched to active.  The output should be delayed as long as possible
> to give a refresh rate faster than anyone's eyes can notice.  100-200
> Hz is adequate, but I try to make it thousands of times faster than
> that so that 100% of 1 CPU isn't needed for screen output.  syscons
> in an old version of FreeBSD now gives me i/o speeds of 26MB/S to an
> active console and 29MB/S to an inactive console.  In text mode of
> course.  That is quite slow even for 10+ year old hardware that it was
> re-tested on (old tests gave approximately the frame buffer speed and
> I mostly stopped running them when frame buffers got fast enough for
> text).  Except with 20+ year old hardware, the frame buffer speed makes
> little difference in this test.  Graphics mode is harder to make
> acceptably fast.
>
> 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.  i386 (but not amd64) has a bogus function
> bcopyb() for doing such i/o.  This was used mainly by the 4+ (3+ too
> many) console drivers in 386BSD, FreeBSD-1 and/or FreeBSD-2.0.  syscons
> never used it.  In FreeBSD-4, it was used by pcvt.  pcvt used it only
> for the character set initialization where speed is unimportant.  Now
> bcopyb() still exists, but is never used.
>
> Another reason that bcopyb() is bogus is that i/o should be done using
> bus space.  dev/fb still has many hacks to avoid using bus-space.  Only
> ia64 is clean there.  Other arches use massive ifdef tangles to do
> things wrong.  Old versions of x86 used mostly bcopy() on frame buffers,
> but now use a home made 16-bit copying function.  arm and mips still
> use bcopy() but misspell it memcpy().
>
> Bruce

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:

* 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?

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

- Justin