Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Mar 2014 15:21:08 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Justin Hibbits <jhibbits@freebsd.org>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org
Subject:   Re: newcons fb driver
Message-ID:  <20140306133834.P2064@besplex.bde.org>
In-Reply-To: <CAHSQbTDxX=XPcKYmA-7pLa8n9xi2izKrJAEtuzonCU1X6jxadA@mail.gmail.com>
References:  <42130.1393829535@critter.freebsd.dk> <5314B2A2.3060100@pix.net> <CAHSQbTBTq6EKD_crn=rvbeUcAEBn7E%2B=U8wRHeqchazF1LhjwQ@mail.gmail.com> <60475.1393876211@critter.freebsd.dk> <20140304071445.Y3158@besplex.bde.org> <CAHSQbTB3FwMDo01LuWvd4zN%2BYHzbDSVHqfiYGeRCnb0iqCkBmA@mail.gmail.com> <20140305230458.L1053@besplex.bde.org> <20140306013120.H1530@besplex.bde.org> <CAHSQbTDxX=XPcKYmA-7pLa8n9xi2izKrJAEtuzonCU1X6jxadA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Mar 2014, Justin Hibbits wrote:

> On Wed, Mar 5, 2014 at 7:02 AM, Bruce Evans <brde@optusnet.com.au> wrote:
>> On Thu, 6 Mar 2014, Bruce Evans wrote:
>>
>>> On Tue, 4 Mar 2014, Justin Hibbits wrote:
>>>>
>>>> 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.
>>
>> I forgot to mention that u$ doesn't solve this problem in WinXP.  The
>> speed is not too bad in normal mode (only about 30 times slower than
>> syscons - the scrolling speed is 30000 lines/second instead of 1000000).
>> But in safe mode, a simple graphics driver is used and it is horribly
>> slow.  Safe mode with command prompt gives an MSDOS prompt in a
>> maximized terminal window, so the problem is very noticeable (the
>> scrolling speed is 4 lines per second = 12 seconds per screenful).
>> Apparently normal mode uses acceleration to be not very slow, but safe
>> mode is too simple to do that.  The FreeBSD console driver needs to
>> be even simpler so that it works as a low level console.

This hardware can do 120 MB/s with 64-bit writes.  The window size in safe
mode was 80x48 (I think with 16x8 characters).  The number of pixels to move
for dumb scrolling of a screenful is this 80x48*x16*8*48 ~= 23.5 million.
I don't know if the mode is 256 colors, but assume that.  So there are
23.5 million bytes and they should be moved in about 0.2 seconds instead of
12.  Probably many of the following pessimizations are applied:
- halve the speed by not using a backing buffer but reading the data to be
   scrolled from the frame buffer.  0.4 seconds at least.  Probably much
   more.
- use 8-bit accesses instead of 64-bit ones.  Probably 8 times slower (see
   below).  3.2 seconds
With a bit more work, 12 seconds can probably be attained.  The 6
times slower read speed measured below on different hardware
would do it easily.

On a laptop that is likely to have a faster frame buffer and a more
customized BIOS (I suspect safe mode uses the BIOS), the scrolling
speed in safe mode is 3-4 times faster.

> The ofwfb syscons driver is much faster than newcons, so a frame
> buffer can be made relatively fast (within reason).  It's newcons
> that's slow, and my assumption currently is the byte-oriented writes
> instead of word size.

I suspect syscons is doing fewer updates, but the potential slowdowns
are indeed very large:

On my test hardware (AGP GeForce2 GTS; not quite the same as used
above; slower), I get an almost perfectly linear slowdown as the access
sizes decreases: for writing 100MB of data (50M characters in text
mode):
     64 bits: 1.37 seconds
     32 bits: 2.35 seconds  (42.5MB/sec)
     16 bits: 4.70 seconds
      8 bits: 9.40 seconds
For reading:
     32 bits: 14.5 seconds  (6.9MB/sec)
      8 bits: 58.1 seconds
Reading is 6 times slower, so using 8-bit accesses instead of 64-bit
ones doesn't just pessimize by a factor of 8 if it causes the hardware
to do a read for every write.  With the above timing, it changes from
1.37 seconds to 9.40 + 58.1 = 67.5 seconds (49 times slower).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140306133834.P2064>