Hmm. You're doing this for Matrix and now the aty driver.
Maybe the problem is at the fbcon level? Depending on
FBINFO_READS_FAST to decide whether you should scroll or rewrite
sounds a bit silly: even if a device doesn't have fast reads, maybe it
has a fast accelerated BLIT operation and scrolls quickly. Should the
fbcon test perhaps be for FBINFO_READS_FAST _or_ the
FBINFO_HWACCEL_COPYAREA bits?
I dunno. I didn't actually check the ->bcopy implementations, maybe
they don't use copyarea. So I'm just going by a general "this feels
wrong" feeling..
Linus
On Thu, Jan 23, 2014 at 10:18 AM, Mikulas Patocka [off-list ref] wrote:
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
Hmm. You're doing this for Matrix and now the aty driver.
Maybe the problem is at the fbcon level? Depending on
FBINFO_READS_FAST to decide whether you should scroll or rewrite
sounds a bit silly: even if a device doesn't have fast reads, maybe it
has a fast accelerated BLIT operation and scrolls quickly. Should the
fbcon test perhaps be for FBINFO_READS_FAST _or_ the
FBINFO_HWACCEL_COPYAREA bits?
Both mach64 and matrox have a hardware bitter that is faster than
rewriting the console - that's why FBINFO_READS_FAST improves performance
for them.
One could improve generic framebuffer core to benchmark the performance of
scrolling using blitter and rewrite and select FBINFO_READS_FAST
automatically...
Mikulas
I dunno. I didn't actually check the ->bcopy implementations, maybe
they don't use copyarea. So I'm just going by a general "this feels
wrong" feeling..
Linus
On Thu, Jan 23, 2014 at 10:18 AM, Mikulas Patocka [off-list ref] wrote:
quoted
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
A time to do ls -la /usr/bin:
original patched
32bpp 4.9 3.6
24bpp 4.9 2.9
16bpp 4.9 2.1
8bpp 4.9 1.7
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/aty/atyfb_base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-3.13-rc1/drivers/video/aty/atyfb_base.c
=================================--- linux-3.13-rc1.orig/drivers/video/aty/atyfb_base.c 2013-11-27 00:25:42.000000000 +0100
On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka [off-list ref] wrote:
Both mach64 and matrox have a hardware bitter that is faster than
rewriting the console - that's why FBINFO_READS_FAST improves performance
for them.
My point is that I'd expect *anything* that has a hardware blitter to
be faster than rewriting the screen.
FBINFO_READS_FAST is documented to be about "soft-copy" being faster
than re-rendering. Which I take to be about actually doing copying in
*software*.
In particular, updatescrollmode() seems to do this right. It sets
p->scrollmode based on whether there's an accelerated copyarea. But
then SCROLL_PAN/WRAP_MOVE ends up re-testing FBINFO_READS_FAST,
ignoring any hw-accelerated copy-area, and I don't quite see why..
Linus
On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka [off-list ref] wrote:
quoted
Both mach64 and matrox have a hardware bitter that is faster than
rewriting the console - that's why FBINFO_READS_FAST improves performance
for them.
My point is that I'd expect *anything* that has a hardware blitter to
be faster than rewriting the screen.
FBINFO_READS_FAST is documented to be about "soft-copy" being faster
than re-rendering. Which I take to be about actually doing copying in
*software*.
In particular, updatescrollmode() seems to do this right. It sets
p->scrollmode based on whether there's an accelerated copyarea. But
then SCROLL_PAN/WRAP_MOVE ends up re-testing FBINFO_READS_FAST,
ignoring any hw-accelerated copy-area, and I don't quite see why..
Linus
I think the argument why not to use the blitter was this:
Some hardware have font expansion - you submit monochromatic bitwise image
of the character via writes to some register and the hardware expands it
to full color. Mach64 has this capability, matrox doesn't (maybe it does,
but the driver doesn't use it).
If you use font expansion, you actually generate less load on the videoram
than using the blitter (the expander only writes to the videoram; the
blitter reads data from the videoram and stores them back).
But the benchmarks that I performed show that the blitter is faster than
the font expander. Maybe on a different computer that has better
bufferring in the PCI chipset the font expander could be faster - who
knows?
Mikulas