Subject: Re: wsdisplay on vesafb is slow
To: Aaron J. Grier <>
From: Michael Lorenz <>
List: current-users
Date: 12/26/2006 19:13:25
Hash: SHA1


On Dec 26, 2006, at 18:15, Aaron J. Grier wrote:

> On Tue, Dec 26, 2006 at 03:13:05AM -0500, Michael Lorenz wrote:
>>> has a PR been filed about the speed issue?
>> Do you have a fix for it? Or, do you have an idea how to fix it?
> I have spent a considerable amount of time optimizing framebuffer
> routines in Nano-X for a 25MHz embedded platform at work, so I've been
> through this before.

Good :)
I usually dealt with blitters so my experience in getting a dumb 
framebuffer fast is rather limited.

> the obvious first questions are:
> 1) how fast is video memory access (read/write)
> 2) how fast are {main,video} <-> {main,video} copies

In vesafb there's no hardware support for the latter so it would amount 
to two PCI or AGP transactions - one for reading, one for writing. 
Reading via AGP is considerably slower than writing.

> the rasops routines in dev/rasops appear to cover the corner cases,
> alignment, et al; I'm still not entirely sure why they would be so
> horrible unless every video memory access is traversing a VM86 trap or
> something similar.

Not sure, ofb on macppc ( which s essentially the same thing, the only 
difference is that the video hardware is set up by OF, not some VESA 
BIOS ) is usable although scrolling is still pretty slow. It seems to 
depend on the CPU though, a G3 with a PCI Rage II+ is much faster than 
a 603e with a c&t 65550. I have no idea how slow vesafb is - scrolling 
the whole screen by one line in 1024x768 in 8 bit on said G3 takes 
about half a second.

>   perhaps luke or jared could shed more light on the
> code?  (I'm still trying to figure out what I'm looking at and tracing
> code paths.)

Since Jared wrote vesafb that's pretty likely.

>> There are a few things we could do but those tend have side effects.
>> For instance, XFree86 uses a shadow framebuffer to avoid having to
>> read from video memory ( which is usually painfully slow ) - gives a
>> nice speed boost but costs memory, in vesafb's case kernel memory
>> which may or may not be acceptable. If I remember correctly Jared was
>> at least looking into supporting it but I'm fairly sure if it's there
>> it's not enabled by default.
> seems like a shadow framebuffer should be optional; keep a dirty
> rectangle, and spawn a kernel thread which does nothing but
> lock-and-flush the shadow framebuffer to hardware every X ms.  a shadow
> framebuffer might also make it possible to switch between multiple
> virtual framebuffers like we do now with multiple text wsconsoles...

Those aren't really virtual framebuffers ( although they could be )
Hmm, doing something like this could be interesting for ofb as well, or 
for a unified dumb fb driver I was going to write at some point.

>> Another thing would be to define a userland interface to switch video
>> modes and colour depth, then teach wsfb to use it.
> it looks like stubs for the calls are there, but the calls back to VESA
> BIOS aren't wired in?

wsdisplay drivers can define multiple 'text modes' which may or may not 
correspond to different video modes, as far as I know there's no 
ioctl() defined anywhere to switch to a given resolution/colour depth.

have fun
Version: GnuPG v1.2.4 (Darwin)