newcons fb driver

[Adrian Chadd]

I think the whole thread here is "this crap may not be needed for
framebuffer modes."

So, maybe for newcons-in-text-mode, you need the 8 bit writes but
newcons-in-FB-mode you can get away with 32 bit writes.

What would be nice would be to add some boot time checks to see if you
can write 32 bit test patterns and then read them back in 8, 16, 32
bit chunks. See if they match. If they do, great. If they don't, then
you need to downgrade.

But the other thing is whether it's slow because you're doing
scrolling/painting using copy operations on a very large/deep buffer,
or whether you're doing anything hardware accelerated. Is newcons
taking advantage of doing things like hardware-assisted scrolling,
blitting/copying, copy-and-mask operations, updating only part of the
screen if the backing text buffer changes, etc?


-a


On 4 March 2014 17:00, Justin Hibbits <jhibbits at freebsd.org> wrote:
> 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
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"