>Are you using fbcon? If so, and if it goes away after starting X, then it
>is the "fbcon kills interrupt latency" problem.
Ug!!! This is getting bad. Give me some time. I plan on releasing a new
vesafb using MMX to help speed up the drawing routines. It will help alot
with the latency issues. I also know using ARM assembly we can greatly
reduce the latency issues.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
James Simmons wrote:
> Ug!!! This is getting bad. Give me some time. I plan on releasing a new
> vesafb using MMX to help speed up the drawing routines. It will help alot
> with the latency issues. I also know using ARM assembly we can greatly
> reduce the latency issues.
There is another issue with vesafb. It tries to use an MTRR, but this
fails for the 2.5MB region that is video RAM because 2.5MB is not a
power of two.
The console driver does not actually use 2.5MB. Does it make sense to
use an MTRR for the smaller power-of-two region?
-- Jamie
James Simmons wrote:
>
> >Are you using fbcon? If so, and if it goes away after starting X, then it
> >is the "fbcon kills interrupt latency" problem.
>
> Ug!!! This is getting bad. Give me some time. I plan on releasing a new
> vesafb using MMX to help speed up the drawing routines. It will help alot
> with the latency issues. I also know using ARM assembly we can greatly
> reduce the latency issues.
On console speedups: back in the old days, scrolling a subregion of the
text console to be _really_ slow on some machines. I am talking about
text mode now, not framebuffer mode. On some cards, text mode is
actually very very slow and the framebuffer is faster. It took *2
seconds* to scroll a 50 lines of text 50 times on my 200MHz PPro system
4 years ago. So less "back one screen" took 2 seconds. And Emacs uses
"scroll region by N lines" a lot. In those days, "N lines" scrolls
actually did N x 1 line scrolls, so text mode was really a burden on
that machine. I took to using X, with a single screen size xterm to
present the illusion of console mode.
Well, nowadays on my laptop we have the joy of the framebuffer console.
Nice penguin aside, it means I get a console on the full screen area.
But it is nearly as slow at scrolling as my old 200MHz PPro.
Probably the lack of hardware area copies has something to do with
this. However, who isn't familiar with xterm "jump scroll" mode?
That's nice and fast.
Could such a thing be implemented in the console driver?
cheers,
-- Jamie
Hi!
> > >Are you using fbcon? If so, and if it goes away after starting X, then it
> > >is the "fbcon kills interrupt latency" problem.
> >
> > Ug!!! This is getting bad. Give me some time. I plan on releasing a new
> > vesafb using MMX to help speed up the drawing routines. It will help alot
> > with the latency issues. I also know using ARM assembly we can greatly
> > reduce the latency issues.
>
> On console speedups: back in the old days, scrolling a subregion of the
> text console to be _really_ slow on some machines. I am talking about
> text mode now, not framebuffer mode. On some cards, text mode is
> actually very very slow and the framebuffer is faster. It took *2
> seconds* to scroll a 50 lines of text 50 times on my 200MHz PPro system
> 4 years ago. So less "back one screen" took 2 seconds. And Emacs uses
> "scroll region by N lines" a lot. In those days, "N lines" scrolls
> actually did N x 1 line scrolls, so text mode was really a burden on
> that machine. I took to using X, with a single screen size xterm to
> present the illusion of console mode.
>
> Well, nowadays on my laptop we have the joy of the framebuffer console.
> Nice penguin aside, it means I get a console on the full screen area.
>
> But it is nearly as slow at scrolling as my old 200MHz PPro.
You have same toshiba satellite as me, right?
> Probably the lack of hardware area copies has something to do with
> this. However, who isn't familiar with xterm "jump scroll" mode?
> That's nice and fast.
>
> Could such a thing be implemented in the console driver?
I believe so. It would be simple: if there's too much activit, defer
framebuffer updates and only update in-memory copy. Sync from time to
time. I'd certainly like to see that.
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
Hi!
> > Ug!!! This is getting bad. Give me some time. I plan on releasing a new
> > vesafb using MMX to help speed up the drawing routines. It will help alot
> > with the latency issues. I also know using ARM assembly we can greatly
> > reduce the latency issues.
>
> There is another issue with vesafb. It tries to use an MTRR, but this
> fails for the 2.5MB region that is video RAM because 2.5MB is not a
> power of two.
>
> The console driver does not actually use 2.5MB. Does it make sense to
> use an MTRR for the smaller power-of-two region?
I had patch which tried that at one point. Just try all 2^n numbers
<= size until it succeeds.
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
Pavel Machek wrote:
> You have same toshiba satellite as me, right?
Yes.
-- Jamie