loader.efi: add "gop blt <on|off>" command

[tsoome]

Summary

Some systems have very slow console output and it may be about either
wrong memory attributes are set or gop->Blt() implementation is bad.

We do not have good way to set memory attributes, but we can
choose which Blt() to use (or we can set "gop off" to fall back on
use of SimpleTextOutput protocol).

This update adds argument for "gop" command to switch gop->Blt() use.
Note, this update does not fix the problem, but allows us to try to
understand the possible cause.

PR: 254381
Reported by: Michael Galassi

[jlduran]

Minor typo in comments

stand/common/gfx_fb.c

167

[tsoome]

fix typo

[tsoome]

thanks!

[imp]

it's ok I guess, but seems like yet another hack. Is there some way we can know if blt is slow?

stand/efi/loader/framebuffer.c

907

maybe this should be default since we have so many issues with slow graphics??

[tsoome]

In D49073#1119151, @imp wrote:

it's ok I guess, but seems like yet another hack. Is there some way we can know if blt is slow?

How slow is slow? Well, sure, update large enough part of the screen with one method and then with other method, measure the time spent and pick up the faster one. just need system with this defect to try to calibrate the chunk size to get meaningful measurement.

stand/efi/loader/framebuffer.c

907

The problem is, you [almost] never hear about people who have no problem. (I certainly am one of those;)

[jkim]

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

[tsoome]

In D49073#1119317, @jkim wrote:

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

use 'gop get' and see if it reports framebuffer address., or better yet, can you paste the output?

blt off does not change colors, we are preparing the glyph exactly the same way, we only switch from using default gop->Blt() to our own implementation (instead of first switch in gfxb_blt() we use second switch).

[kenrap_kennethraplee.com]

I'm having this same problem with the GOP Blt rendering the framebuffer at my monitor's 4K resolution. It makes rendering to the next part of the loader crawl very slowly against my screen at a row-by-row basis.

I took a video recording and uploaded on Streamable to show as an example (skip to 26s to see it finally process the "2nd" row):

https://streamable.com/nj4mkb

At that speed, I feel it'll likely take 2 hours or more to get to the full rendering of the menu before I can hit enter to load the kernel.

I should note that not all graphics cards I've used on my system have this problem. Since I recently started using an RX 7800 XT GPU, it was the one that ramped up the Blt to 4K where as other GPUs would use 1080p even when they render 4K in X11/Wayland.

What I do to work around this problem is by using rEFInd as an intermediary and config it to lower the Blt resolution before transitioning to the loader. This dramatically speeds up the rendering to the menu which allows me to boot and finally use this graphics card for this system as shown in the following:

https://streamable.com/jlm7ig

I've also tested gop blt off and it doesn't solve my problem without rEFInd. And after using rEFInd and it just doesn't render the menu after a bit of time and goes right to showing the kernel being loaded, as shown here:

https://streamable.com/esgqn3

[jkim]

In D49073#1119340, @tsoome wrote:

In D49073#1119317, @jkim wrote:

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

use 'gop get' and see if it reports framebuffer address., or better yet, can you paste the output?

I have tried gop blt off on four PCs with different GPUs. I found one laptop that actually works with gop blt off.

EDID 1920x0180
mode 0: 1920x1080x32, stride=1920
    frame buffer: address=b0000000, size=7e9000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

In this case, I can see gop blt off is significantly faster.

The following three cases do not work with gop blt off.

EDID 3840x2160 3840x2160 1920x1080 1600x900 1280x1024 1280x800 1152x864 1280x720
mode 0: 3840x2160x32, stride=3840
    frame buffer: address=7c00000000, size=1fa4000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

EDID 1920x0180 1680x1050 1400x1050 1600x900 1280x1024 1440x900 1280x960 1152x864 1280x720
mode 0: 1920x1080x32, stride=2048
    frame buffer: address=7800000000, size=870000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

EDID 1920x0180
mode 0: 1920x1080x32, stride=1920
    frame buffer: address=2fa0000000, size=7e9000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

[tsoome]

In D49073#1119425, @kenrap_kennethraplee.com wrote:

I'm having this same problem with the GOP Blt rendering the framebuffer at my monitor's 4K resolution. It makes rendering to the next part of the loader crawl very slowly against my screen at a row-by-row basis.

I took a video recording and uploaded on Streamable to show as an example (skip to 26s to see it finally process the "2nd" row):

https://streamable.com/nj4mkb

At that speed, I feel it'll likely take 2 hours or more to get to the full rendering of the menu before I can hit enter to load the kernel.

I should note that not all graphics cards I've used on my system have this problem. Since I recently started using an RX 7800 XT GPU, it was the one that ramped up the Blt to 4K where as other GPUs would use 1080p even when they render 4K in X11/Wayland.

What I do to work around this problem is by using rEFInd as an intermediary and config it to lower the Blt resolution before transitioning to the loader. This dramatically speeds up the rendering to the menu which allows me to boot and finally use this graphics card for this system as shown in the following:

https://streamable.com/jlm7ig

I've also tested gop blt off and it doesn't solve my problem without rEFInd. And after using rEFInd and it just doesn't render the menu after a bit of time and goes right to showing the kernel being loaded, as shown here:

https://streamable.com/esgqn3

mm ok the 4K is nasty ofc.

In D49073#1119458, @jkim wrote:

In D49073#1119340, @tsoome wrote:

In D49073#1119317, @jkim wrote:

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

use 'gop get' and see if it reports framebuffer address., or better yet, can you paste the output?

I have tried gop blt off on four PCs with different GPUs. I found one laptop that actually works with gop blt off.

EDID 1920x0180
mode 0: 1920x1080x32, stride=1920
    frame buffer: address=b0000000, size=7e9000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

In this case, I can see gop blt off is significantly faster.

faster than 'blt on' with the same resolution? It definitely is faster than 4K resolution.

The following three cases do not work with gop blt off.

do not work how? do you get blank screen? or is it the performance just as slow? (just trying to understand what is exactly happening).

I have some idea, but we would need to test it. Might it be possible for you to download either omnios or openindiana usb image and start up the boot loader there - to the menu, press esc to get ok prompt and then use framebuffer get/framebuffer list/framebuffer set to see if you are using 4k resolution and how the screen is behaving? you can enter: clear or press ctrl-l to clear the screen to observe the screen draw? the screen draw primitives are the same there, but the data is handled a bit differently so I would like to get feedback about it. You may mail the results directly to me ([e-mail] or [e-mail]), thanks.

EDID 3840x2160 3840x2160 1920x1080 1600x900 1280x1024 1280x800 1152x864 1280x720
mode 0: 3840x2160x32, stride=3840
    frame buffer: address=7c00000000, size=1fa4000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

EDID 1920x0180 1680x1050 1400x1050 1600x900 1280x1024 1440x900 1280x960 1152x864 1280x720
mode 0: 1920x1080x32, stride=2048
    frame buffer: address=7800000000, size=870000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

EDID 1920x0180
mode 0: 1920x1080x32, stride=1920
    frame buffer: address=2fa0000000, size=7e9000
    color mask: R=00ff0000, G=0000ff00, B=000000ff

[jkim]

In D49073#1119520, @tsoome wrote:

In D49073#1119458, @jkim wrote:

In this case, I can see gop blt off is significantly faster.

faster than 'blt on' with the same resolution? It definitely is faster than 4K resolution.

Yes, the same resolution. Note the laptop display has only one mode.

The following three cases do not work with gop blt off.

do not work how? do you get blank screen? or is it the performance just as slow? (just trying to understand what is exactly happening).

No OK prompt. Nothing changes. After *blindly* typing gop blt on, OK prompt appears again and everything works normally afterwards.

[jkim]

I tried gop blt off on my old laptop and it worked there. Surprisingly, gop blt off case is significantly *slower* than gop blt on case.