Re: [PATCH 4/10] atyfb: set FBINFO_READS_FAST

From: Mikulas Patocka
Date: Thu Jan 23 2014 - 15:03:14 EST

On Thu, 23 Jan 2014, Linus Torvalds wrote:

> On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka <mpatocka@xxxxxxxxxx> 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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at