Messages in this thread | | | Date | Sun, 29 Mar 1998 15:43:32 +0200 (MET DST) | From | Geert Uytterhoeven <> | Subject | Re: Fast scrolling on sparc [Re: GGI Project Unhappy On Linux] |
| |
On Sat, 28 Mar 1998, Pavel Machek wrote: > > > I've seen linux text-mode emulation on ultra-sparcs. There are not > > > many machines faster than ultra. It is *slow* compared to my 486 with > > > VGA. Even if you turn of hw scrolling on VGA it starts to be too > > > > The main reason is that text scrolling is done in FORTH under Open Firmware, > > which is an interpreted language (using FCode). > > Hmm, I did not know this one...
One minor correction: under Linux Linux takes care of the scrolling, it's done in the boot monitor using FORTH only.
> > But there are many ways to accelerate scrolling, all supported by fbcon (on > > some chipsets): > > > > - memcpy with the CPU (slow, mainly due to limited memory bandwidth. The PCI > > on my PPC is only 32 bit, 33 MHz). this is what is used if anything else > > fails > > I have a machine (sun4/330), which has beatiful monitor, but due to > simple hw, only memcpy with hardware is possible. Linux scrolls > rrrreeeallly slooowwllly on this one. (You can actually easily scan > for text.)
The way scrolling works in the Linux sun console driver is very similar to what was possible with GGI when I ported it to m68k. Since Suns have faster video hardware than Amigas, you now understand why I stayed with our own fast console driver :-)
> My idea was: what about not doing scroll at all? Just synchronize > screen with internal screen buffer every 100msec or so (something like > Xterm does). Yes, it would do ugly hops, but scrolling could no longer > eat 99% of CPU time. > > Imagine it this way: There are two things, framebuffer, and > shadow. Framebuffer is screen, shadow is memory (2bytes/character) (we > have it anyway, dunnno how it is called). There is counter of how many > modifications to shadow were done in last second. When there are too > many modifications, kernel gives up updating framebuffer. > > Then, there are two daemons. One on realtime priority, waking every > 500msec, second on lowest possible priority, running all the > time. Both do synchronize shadow with framebuffer. > > What do you think? This could accelerate scrolling many times...
That's indeed possible. Feel free to join the graphics console coder team :-)
Greetings,
Geert
-- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |