AMDGPU DC Seeing Work On "Seamless Boot" Functionality

[phoronix]

Phoronix: AMDGPU DC Seeing Work On "Seamless Boot" Functionality

The boot experience may be improved moving forward for AMDGPU-using Radeon Linux users...

http://www.phoronix.com/scan.php?pag...-Seamless-Boot

[schmidtbag]

How big of a difference does this make? How long does the current mode-setting process take? Considering how much of the boot process seems to run in parallel, I would think that any speed improvement would be left unnoticed, but, I guess that all comes down to my first question.

[boxie]

*yay* this kind of work is pretty cool.

[boxie]

How big of a difference does this make? How long does the current mode-setting process take? Considering how much of the boot process seems to run in parallel, I would think that any speed improvement would be left unnoticed, but, I guess that all comes down to my first question.

I would imagine that it makes the boot process smoother rather than faster, but hey - I am willing to be surprised

[lu_tze]

For AMD GPUs, there is a long way ahead, and not only in the drivers, but also in firmware.

The UEFI GOP is supposed to behave like this: https://docs.microsoft.com/en-us/win...a-99f05bbdc7f3

Unfortunately, for desktop systems (section More Information, Mode selection, point 2), AMD cards behave as described in section 2c). For seamless boot, they would need to behave as in section 2a). For that, they would need updated firmware. Currently, the result is, that systems with AMD cards display a blurry startup logo, not in native resolution (unless you happen to use 1024x768 display, which I doubt) and not even Windows users are getting the experience that Intel and Nvidia users are getting.

[torsionbar28]

How big of a difference does this make? How long does the current mode-setting process take? Considering how much of the boot process seems to run in parallel, I would think that any speed improvement would be left unnoticed, but, I guess that all comes down to my first question.

This is not about speed, it's about the user experience. When I boot my Linux PC, the monitor has to change modes multiple times. Each time takes a couple of seconds. Once for the BIOS, once for each option ROM, once for GRUB, and once again for the Linux kernel. The mode setting takes longer than the init of the various ROM's, and so I end up not seeing the output, because the monitor is spending so much time "shifting gears". It makes the bootup user experience feel clunky and disjointed. A seamless startup display from BIOS to Desktop, with no mode changes, would be welcome indeed!

[schmidtbag]

This is not about speed, it's about the user experience. When I boot my Linux PC, the monitor has to change modes multiple times. Each time takes a couple of seconds. Once for the BIOS, once for each option ROM, once for GRUB, and once again for the Linux kernel. The mode setting takes longer than the init of the various ROM's, and so I end up not seeing the output, because the monitor is spending so much time "shifting gears". It makes the bootup user experience feel clunky and disjointed. A seamless startup display from BIOS to Desktop, with no mode changes, would be welcome indeed!

Ah I see. That makes more sense. Thanks for the clarification.

[bearoso]

For AMD GPUs, there is a long way ahead, and not only in the drivers, but also in firmware.

The UEFI GOP is supposed to behave like this: https://docs.microsoft.com/en-us/win...a-99f05bbdc7f3

Unfortunately, for desktop systems (section More Information, Mode selection, point 2), AMD cards behave as described in section 2c). For seamless boot, they would need to behave as in section 2a). For that, they would need updated firmware. Currently, the result is, that systems with AMD cards display a blurry startup logo, not in native resolution (unless you happen to use 1024x768 display, which I doubt) and not even Windows users are getting the experience that Intel and Nvidia users are getting.

That has nothing to do with the card's firmware and everything to do with the motherboard's UEFI firmware. Sometimes messing with the boot logo setting can affect it, like changing it to/from "stretch" or "full screen". On the ASUS board I'm using now, UEFI gets the resolution right, but uses the NTSC 59.94Hz refresh rate instead of the EDID-native, almost-exact 60Hz. If I set that to persist (vga=current), the driver thinks it's OK, and it keeps that mode all the way through, which is a bad thing.

[lu_tze]

That has nothing to do with the card's firmware and everything to do with the motherboard's UEFI firmware. Sometimes messing with the boot logo setting can affect it, like changing it to/from "stretch" or "full screen". On the ASUS board I'm using now, UEFI gets the resolution right, but uses the NTSC 59.94Hz refresh rate instead of the EDID-native, almost-exact 60Hz. If I set that to persist (vga=current), the driver thinks it's OK, and it keeps that mode all the way through, which is a bad thing.

Of course it has to do with card's firmware and the proof is easy: change the card. If the card has the same problem across multiple boards, and different cards have no problem across the same set of boards, the problem is in the card.

Notwithstanding, GOP is implemented in the card's firmware. You can google around for a tool called modelist.efi, which will show you which UEFI modes the given card supports and which not. Unsurprisingly, the AMD cards I have go up to 1280x1024 and no higher.

[bearoso]

Of course it has to do with card's firmware and the proof is easy: change the card. If the card has the same problem across multiple boards, and different cards have no problem across the same set of boards, the problem is in the card.

I was too absolute saying it would have "nothing" to do with the card. You're right, of course, the graphics card will limit the available resolutions. In my recent experience, it has been the UEFI that was the problematic factor, with the boot logo feature on ASUS/MSI motherboards affecting the EFI framebuffer resolution.