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 knows? Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
