From owner-freebsd-arch@FreeBSD.ORG Thu Mar 6 04:21:19 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92CD2514; Thu, 6 Mar 2014 04:21:19 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 2289990E; Thu, 6 Mar 2014 04:21:18 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id F28551A28FA; Thu, 6 Mar 2014 15:21:10 +1100 (EST) Date: Thu, 6 Mar 2014 15:21:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Justin Hibbits Subject: Re: newcons fb driver In-Reply-To: Message-ID: <20140306133834.P2064@besplex.bde.org> References: <42130.1393829535@critter.freebsd.dk> <5314B2A2.3060100@pix.net> <60475.1393876211@critter.freebsd.dk> <20140304071445.Y3158@besplex.bde.org> <20140305230458.L1053@besplex.bde.org> <20140306013120.H1530@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=PqKqMW83 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=KxXyRG7pkqQyeGXE110A:9 a=Q858Yj1g5SAHSpJR:21 a=NmfiDTQT_qFu96JG:21 a=CjuIK1q_8ugA:10 Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 04:21:19 -0000 On Wed, 5 Mar 2014, Justin Hibbits wrote: > On Wed, Mar 5, 2014 at 7:02 AM, Bruce Evans 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