[HankB99]

I have an old server motherboard that does not support UEFI. Otherwise it still runs fine.

I came here to ask why it matters to the GPU how the host boots. Does it need to load some drivers or firmware before the host OS? The only thing I found in the article was "... may lose access to important and necessary features of your motherboard,"

[sunshowers]

Yeah, boot menus and UEFI configuration as the sibling suggests.

This is actually a huge problem with DDR5 memory training. Since memory training must happen before the GPU is brought up, the screen stays blank for that duration (which can take several minutes). The only indication that it's happening is in debug LEDs if your motherboard has them.

[chronid]

The fact boot codes displays are getting pushed to always more expensive motherboards - and there is no standard way to get them otherwise - drives me crazy.

[HankB99]

> DDR5 memory training.

That makes sense. I also have a newer host that uses DDR5 RAM. The first time I powered it up, I thought it was not working. While I was sitting there trying to figure out what to try nest, It finally came up. It gets better with time (or BIOS updates.)

[wmf]

Resizable BAR (which doesn't exist on old pre-UEFI hardware anyway).

[toast0]

> I came here to ask why it matters to the GPU how the host boots. Does it need to load some drivers or firmware before the host OS?

Only if you want some display output before the host OS starts. Like maybe firmware menus, or boot prompts. Generally, this functionality is enabled by a ROM with code for the system firmware to call into: VGA BIOS for CSM and the UEFI GOP for UEFI.

I think all of the IBM video standards involve semi-fixed memory and i/o addresses, so a video card operating in CSM mode needs to listen on those addresses or CSM software is unlikely to work.