Re: OpenGL-based framebuffer concepts

["Antonino A. Daplas" <adaplas@gmail.com>]

David Lang wrote:
> On Sun, 28 May 2006, Jon Smirl wrote:
> 
 > in part this dates back to my early experiances with the framebuffer
> code when it was first introduced, but I still find that the framebuffer
> is not as nice to use as the simpler direct access for text modes. and
> when I start X up it doesn't need a framebuffer, so why suffer with the
> performance hit of the framebuffer?

This might be true with the framebuffer in 2.2 and 2.4, but you may want
to reconsider in 2.6:

time cat linux/MAINTAINERS

vgacon (80x25 or 640x400, CONFIG_VGACON_SOFT_SCROLLBACK=n)

real    0m0.637s
user    0m0.000s
sys     0m0.637s

vesafb 640x480-8 (vga=0x305 video=vesafb:ypan,mtrr:3)

real    0m0.572s
user    0m0.001s
sys     0m0.571s

vesafb 640x480-8 (vga=0x305 video=vesafb:ypan,mtrr:3,vremap:4)

# vremap:4 gives approximately 12 extra pages of text for hardware
# scrolling, vgacon has 16.

real    0m0.409s
user    0m0.001s
sys     0m0.408s

So even a dumb driver such as vesafb that has to do on the fly
color conversions while pushing 64x more data to the bus can be
faster than vgacon.

Note the above is true for x86_32. For x86_64 and ia64, vesafb will
be slow because in it cannot do ypan in these archs.

But using a chipset specific driver on any arch, you can achieve a
fivefold increase:

nvidiafb 640x480-8 accel=true

real    0m0.145s
user    0m0.001s
sys     0m0.144s

> 
> yes, some hardware requires a framebuffer to display anything, but for
> most video cards, the hardware scrolling of a pure text mode is better
> (faster, smoother, less cpu required, etc) then the framebuffer equivalent.

A framebuffer driver can be faster than vgacon.  Scrolling is also smooth
even for vesafb because of a new scrolling method (pan_redraw) introduced
sometime in 2.6.10.  I don't know about less cpu required, that's probably
true.

Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/