From: Daniel Vetter <firstname.lastname@example.org>
To: Phillip Susi <email@example.com>
Cc: Daniel Vetter <firstname.lastname@example.org>,
Geert Uytterhoeven <email@example.com>,
Linus Torvalds <firstname.lastname@example.org>,
Pavel Machek <email@example.com>, Randy Dunlap <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Linux Fbdev development list <firstname.lastname@example.org>
Subject: Re: fbcon: remove soft scrollback code (missing Doc. patch)
Date: Tue, 2 Feb 2021 16:23:50 +0100 [thread overview]
Message-ID: <YBluhm2WV2rmWfja@phenom.ffwll.local> (raw)
On Tue, Feb 02, 2021 at 10:13:14AM -0500, Phillip Susi wrote:
> Daniel Vetter writes:
> > Just a quick comment on this: Since most framebuffers are write-combining,
> > and reads from that tend to be ~3 orders of magnitude slower than writes
> > (at least on the pile of machines I looked at here, there's big
> > differences, and some special streaming cpu instructions to make the
> > reading side not so slow).
> > So scrolling by copying tends to be significantly slower than just
> > redrawing everything.
> I know this was the case years ago with AGP as iirc, it doubled ( 4x, 8x
> ) the PCI clock rate but only for writes wasn't it? I thought this was
> no longer an issue with PCIe, but if it is, then I guess I'll go ahead
> with cleaning up the dead code and having it re-render with the larger
> text buffer.
Still the same with PCIe, probably gotten worse since uncached reads are
still as slow, but write-combined writes have gotten much faster even.
There's work going on to have a coherent link to gpus which would allow
fully cached reads and writes, early with nvlink and now as a standard
with CXL (https://en.wikipedia.org/wiki/Compute_Express_Link)
But that's aimed at big compute jobs for servers, not really for display.
Also some on-die gpus have become fully coherent, but again only for
render/compute buffers, not for the display framebuffer.
So all together 0 signs this is changing going forward, reading from
framebuffers is slow.
Ok there's some exceptions: For manual update buffers (defio for fbdev
drivers, drm also supports this with an entire set of helpers) the
framebuffer used by the cpu is sometimes (but very often still not)
cached. Imo not worth optimizing for, since for the drivers where it is
cached they either have no blitter, or it's really tiny panels behind spi
links and similar, so not going to be fast anyway.
Software Engineer, Intel Corporation
prev parent reply other threads:[~2021-02-02 15:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200916205434.GA10389@duo.ucw.cz>
[not found] ` <email@example.com>
[not found] ` <CAHk-=wjsjC1h7fskwYaaRLykN1ms6ZtxGvucQgmL-zZTfxPdBA@mail.gmail.com>
[not found] ` <CAKMK7uEGXOC_ci=Drm=Hz+xPGdcoxv8YZ-gcOckoPmu2XijiSA@mail.gmail.com>
2021-01-14 15:56 ` fbcon: remove soft scrollback code (missing Doc. patch) Geert Uytterhoeven
2021-01-14 16:11 ` Daniel Vetter
2021-01-15 8:06 ` Geert Uytterhoeven
2021-02-03 8:03 ` Thomas Zimmermann
2021-01-22 18:55 ` Phillip Susi
2021-01-25 15:39 ` Geert Uytterhoeven
2021-02-02 14:18 ` Daniel Vetter
2021-02-02 15:13 ` Phillip Susi
2021-02-02 15:23 ` Daniel Vetter [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).