Intel® Embedded Graphics Drivers FAQ
BIOS and firmware
1. What is UEFI?
UEFI stands for unified extensible firmware interface. UEFI is a replacement for legacy system BIOS; it is flexible, fast, efficient, and has no driver size constraints. The UEFI pre-boot firmware architecture can either be 32-bit, 64-bit, or IA-64. There is no binary compatibility. Compatibility support module (CSM) is used to boot legacy operating systems and operate with legacy option ROMs.
Intel® Embedded Graphics Drivers support the extensible firmware interface (EFI) driver, which gets merged into the UEFI system pre-boot firmware. The EFI driver supports fast boot capability.
2. What does “EPOG” stand for and how is it used?
EPOG stands for embedded pre-OS graphics feature. EPOG was first supported with the Intel Embedded Graphics Drivers 10.2 gold release. This driver is a module within the Intel® Boot Loader Development Kit (Intel® BLDK).
EPOG is configured using Configuration EDitor (CED). CED provides a file called libepog.a, which must be integrated into the firmware. The EPOG feature enables quick display of the user’s chosen splash screen (8-bit or 24-bit per pixel .bmp format with size less than 50K). Splash screens are often used to display corporate logos. The current EPOG driver supports a static splash screen only. Industry suppliers can also provide splash video, but this is not currently implemented by Intel.
From the time control is handed over to the EPOG driver by the Intel BLDK environment, the EPOG driver typically takes no longer than 500 ms to display the splash screen.
3. Is video BIOS (VBIOS) the same as the graphics output protocol (GOP) driver?
No. The GOP driver is a replacement for legacy video BIOS and enables the use of UEFI pre-boot firmware without CSM. The GOP driver can be 32-bit, 64-bit, or IA-64 with no binary compatibility. UEFI pre-boot firmware architecture (32-/64-bit) must match the GOP driver architecture (32-/64-bit). The Intel Embedded Graphics Drivers' GOP driver can either be fast boot (speed optimized and platform specific) or generic (platform agnostic for selective platforms).
Here is a quick comparison between GOP and video BIOS:
- GOP: No 64 KB limit. 32-bit protected mode. No need for CSM. Speed optimized (fast boot). The UEFI pre-boot firmware architecture (32-/64-bit) must match the GOP driver.
- Video BIOS: 64 KB limit. 16-bit execution. CSM is needed with UEFI system firmware. Performance inferior to GOP CSM. The VBIOS works with both 32- and 64-bit architectures.
4. Can VBIOS and the GOP driver coexist on a platform?
No. This is not recommended as the UEFI pre-boot firmware will choose the graphics firmware component for console_out during runtime based on an algorithm (currently the version number). The graphics firmware component with the highest version number will be chosen, and this algorithm is subject to change. This same answer is applicable to multiple instances of the GOP driver.
5. How is the VBIOS option ROM linked to the display adapter in EFI pre-boot firmware?
The VBIOS option ROM is linked with the PCI vendor-device ID of the video graphics array (VGA) device—typically bus 0, device 2, function 0—and this information is embedded in the EFI pre-boot firmware at compile time or merged into the image on the host via the merge utility.
6. Which VBIOS is activated when I have an external graphics card, such as a Matrox card*, and internal graphics, such as internal low-voltage differential signaling (LVDS)?
The answer depends upon the EFI pre-boot firmware setting, if available. If the "PCI as primary" option is available and enabled, then the VBIOS option ROM from the Matrox card is activated. If "PCI as primary" is not enabled, then the Intel Embedded Graphics Drivers VBIOS is activated. Note that there can be only one instance of VBIOS in the platform.
7. What are the VBIOS usage scenarios under Windows* XP?
Windows XP uses the VBIOS via INT 10h for displaying the splash screen and any messages until the graphics driver is loaded. Note that during the OS boot process, the OS writes to the framebuffer directly, bypassing VBIOS for display purposes. After the graphics driver is loaded, the OS transfers control to VBIOS during full screen DOS mode and during “blue screen” to display the stack information.