newcons fb driver

[Warner Losh]

On Mar 3, 2014, at 3:48 AM, Julian Elischer <julian at freebsd.org> wrote:

> On 3/2/14, 8:55 AM, jhibbits at 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.

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…  But that’s back in the earliest of the
early days when 386sx-25’s ran the face of the earth and 8-bit video cards had not yet gone extinct…

But I think that either a verify option or a simpler ‘do single byte writes’ if the larger writes cause hangish
problems. Since this is a big ‘go uber-slow’ option, we shouldn’t do it unless we really sure we need this.

Warner

>> 
>> Thoughts?
>> 
>> - Justin
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>> 
> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"