On Thu, 23 Jan 2014, Linus Torvalds wrote:

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