From owner-freebsd-arch@FreeBSD.ORG Mon Mar 3 10:48:44 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 87CAF61C for ; Mon, 3 Mar 2014 10:48:44 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D063763 for ; Mon, 3 Mar 2014 10:48:43 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s23Amg8u073647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 Mar 2014 02:48:43 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <53145E05.1070207@freebsd.org> Date: Mon, 03 Mar 2014 02:48:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: newcons fb driver References: <20140302085511.6354f9ac@zhabar.gateway.2wire.net> In-Reply-To: <20140302085511.6354f9ac@zhabar.gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 03 Mar 2014 10:48:44 -0000 On 3/2/14, 8:55 AM, jhibbits@freebsd.org wrote: > I've been looking into the slowness of the newcons framebuffer backend, > and after discussing with Nathan Whitehorn, we've determined that the > slowness is caused by single byte writes to the framebuffer, which are > very much suboptimal. His conclusion is that, on nVidia hardware, the > card first performs a read, a very slow operation on the hardware, then > a single-byte write, and I'm thinking the same. So, to accomodate this > limitation, I have a question and proposal: > > (q) From looking at the code, it appears to support, to some degree, a > background image (the character blitting uses a mask, it doesn't just > write background in that mask). Is this truly the case? > > (p) If it is the case that it supports a background image, I'm thinking > it would make sense to buffer the framebuffer, such that we write to > the internal representation, and blit whole words or lines at a time > to the hardware. With an 8-bit buffer, at 1920x1080 (common resolution) > we would be using approximately 2MB for the buffer. On memory > constrained devices this can be quite significant, so it becomes a > tradeoff. oh how history repeats itself.. hit this in the newcons driver (never completed) in 1993. the oldest hardware had this problem.. solution: keep a virtual framebuffer and update the hardware (only lines that changed) on 1/50 of a second ticks... (or some other timer value faster than that) requires keeping the data in smaller subbuffers to track whether the entire creen needs ot be updated. > > Thoughts? > > - Justin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >