graphicsoperating-systemkerneldrivervesa

How can VBE be implemented as BIOS function agnostic to graphics card?


I'm currently learning about low level computing like bootloader and kernel, and I stumbled upon the VESA BIOS extension, the standard for graphics display controllers.

But after reading some documents about it, I'm not sure how BIOS, developed by a motherboard manufacturer, can configure / utilize graphics cards which are completely independent from it.

I'm aware about VGA which also turned out to graphics standards available with BIOS function, but it has specific IO ports dedicated for certain functions that every VGA compatible graphics card also has. I'm not really sure about this, but I think that BIOS functions for VGA actually utilize these ports to provide functions like switching modes, etc.

However Super-VGA, which kinda is the reason VBE was created, as far as I know, does not have any standardized ports or MMIO for extended features. And so does VBE (At least I couldn't find any documentation about IO port or MMIO).

Since video cards nowadays come up with even more proprietary ways to communicate with the CPU and usually offer graphics driver binaries hiding implementation details, I can't imagine how the BIOS extension can offer a unified way of utilizing the video card.


Solution

  • The VBE standard isn't really agnostic to graphics cards. It is a BIOS interface so it doesn't give much details about how the firmware implementing the BIOS needs to access the graphics card. You can find a link to the VBE 3.0 standard on the Wikipedia page for VBE. In the standard, it states:

    The VBE standard defines a set of extensions to the VGA ROM BIOS services. These functions can be accessed under DOS through interrupt 10h, or be called directly by high performance 32-bit applications and operating systems other than DOS.

    These extensions also provide a hardware-independent mechanism to obtain vendor information, and serve as an extensible foundation for OEMs and VESA to facilitate rapid software support of emerging hardware technology without sacrificing backwards compatibility.

    What I understand here is that it isn't the way to interact with the card from software that is standardized. Instead, VBE standardizes how to find the information to know how to interact with the card. Then, the mobo manufacturer writes code that uses this information to implement the standardized BIOS interface that your OS uses to show graphics on your screen.

    Most of the time, your OS doesn't use the discrete GPU for graphics. Instead, it uses the integrated GPU in the CPU to kickstard the OS until it can detect the proprietary driver to use the more powerful discrete GPU.

    During installation, it can use the integrated GPU and automatically use vendor web APIs to search for the proper driver for your discrete GPU and install it in the background while you are using the computer. It might ask you to reboot after its installation if it is needed.

    More recent discrete GPUs are PCI-Express so their mechanism to detect the type of card and the vendor is standardized and a list of vendors and type of devices is maintained by PCI-SIG group a non-profit organization maintaining PCI. This mechanism is MMIO like you mentionned so you read some standard registers mapped in main memory and they return IDs that you can compare to the public device/vendor lists from PCI-SIG. After this, it comes down to the driver model of the OS and its mechanisms to support generic drivers (drivers that you can use even though you don't know how they work). The most common type on Linux for graphics is the character device but, AFAIK there are others. The integrated CPU graphics cards are often very open because their interface are available for download free of charge from corresponding vendors like Intel or AMD.

    You can read my answer at https://cs.stackexchange.com/questions/149203/how-bits-translated-into-text-on-the-screen/149215#149215 for some more information. You can also read some of my other answers. The information I give is probably not 100% accurate but it is a good starting point to gather more precise/accurate information from actual standards and documentation (some of them might not be free or even quite costly like PCI which can cost thousands). Anyway, don't be scared to dig in the actual standards. They are not as hard to read as people think especially if you are only looking for a general knowledge about how it works. You can probably just skim the documents and get a proper high-level overview.