Re: fbcon slowness [was NTP on 2.4.2?]

Re: fbcon slowness [was NTP on 2.4.2?]

[James Simmons]

>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  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: fbcon slowness [was NTP on 2.4.2?]

[Jamie Lokier]

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

Re: fbcon slowness [was NTP on 2.4.2?]

[Pavel Machek]

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+

Re: fbcon slowness [was NTP on 2.4.2?]

[Jamie Lokier]

Pavel Machek wrote:
> You have same toshiba satellite as me, right?

Yes.

-- Jamie

Re: fbcon slowness [was NTP on 2.4.2?]

[Jamie Lokier]

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

Re: fbcon slowness [was NTP on 2.4.2?]

[Pavel Machek]

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+

Re: fbcon slowness [was NTP on 2.4.2?]

[James Simmons]

>I had patch which tried that at one point. Just try all 2^n numbers
><= size until it succeeds.

Hum. Is this the only way we can solve this problem? I assume you end of
with most of but not all the video memory using MTRR then. Kind of sucks!!

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  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: fbcon slowness [was NTP on 2.4.2?]

[James Simmons]

>> 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.

If the time between syncs gets to big then the amount of data to go over
the bus would kill performance. Plus this has the problem that even
small areas like 12x20 areas become more expensive as the bpp increases. A
better solution is to implement accelerated copyareas. In fact for 2.5.X I
have the fbcon system wrapped around using accels instead of writing to the
framebuffer directly. I have had enormous improvements doing this. Plus
using this approach makes the fbcon layer much simpler and smaller in size.
Thus better performace overall.

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  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net