-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

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
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRZG6pcpnzkX8Yg2nAQIY8wgAmE/Rqv86sUR+aPIPKj+1WJ+Pk3PxKYEC
c8eBrl9U+EEMmNigEXUz0W5yEgoa6xq1g50F5DOXs8/Ishh4fHeym1nmaLbKCmYW
sHkxfGh6Ad8VSYkLOw90BzBrkTuMJ0Gh96vKXVvY/w6QPmKaKuEM5Y/hHwlA1V0P
18XMas+6kff4ypcpUIRH1o4ko/ZCq4qLNAh3qTtP5qX6r5Jxxx7k/emBc+6+9SvZ
mVgD3mXQbte1oedaT/PHDGcXymN+5SEPqNOHhCyQca/CGfsFFdQSkTayebUSAT7b
jIC+OYAZjChWm0L+gqFFRexO1mn73CHJd0vBVltzIpm9HEN7s1wIBA==
=ScEu
-----END PGP SIGNATURE-----