23.1 Assumptions

The rest of this chapter assumes that the Driver Checklist in Chapter 2 has been followed and that the following items have already been identified:

• UEFI Driver Type

• Optional UEFI Driver features

• Supported CPU architectures

• Consumed protocols that are used to produce the graphics controller related protocols.

If the UEFI Driver is required to be compiled for EBC, then see Chapter 18 for PCI optimizations and Chapter 29 for EBC considerations. UEFI Drivers for graphics controllers are typically more sensitive to the EBC virtual machine interpreter overheads, so it is critical that the performance guidelines are followed for a UEFI Driver for a graphics controller that is compiled for EBC to have good performance.

UEFI Drivers for graphics controllers typically follow the UEFI driver model. Some graphics controllers have a single output controller, and other may have multiple output controllers. In both cases, a child handle must be created for each output controller, which means UEFI Drivers for graphics controllers are always either Bus Drivers or Hybrid Drivers. They are never Device Drivers. UEFI Drivers for graphics controllers are chip-specific because of the requirement to initialize and manage the graphics device.

UEFI drivers that manage graphics controllers typically follow the UEFI Driver Model because the devices are typically on industry standard busses such as PCI. However, it is possible to implement UEFI drivers for graphics controllers that are not on industry standard busses. In these cases, a Root Bridge Driver implementation that produces a handle for each output controller in the driver entry point may be more appropriate than a UEFI Driver Model implementation.