linux-kernel - Re: [PATCH 4/10] atyfb: set FBINFO_READS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.02.1401231448100.7971@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Thu, 23 Jan 2014 15:03:03 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/10] atyfb: set FBINFO_READS_FAST

On Thu, 23 Jan 2014, Linus Torvalds wrote:

> On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka <mpatocka@...hat.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/