Reading from /dev/fb0 very slow?

Reading from /dev/fb0 very slow?

[Pavel Machek]

Hi!

I did some benchmarks, and my framebuffer is *way* faster when writing
than when reading:

root@bug:/home/pavel# time cat /tmp/test > /dev/fb0
0.01user 0.08system 0.09 (0m0.097s) elapsed 93.13%CPU
root@bug:/home/pavel# time cat /dev/fb0 > /dev/null
0.00user 0.62system 0.62 (0m0.620s) elapsed 99.93%CPU
root@bug:/home/pavel#

That is 6 times slower! This is also very visible in X, where moving
regions is expensive, while just drawing regions is fast. For example
gnome-terminal is *way* faster *with* transparent background option.

Any idea why such assymetry? [This is toshiba 4030cdt with vesafb and
2.4.5]

								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Reading from /dev/fb0 very slow?

[Jeff Garzik]

Pavel Machek wrote:
> 
> Hi!
> 
> I did some benchmarks, and my framebuffer is *way* faster when writing
> than when reading:
> 
> root@bug:/home/pavel# time cat /tmp/test > /dev/fb0
> 0.01user 0.08system 0.09 (0m0.097s) elapsed 93.13%CPU
> root@bug:/home/pavel# time cat /dev/fb0 > /dev/null
> 0.00user 0.62system 0.62 (0m0.620s) elapsed 99.93%CPU
> root@bug:/home/pavel#
> 
> That is 6 times slower! This is also very visible in X, where moving
> regions is expensive, while just drawing regions is fast. For example
> gnome-terminal is *way* faster *with* transparent background option.
> 
> Any idea why such assymetry? [This is toshiba 4030cdt with vesafb and
> 2.4.5]

Do you have write combining enabled?

-- 
Jeff Garzik      | Echelon words of the day, from The Register:
Building 1024    | FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 
MandrakeSoft     | Steak Knife Kill the President anarchy echelon
                 | nuclear assassinate Roswell Waco World Trade Center

Re: Reading from /dev/fb0 very slow?

[Alan Cox]

> I did some benchmarks, and my framebuffer is *way* faster when writing
> than when reading:

That is quite normal.

> That is 6 times slower! This is also very visible in X, where moving
> regions is expensive, while just drawing regions is fast. For example
> gnome-terminal is *way* faster *with* transparent background option.
> 
> Any idea why such assymetry? [This is toshiba 4030cdt with vesafb and
> 2.4.5]

Writes to a PCI device can be queued or posted. Reads from a PCI device for
obvious reasons have to stall the CPU until the data returns. 

Re: Reading from /dev/fb0 very slow?

[Pavel Machek]

Hi!

> > I did some benchmarks, and my framebuffer is *way* faster when writing
> > than when reading:
> 
> That is quite normal.

Unfortunately, at least X and few framebuffer modes can not survive
that too well.

vesafb ypan mode attempts to do video-to-video copy, which is slow.
Xserver attempts that, too. 

> > That is 6 times slower! This is also very visible in X, where moving
> > regions is expensive, while just drawing regions is fast. For example
> > gnome-terminal is *way* faster *with* transparent background option.
> > 
> > Any idea why such assymetry? [This is toshiba 4030cdt with vesafb and
> > 2.4.5]
> 
> Writes to a PCI device can be queued or posted. Reads from a PCI device for
> obvious reasons have to stall the CPU until the data returns. 

But they can't be posted indifinitely, right? I'm copying whole
framebuffer at a time, I do not believe PCI has enough buffers to
cache *that*. [Or is it using some kind of burst mode it can not use
for reading? That does not give a sense, you can cache reads, too....]

-- 
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: Reading from /dev/fb0 very slow?

[Alan Cox]

> Unfortunately, at least X and few framebuffer modes can not survive
> that too well.

Actually most X servers are heavily optimised to avoid video->video copies and
use the accelerators. If you are using the frame buffer X server then yes
it can be a problem but look up 'shadowfb'.

> > Writes to a PCI device can be queued or posted. Reads from a PCI device for
> > obvious reasons have to stall the CPU until the data returns. 
> 
> But they can't be posted indifinitely, right? I'm copying whole
> framebuffer at a time, I do not believe PCI has enough buffers to
> cache *that*. [Or is it using some kind of burst mode it can not use
> for reading? That does not give a sense, you can cache reads, too....]

Your writes are running at bus speed. Assuming the video ram has an mtrr for
write combining you are doing full bursts. When you read the sequence instead
is

	issue read
	stall cpu
	pci cycle goes out for one longword
	pci cycle hits the video card
	video card replies a longword
	cpu gets it

So the entire pci bus latency is directly biting you for each fetch.

Alan