From owner-freebsd-arch@FreeBSD.ORG Wed Mar 5 01:00:41 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 7E0F5B60 for ; Wed, 5 Mar 2014 01:00:41 +0000 (UTC) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3ACC1699 for ; Wed, 5 Mar 2014 01:00:41 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id hq11so337637vcb.0 for ; Tue, 04 Mar 2014 17:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+MGyzf2PIaCrGnN4QgNeET1jB+byo+4HvjqNwhgcOlc=; b=t8nr65aP6dT4o9CgJrSmGMmmJUZEhSHDB7Np+yr9LQDIexEZkW1LsJ3aLuH/R4sJ8G S05Qx++/35q3xhDiw3AqXpmMHpu9Y0f799DgNsCMeiWx7S5i14ygVU//v/KsZOv5cIWw oAf7vch7Sy7GBpCbg6cE1p+rPfV+pEPVDUtYVksdkRmtd9EGMH2gwsIy2FHeN0CakZQm ILh8EUxkTb6sWBiDsEct5kjfGhYuKJw8nnj/RkVbKBwJVlNVnU4rA4tFE0nkeNlCxdjr je6oat15mpL1cHe8XLMKxMb6Ns2xv7MQgeSKSM8mhAqGUU4WnOjCPU82qtQNYmTzxImU ErHA== MIME-Version: 1.0 X-Received: by 10.52.190.1 with SMTP id gm1mr1768734vdc.21.1393981240223; Tue, 04 Mar 2014 17:00:40 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.58.133.193 with HTTP; Tue, 4 Mar 2014 17:00:40 -0800 (PST) In-Reply-To: <20140304071445.Y3158@besplex.bde.org> References: <42130.1393829535@critter.freebsd.dk> <5314B2A2.3060100@pix.net> <60475.1393876211@critter.freebsd.dk> <20140304071445.Y3158@besplex.bde.org> Date: Tue, 4 Mar 2014 17:00:40 -0800 X-Google-Sender-Auth: GmH0iGmlfb8niWinFvch1tg6dxU Message-ID: Subject: Re: newcons fb driver From: Justin Hibbits To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 05 Mar 2014 01:00:41 -0000 On Mon, Mar 3, 2014 at 2:33 PM, Bruce Evans wrote: > On Mon, 3 Mar 2014, Poul-Henning Kamp wrote: > >> In message >> >> , Justin Hibbits writes: >>> >>> On Mon, Mar 3, 2014 at 8:49 AM, Kurt Lidl 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=C3=B8ren 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