[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c000477-002b-d125-b945-2c4831bad8a5@gmx.de>
Date: Thu, 20 Jan 2022 18:01:00 +0100
From: Helge Deller <deller@....de>
To: Thomas Zimmermann <tzimmermann@...e.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-fbdev@...r.kernel.org, Sven Schnelle <svens@...ckframe.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Javier Martinez Canillas <javierm@...hat.com>,
Daniel Vetter <daniel.vetter@...el.com>,
Ilia Mirkin <imirkin@...m.mit.edu>,
Tomi Valkeinen <tomi.valkeinen@...com>,
dri-devel@...ts.freedesktop.org,
Jani Nikula <jani.nikula@...ux.intel.com>,
Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
Gerd Hoffmann <kraxel@...hat.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Sam Ravnborg <sam@...nborg.org>, Claudio Suarez <cssk@...-c.es>
Subject: Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Hello Daniel,
On 1/20/22 15:30, Daniel Vetter wrote:
> On Wed, Jan 19, 2022 at 12:08:39PM +0100, Helge Deller wrote:
>> This reverts commit 39aead8373b3c20bb5965c024dfb51a94e526151.
>>
>> Revert this patch. This patch started to introduce the regression that
>> all hardware acceleration of more than 35 existing fbdev drivers were
>> bypassed and thus fbcon console output for those was dramatically slowed
>> down by factor of 10 and more.
>>
>> Reverting this commit has no impact on DRM, since none of the DRM drivers are
>> tagged with the acceleration flags FBINFO_HWACCEL_COPYAREA,
>> FBINFO_HWACCEL_FILLRECT or others.
>>
>> Signed-off-by: Helge Deller <deller@....de>
>> Cc: stable@...r.kernel.org # v5.16
>
> So if this really has to come back then I think the pragmatic approach is
> to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning
> that enabling that shouldn't be done for any distro which only enables
> firmware and drm fbdev drivers.
Thanks for coming back on this, but quite frankly I don't understand
that request. How should that warning look like, something along:
"BE WARNED: The framebuffer text console on your non-DRM supported
graphic card will then run faster and smoother if you enable this option."
That doesn't make sense. People and distros would want to enable that.
And if a distro *just* has firmware and drm fbdev drivers enabled,
none of the non-DRM graphic cards would be loaded anyway and this code
wouldn't be executed anyway.
I think what you want is that DRM drivers are preferred over standard
fbdev drivers, esp. if there is a driver for both available.
But that's completely independed of fbdev-drivers console hardware acceleration.
> Plus adjusting the todo to limit it to drm drivers. Maybe also #ifdef out
> the code that's then dead from fbcon.
Sorry, I don't understand that either.
I assume you mean to put code of fbcon which is only used by fbdev-drivers
into and #ifdef CONFIG_FB .. #endif (CONFIG_FB may be wrong in this example).
That's probably possible, but I don't see a big win.
If there is no fbdev driver compiled-in or as module, none of this fbdev-drivers
will be loaded and that code path wouldn't be executed anyway.
In that case you will win a few bytes of code, but probably not much.
> Also in that case I guess it's ok to cc: stable, and really if you cc:
> stable it needs to go down to 5.11, not 5.16.
Yes, I missed that in my patch request. Will fix.
> And if we do that, I think that should go in through a -next cycle, or at
> least quite some soaking before it's cherry-picked over. Enough to give
> syzbot a chance to discover any path we've missed at least.
Sure. We don't need to hurry.
Thanks!
Helge
> -Daniel
>
>> ---
>> Documentation/gpu/todo.rst | 21 ---------------
>> drivers/video/fbdev/core/fbcon.c | 45 ++++++++++++++++++++++++++------
>> 2 files changed, 37 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>> index 29506815d24a..a1212b5b3026 100644
>> --- a/Documentation/gpu/todo.rst
>> +++ b/Documentation/gpu/todo.rst
>> @@ -300,27 +300,6 @@ Contact: Daniel Vetter, Noralf Tronnes
>>
>> Level: Advanced
>>
>> -Garbage collect fbdev scrolling acceleration
>> ---------------------------------------------
>> -
>> -Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
>> -SCROLL_REDRAW. There's a ton of code this will allow us to remove:
>> -
>> -- lots of code in fbcon.c
>> -
>> -- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
>> - directly instead of the function table (with a switch on p->rotate)
>> -
>> -- fb_copyarea is unused after this, and can be deleted from all drivers
>> -
>> -Note that not all acceleration code can be deleted, since clearing and cursor
>> -support is still accelerated, which might be good candidates for further
>> -deletion projects.
>> -
>> -Contact: Daniel Vetter
>> -
>> -Level: Intermediate
>> -
>> idr_init_base()
>> ---------------
>>
>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>> index 22bb3892f6bd..b813985f1403 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1025,7 +1025,7 @@ static void fbcon_init(struct vc_data *vc, int init)
>> struct vc_data *svc = *default_mode;
>> struct fbcon_display *t, *p = &fb_display[vc->vc_num];
>> int logo = 1, new_rows, new_cols, rows, cols;
>> - int ret;
>> + int cap, ret;
>>
>> if (WARN_ON(info_idx == -1))
>> return;
>> @@ -1034,6 +1034,7 @@ static void fbcon_init(struct vc_data *vc, int init)
>> con2fb_map[vc->vc_num] = info_idx;
>>
>> info = registered_fb[con2fb_map[vc->vc_num]];
>> + cap = info->flags;
>>
>> if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
>> logo_shown = FBCON_LOGO_DONTSHOW;
>> @@ -1135,13 +1136,11 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>> ops->graphics = 0;
>>
>> - /*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> - p->scrollmode = SCROLL_REDRAW;
>> + if ((cap & FBINFO_HWACCEL_COPYAREA) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED))
>> + p->scrollmode = SCROLL_MOVE;
>> + else /* default to something safe */
>> + p->scrollmode = SCROLL_REDRAW;
>>
>> /*
>> * ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1953,15 +1952,45 @@ static void updatescrollmode(struct fbcon_display *p,
>> {
>> struct fbcon_ops *ops = info->fbcon_par;
>> int fh = vc->vc_font.height;
>> + int cap = info->flags;
>> + u16 t = 0;
>> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> + info->fix.xpanstep);
>> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> + divides(ypan, vc->vc_font.height) && vyres > yres;
>> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> + divides(ywrap, vc->vc_font.height) &&
>> + divides(vc->vc_font.height, vyres) &&
>> + divides(vc->vc_font.height, yres);
>> + int reading_fast = cap & FBINFO_READS_FAST;
>> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>>
>> p->vrows = vyres/fh;
>> if (yres > (fh * (vc->vc_rows + 1)))
>> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> if ((yres % fh) && (vyres % fh < yres % fh))
>> p->vrows--;
>> +
>> + if (good_wrap || good_pan) {
>> + if (reading_fast || fast_copyarea)
>> + p->scrollmode = good_wrap ?
>> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> + else
>> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> + SCROLL_PAN_REDRAW;
>> + } else {
>> + if (reading_fast || (fast_copyarea && !fast_imageblit))
>> + p->scrollmode = SCROLL_MOVE;
>> + else
>> + p->scrollmode = SCROLL_REDRAW;
>> + }
>> }
>>
>> #define PITCH(w) (((w) + 7) >> 3)
>> --
>> 2.31.1
>>
>
Powered by blists - more mailing lists