March 8, 2014 at 22:27Games with UEFI
One of the most important innovations in the Unified Extensible Firmware Interface specification was the emergence and integration into the firmware of the personal platform of the special UEFI Shell operating environment , which allows you to perform small tasks or UEFI applicationswithout loading the operating system. In this context, first of all, we are talking about tasks related to servicing a computer system: updating the firmware of the platform and peripheral devices, restoring operating system modules after various failures, as well as system information and diagnostics utilities. The mention of gaming applications, and especially modern 3D games in this context, sounds somewhat paradoxical. And yet, let's try to answer the question: is it possible to write a game to run in the UEFI environment? If possible, then how? If not, then why?
In the early stages of the development of the graphics subsystems of personal platforms, during the reign of the ISA bus, the "drawing" of objects on the screen was carried out programmatically. The principle is simple: the video memory is located in the address space of the central processor, the output of the graphic object is reduced to recording the specified information at the given addresses. Simplifying somewhat, we can say that the coordinates of each displayed point are determined by the address at which the recording was made, and the color by the recorded data. The advantage of this model is the simplicity of software and hardware implementations, the disadvantage is low productivity.
As you know, a modern video adapter is “computer to computer”. The graphics processor included in it is capable of executing its own command stream, interacting with the platform's RAM in the bus-master mode, as well as with the local memory of the video adapter. In this case, the main task of the central processor is reduced to preparing in the main memory blocks of tasks for the GPU.
In a typical modern personal computer system, the bus connecting the video controller chip with the video memory is characterized by bit depths and clock frequencies that significantly exceed the same parameters for the mainboard RAM bus. And note that unlike the central processor, the GPU does not use transit links (in the form of AGP or PCI Express buses) when accessing video memory. As a result, the obvious advantage is high performance. But there are also disadvantages. About it below.
It so happened historically that the industry has not developed a single unified software model for low-level access to video accelerator registers. Unification is implemented exclusively at the level of the driver software interface. The developer of applications running in the environment of modern operating systems does not need to worry about low-level interaction with the video controller registers because its manufacturer has provided a driver that takes on this task. The problem is that such an infrastructure is not provided for the UEFI environment.
Undoubtedly, factors such as the transition from 16-bit Real Mode to 64-bit Protected Mode, as well as the use of the UEFI Driver Model instead of software interrupts Legacy BIOS, lay the foundation for creating such an infrastructure. But today there is a foundation, but no infrastructure.
A number of modern technologies made it possible to “breathe a second life” into the implementation of graphics using a central processor. This is primarily about the use of 128 and 256-bit SSE instructions, as well as Write Combining technology, which allows combining the results of several processor write cycles into a packet of up to 4 kilobytes in size for sending via the PCI Express bus. Sometimes, this approach allows you to get an acceptable result for 2D graphics in the framework of using the UEFI Graphics Output Protocol in combination with the "grandfather" visualization method:
Figure 1 . A screenshot taken from the UEFI environment during the launch of the Tetris64 game .
But it is obvious that this method will not allow to achieve the functionality and performance implemented by means of hardware GPUs.
We have to admit the impossibility of writing a UEFI application that implements 3D graphics with cinematic quality. Why? There are no unified protocols or off-the-shelf drivers that support 3D under UEFI. It is also unrealistic to solve this problem by directly accessing the hardware resources of the video accelerator from a UEFI application: the lack of unification of equipment will require the developer to write drivers for all models of graphic processors.
Recall everything: programmatic graphics output
In the early stages of the development of the graphics subsystems of personal platforms, during the reign of the ISA bus, the "drawing" of objects on the screen was carried out programmatically. The principle is simple: the video memory is located in the address space of the central processor, the output of the graphic object is reduced to recording the specified information at the given addresses. Simplifying somewhat, we can say that the coordinates of each displayed point are determined by the address at which the recording was made, and the color by the recorded data. The advantage of this model is the simplicity of software and hardware implementations, the disadvantage is low productivity.
Computer to computer: hardware graphics output
As you know, a modern video adapter is “computer to computer”. The graphics processor included in it is capable of executing its own command stream, interacting with the platform's RAM in the bus-master mode, as well as with the local memory of the video adapter. In this case, the main task of the central processor is reduced to preparing in the main memory blocks of tasks for the GPU.
In a typical modern personal computer system, the bus connecting the video controller chip with the video memory is characterized by bit depths and clock frequencies that significantly exceed the same parameters for the mainboard RAM bus. And note that unlike the central processor, the GPU does not use transit links (in the form of AGP or PCI Express buses) when accessing video memory. As a result, the obvious advantage is high performance. But there are also disadvantages. About it below.
Problems resolved and not resolved
It so happened historically that the industry has not developed a single unified software model for low-level access to video accelerator registers. Unification is implemented exclusively at the level of the driver software interface. The developer of applications running in the environment of modern operating systems does not need to worry about low-level interaction with the video controller registers because its manufacturer has provided a driver that takes on this task. The problem is that such an infrastructure is not provided for the UEFI environment.
Undoubtedly, factors such as the transition from 16-bit Real Mode to 64-bit Protected Mode, as well as the use of the UEFI Driver Model instead of software interrupts Legacy BIOS, lay the foundation for creating such an infrastructure. But today there is a foundation, but no infrastructure.
Compromises are possible
A number of modern technologies made it possible to “breathe a second life” into the implementation of graphics using a central processor. This is primarily about the use of 128 and 256-bit SSE instructions, as well as Write Combining technology, which allows combining the results of several processor write cycles into a packet of up to 4 kilobytes in size for sending via the PCI Express bus. Sometimes, this approach allows you to get an acceptable result for 2D graphics in the framework of using the UEFI Graphics Output Protocol in combination with the "grandfather" visualization method:
Figure 1 . A screenshot taken from the UEFI environment during the launch of the Tetris64 game .
But it is obvious that this method will not allow to achieve the functionality and performance implemented by means of hardware GPUs.
Summary
We have to admit the impossibility of writing a UEFI application that implements 3D graphics with cinematic quality. Why? There are no unified protocols or off-the-shelf drivers that support 3D under UEFI. It is also unrealistic to solve this problem by directly accessing the hardware resources of the video accelerator from a UEFI application: the lack of unification of equipment will require the developer to write drivers for all models of graphic processors.