Reading from /dev/fb0 very slow?
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
Signature · 2 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [email protected]
Quoted 12 lines · 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#
Quoted 6 lines
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?
Signature · 4 lines
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 CenterQuoted 2 lines
I did some benchmarks, and my framebuffer is *way* faster when writing than when reading:
That is quite normal.
Quoted 6 lines
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.
Hi!
Quoted 4 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 6 lines
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....]
Signature · 2 lines
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+
Quoted 2 lines
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'.
Quoted 7 lines
Quoted 2 lines
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