From owner-freebsd-arch@FreeBSD.ORG Mon Mar 3 14:21:48 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B776CC3 for ; Mon, 3 Mar 2014 14:21:48 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36416E06 for ; Mon, 3 Mar 2014 14:21:48 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so940686iec.30 for ; Mon, 03 Mar 2014 06:21:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gYuIoHtIKpe0fWzH8bWHjaJSPTqzKEDwyDIP1ZRFvHI=; b=QhT9CyM5LXLLOCVLvFOlGY4hDYR5raVGA/Z+r7NjtZxW3jncb41tKo8HAoH8xLMXtr ZGfo/554vpO3PcZiwOOXprklnJR8htdcbm6R5hr0F17xDdIuZUaMvujJPfQQHWE1DnW9 HKmfZsYJWj6vx4UO65mjRC7x27s08IuQepcgF7DKkFl2VlygCKu7R4WGGlMRy+pFEtMj rjsZADjhIawdbYtvU9p/1VATzT45HSqX5EdxBYfjI0gnCPi34Zts2ZMgZzp5rur9HOm/ +hZhzAJgGYp6V/3JUbOHiqN+RURXAHYC0UgsTRprjaW5jkqK0vqfUnWeyaO0y2YA99hK YfHg== X-Gm-Message-State: ALoCoQnVE3rPrUdRPz98xG5GLykCSnvwtbbbeK4P3IQlNHSlheHHo4et09MzBPDCRXIkRO/dox3n X-Received: by 10.50.253.70 with SMTP id zy6mr22233426igc.28.1393856507325; Mon, 03 Mar 2014 06:21:47 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id y9sm39651440igl.7.2014.03.03.06.21.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 06:21:46 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: newcons fb driver From: Warner Losh In-Reply-To: <53145E05.1070207@freebsd.org> Date: Mon, 3 Mar 2014 07:21:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140302085511.6354f9ac@zhabar.gateway.2wire.net> <53145E05.1070207@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1874) Cc: 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: Mon, 03 Mar 2014 14:21:48 -0000 On Mar 3, 2014, at 3:48 AM, Julian Elischer wrote: > 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: >>=20 >> (q) =46rom 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? >>=20 >> (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. >=20 > 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) >=20 > requires keeping the data in smaller subbuffers to track whether the = entire creen needs ot be updated. I know back in this kind of day the reason we had to do byte writes was = because 8-bit video cards would drop every other character if you did word writes of the same data=85 = But that=92s back in the earliest of the early days when 386sx-25=92s ran the face of the earth and 8-bit video = cards had not yet gone extinct=85 But I think that either a verify option or a simpler =91do single byte = writes=92 if the larger writes cause hangish problems. Since this is a big =91go uber-slow=92 option, we shouldn=92t = do it unless we really sure we need this. Warner >>=20 >> Thoughts? >>=20 >> - 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" >>=20 >=20 > _______________________________________________ > 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"