newcons fb driver

[Julian Elischer]

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.

>
> 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"
>