All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Sven Schnelle <svens@stackframe.org>
Cc: Helge Deller <deller@gmx.de>,
	linux-fbdev@vger.kernel.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Hamza Mahfooz <someguy@effective-light.com>
Subject: Re: fbdev: Garbage collect fbdev scrolling acceleration
Date: Wed, 19 Jan 2022 16:39:03 +0100	[thread overview]
Message-ID: <Yegwl/rwRhjROxcy@phenom.ffwll.local> (raw)
In-Reply-To: <87zgnz71ic.fsf@x1.stackframe.org>

On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote:
> Helge Deller <deller@gmx.de> writes:
> 
> > I may have missed some discussions, but I'm objecting against this patch:
> >
> > 	b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)")
> >
> > Can we please (partly) revert it and restore the scrolling behaviour,
> > where fbcon uses fb_copyarea() to copy the screen contents instead of
> > redrawing the whole screen?
> >
> > I'm fine with dropping the ypan-functionality.
> >
> > Maybe on fast new x86 boxes the performance difference isn't huge,
> > but for all old systems, or when emulated in qemu, this makes
> > a big difference.
> >
> > Helge
> 
> I second that. For most people, the framebuffer isn't important as
> they're mostly interested in getting to X11/wayland as fast as possible.
> But for systems like servers without X11 it's nice to have a fast
> console.

Fast console howto:
- shadow buffer in cached memory
- timer based upload of changed areas to the real framebuffer

This one is actually fast, instead of trying to use hw bltcopy and having
the most terrible fallback path if that's gone. Yes drm fbdev helpers has
this (but not enabled on most drivers because very, very few people care).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Sven Schnelle <svens@stackframe.org>
Cc: linux-fbdev@vger.kernel.org,
	Hamza Mahfooz <someguy@effective-light.com>,
	Helge Deller <deller@gmx.de>,
	dri-devel@lists.freedesktop.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: fbdev: Garbage collect fbdev scrolling acceleration
Date: Wed, 19 Jan 2022 16:39:03 +0100	[thread overview]
Message-ID: <Yegwl/rwRhjROxcy@phenom.ffwll.local> (raw)
In-Reply-To: <87zgnz71ic.fsf@x1.stackframe.org>

On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote:
> Helge Deller <deller@gmx.de> writes:
> 
> > I may have missed some discussions, but I'm objecting against this patch:
> >
> > 	b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)")
> >
> > Can we please (partly) revert it and restore the scrolling behaviour,
> > where fbcon uses fb_copyarea() to copy the screen contents instead of
> > redrawing the whole screen?
> >
> > I'm fine with dropping the ypan-functionality.
> >
> > Maybe on fast new x86 boxes the performance difference isn't huge,
> > but for all old systems, or when emulated in qemu, this makes
> > a big difference.
> >
> > Helge
> 
> I second that. For most people, the framebuffer isn't important as
> they're mostly interested in getting to X11/wayland as fast as possible.
> But for systems like servers without X11 it's nice to have a fast
> console.

Fast console howto:
- shadow buffer in cached memory
- timer based upload of changed areas to the real framebuffer

This one is actually fast, instead of trying to use hw bltcopy and having
the most terrible fallback path if that's gone. Yes drm fbdev helpers has
this (but not enabled on most drivers because very, very few people care).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2022-01-19 15:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 16:36 fbdev: Garbage collect fbdev scrolling acceleration Helge Deller
2022-01-13 21:46 ` Sven Schnelle
2022-01-13 21:46   ` Sven Schnelle
2022-01-19 15:39   ` Daniel Vetter [this message]
2022-01-19 15:39     ` Daniel Vetter
2022-01-19 16:15     ` Sven Schnelle
2022-01-19 16:15       ` Sven Schnelle
2022-01-19 16:21       ` Daniel Vetter
2022-01-19 16:21         ` Daniel Vetter
2022-01-19 16:33         ` Sven Schnelle
2022-01-19 16:33           ` Sven Schnelle
2022-01-24 18:27     ` Geert Uytterhoeven
2022-01-24 18:27       ` Geert Uytterhoeven
2022-01-24 19:58       ` Daniel Vetter
2022-01-24 19:58         ` Daniel Vetter

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yegwl/rwRhjROxcy@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=someguy@effective-light.com \
    --cc=svens@stackframe.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.