Bug 941931 - GRUB2 graphical menu is extremely slow
GRUB2 graphical menu is extremely slow
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Michael Chang
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-17 10:10 UTC by Jan Matejek
Modified: 2022-04-19 11:32 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
screen showing output of vbeinfo (1.56 MB, image/jpeg)
2015-08-17 10:10 UTC, Jan Matejek
Details
vbeinfo with only vbe module loaded (1.20 MB, image/jpeg)
2015-09-03 08:27 UTC, Jan Matejek
Details
hwinfo --framebuffer output (2.64 KB, text/plain)
2015-09-03 08:28 UTC, Jan Matejek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Matejek 2015-08-17 10:10:15 UTC
Created attachment 643998 [details]
screen showing output of vbeinfo

i'm using an AMD GPU and a 2560x1440 native display.
on this configuration, the GRUB2 UI is slow to the point of unusability; it takes a full second to flip from one menu item to another, 3-5s just to display the boot menu, before booting starts.
drawing the chameleon logo is visible line-by-line, too

lowering the resolution helps, at 1280x960x32 the speed is almost usable, 1280x960x16 is sluggish but OK (so i'm sticking with this resolution for now)

my GPU is reported as follows:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X]

detected graphics modes are attached
Comment 1 Jan Matejek 2015-08-18 16:58:47 UTC
on a different system with an AMD GPU, the gui menu is using mode 1600x1200x32 and is working fine
the GPU is:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
Comment 2 Michael Chang 2015-08-26 03:25:51 UTC
Hi Jan,

Can you please test by disabling theme and with gfxterm and background ? It's simple to do that by editing /etc/default/grub and commenting out the GRUB_THEME=..

  GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
  # GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt

After that, run grub2-mkconfig -o /boot/grub2/grub.cfg

I think we need to check whether it's related to how grub's theme rendering and compositing things to target . And if you still experience slowness with gfxterm, I suspect it's more related with firmware as the flipping to front/display buffer is somehow slow in larger resolution..

Thanks.
Comment 3 Jan Matejek 2015-08-30 21:58:50 UTC
gfxterm without theme still renders the background, and then a border around the menu. both of those things are slow (as in, you can see first the logo and later the border render from bottom to top, line by line)

after that is done, all the text appears instantly and the option picker responds reasonably fast
Comment 4 Jan Matejek 2015-08-31 09:55:08 UTC
sorry, a correction. text does NOT appear instantly, but is rendered along with the border. (just confirmed this by switching to grub's edit mode. the screen is cleared and then a new border with the edit window is rendered, again, scanline-by-scanline)

(a clarification, when i say "line by line", i mean scanlines, as in individual pixels. not lines of text)

it very much looks as if a pre-filled 2560x1440 buffer is copied on screen and that takes a long time.

moving around and editing is responsive, which i guess is because a much smaller area is updated? it still feels sort of sluggish, but at this point i can't be sure whether there is a problem or whether my perception is wrong.
Comment 5 Michael Chang 2015-09-02 10:29:53 UTC
(In reply to Jan Matejek from comment #4)

From your log. somehow the active video adapter was VGA Video driver. There could be something wrong here, as it can't support for resolutions other than 640x480 or 640x350. Also it should use vbe video driver if video bios externsion is available, which is quite common nowadays.  
  
What do `hwinfo --framebuffer` say in your system ? Also can you test by modifying /boot/grub2/grub.cfg from 

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

to 

function load_video {
    insmod vbe
}

* remember to backup your grub.cfg for the testing, ideally it should fallback to text mode for no matched video adapter found, but I can assure that.

Thanks.
Comment 6 Michael Chang 2015-09-02 10:34:43 UTC
(In reply to Jan Matejek from comment #4)

> (a clarification, when i say "line by line", i mean scanlines, as in
> individual pixels. not lines of text)
> 
> it very much looks as if a pre-filled 2560x1440 buffer is copied on screen
> and that takes a long time.

That sounds like no dobule buffering so that the rendering direct updating the on-screen buffer in video memory, blitting data from system memory to it.
Comment 7 Jan Matejek 2015-09-03 08:27:13 UTC
(In reply to Michael Chang from comment #5)
> (In reply to Jan Matejek from comment #4)
> 
> From your log. somehow the active video adapter was VGA Video driver.

no, the top of the output is missing and the list of resolutions is apparently generated by "VESA BIOS Extension Video Driver"

(i presume the "VGA" entry means that the VGA driver was loaded, but found no applicable resolutions?)

anyways, i'm attaching a complete output that I got when only vbe was loaded.

> function load_video {
>     insmod vbe
> }

this didn't change anything (except the VGA section from vbeinfo is gone)
Comment 8 Jan Matejek 2015-09-03 08:27:51 UTC
Created attachment 646060 [details]
vbeinfo with only vbe module loaded
Comment 9 Jan Matejek 2015-09-03 08:28:19 UTC
Created attachment 646061 [details]
hwinfo --framebuffer output
Comment 10 Michael Chang 2015-09-03 11:04:52 UTC
Looks to me that the video ram is too small to enable page flipping by swapping poiners of on-screen and off-screen buffers in video memory to update the screen quicky [1]. 

Some relevant log outputs

VBE info:
  total memory: 16384 KB

* 0x1d4 2560 x 1440 x 32 (10240) Direct Color, mask: 8/8/8/0 pos: 16/8/0/0

page_size = pitch * height = 10240 * 1440  = 14745600 = 14745.6 KiB
vram = 16384 KB < 2 * page_size = 2 * 14745.6 KiB = 29491.2 KiB

Without page flipping, the screen update would be way much slower by bit-blitting from system memory to video memory and no longer a simple pointer switch.

[1] http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/video/i386/pc/vbe.c#n1114
Comment 11 Jan Matejek 2015-09-04 08:19:44 UTC
(In reply to Michael Chang from comment #10)
> Looks to me that the video ram is too small to enable page flipping by
> swapping poiners of on-screen and off-screen buffers in video memory to
> update the screen quicky [1]. 

this is true, but doesn't help the issue

indeed, lowering to 1600x1200x32 (6400 line width, 15MB used) gets rid of the line-by-line rendering, and the whole image appears at once

BUT, there is still roughly the same delay before the image appears

so ISTM it's the filling of the buffer itself that is causing the slowdown
Comment 12 Michael Chang 2015-09-07 10:11:24 UTC
(In reply to Jan Matejek from comment #11)
> (In reply to Michael Chang from comment #10)

> BUT, there is still roughly the same delay before the image appears

How the delay was measured? Is it still gfxterm (no theme enabled) with backgroud image that could reproduce it? How about the disable the background image completely and leave on gfxterm or do not scale the background image by changing, for eg.

 background_image -m stretch /boot/grub2/themes/SLE/back-640-480.png
 to
 background_image -m normal /boot/grub2/themes/SLE/back-640-480.png

in /boot/grub2/grub.cfg ?

Thanks.
Comment 13 Jan Matejek 2015-09-20 09:31:27 UTC
so, some measurements. taken with a stopwatch in my phone so sub-second precision is going to be wobbly
timed from the moment when "Loading GRUB" in 80x25 textmode flashes on the screen and immediately disappears


at 1920x1440x32 (does not fit double-buffer, rendering is visible)

themed GRUB takes 4s to render the screen, and 1s to switch between items
(i forgot to take note what happens when an item is selected; it's probably not significant, perhaps it disappears immediately)

gfxterm GRUB with no background takes a little less, maybe 3-3.5s to render the screen. switching between items is immediate
after selecting an item, takes another 3s to "de-render" the screen, clearing it line by line, before boot starts


at 1600x1200x32 (fits double-buffer, screen displays at once)

themed GRUB takes about 3.5s to render, around 0.7s to switch between items
(again, not sure what happens after selecting item)

gfxterm GRUB with no background takes a little over 2s to display
after that, additional 2s before it starts responding to keyboard input
switching between items is immediate, booting is also immediate

the additional delay *seems* to correspond to clearing the second buffer in advance?


presence of background image doesn't seem to have an effect when double-buffering; i didn't take measurements with it, but it didn't feel that removing the background image made it faster.
when not double-buffering, the background image takes its own time to render, but doesn't "de-render" like the gfxterm border and instead stays on the screen as if in background layer, presumably until the kernel takes over
Comment 14 Benjamin Brunner 2022-04-19 11:32:51 UTC
After there was no progress for several years and grub received some version-updates in the meantime, I would like to close this bug for now.

If you think this is still relevant, please reopen the report.

Thank you.