Date: Mon, 3 Mar 2014 07:21:45 -0700 From: Warner Losh <imp@bsdimp.com> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: newcons fb driver Message-ID: <C16A9BB9-124D-4892-846C-D7985B629797@bsdimp.com> In-Reply-To: <53145E05.1070207@freebsd.org> References: <20140302085511.6354f9ac@zhabar.gateway.2wire.net> <53145E05.1070207@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 3, 2014, at 3:48 AM, Julian Elischer <julian@freebsd.org> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C16A9BB9-124D-4892-846C-D7985B629797>