Games with UEFI
One of the most important innovations of the Unified Extensible Firmware Interface specification was the emergence and integration of a special UEFI Shell operating environment into the firmware of a personal platform that allows you to perform small tasks or a UEFI application without loading the operating system. In this context, first of all, we are talking about tasks related to the maintenance of the computing system: updating the platform firmware and peripherals, restoring the operating system modules after various failures, as well as the system information and diagnostics utilities. The mention of gaming applications, and even more so 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 for execution in the UEFI environment? If so, how? If not, then why?
In the early stages of the development of graphic subsystems of personal platforms, during the time of the ISA bus domination, 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 CPU, the output of the graphical object is reduced to recording the specified information at the specified addresses. Somewhat simpler, 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 such a model is the simplicity of the software and hardware implementations, the disadvantage is poor performance.
As you know, a modern video adapter is a “computer to computer”. The graphics processor, which is part of it, is capable of executing its own command flow, interacting with the platform's RAM in 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 the preparation in the operational memory of blocks of tasks for the graphic processor.
')
In a typical modern personal computing system, the bus, which connects the video controller chip to video memory, is characterized by bit widths and clock frequencies that are much higher than those for the main memory bus. And note that, unlike the CPU, the graphics processor does not use transit links (in the form of AGP or PCI Express tires) when accessing video memory. As a result, the obvious advantage is high performance. But there are drawbacks. About this below.
So historically, the industry has not developed a unified unified software model for low-level access to the video accelerator registers. Unification is implemented solely at the level of the driver software interface. The developer of applications running in the environment of modern operating systems do not need to worry about low-level interaction with the video registers of the controller because its manufacturer has provided a driver that takes on this task. The problem is that for the UEFI environment such an infrastructure is not provided.
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 the Legacy BIOS software interrupts, lay the foundation for creating such an infrastructure. But today there is a foundation, but there is no infrastructure.
A number of modern technologies allowed to “breathe a second life” into the implementation of graphics by means of the central processor. This is primarily about the use of 128 and 256-bit SSE instructions, as well as Write Combining technology, which allows you to combine the results of several processor cycles of writing into a packet of up to 4 kilobytes in size to be sent over the PCI Express bus. Sometimes, this approach allows you to get an acceptable result for 2D graphics as part of using the UEFI Graphics Output Protocol in combination with the “old-fashioned” visualization method:
Figure 1 . Screenshot taken from the UEFI environment in the process of launching the game Tetris64
But it is obvious that to achieve the functionality and performance realized by means of hardware graphics processors, this method will not allow.
We have to admit the impossibility of writing a UEFI application that implements 3D graphics with cinematic quality. Why? Unified protocols and ready-made drivers that provide 3D support for UEFI do not exist. It is also unrealistic to solve this problem by directly referring to the hardware resources of the video accelerator from the UEFI application: the lack of equipment unification will require the developer to write drivers for all models of graphics processors.
Recall all: software graphics output
In the early stages of the development of graphic subsystems of personal platforms, during the time of the ISA bus domination, 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 CPU, the output of the graphical object is reduced to recording the specified information at the specified addresses. Somewhat simpler, 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 such a model is the simplicity of the software and hardware implementations, the disadvantage is poor performance.
Computer in computer: hardware graphics output
As you know, a modern video adapter is a “computer to computer”. The graphics processor, which is part of it, is capable of executing its own command flow, interacting with the platform's RAM in 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 the preparation in the operational memory of blocks of tasks for the graphic processor.
')
In a typical modern personal computing system, the bus, which connects the video controller chip to video memory, is characterized by bit widths and clock frequencies that are much higher than those for the main memory bus. And note that, unlike the CPU, the graphics processor does not use transit links (in the form of AGP or PCI Express tires) when accessing video memory. As a result, the obvious advantage is high performance. But there are drawbacks. About this below.
Problems solved and not solved
So historically, the industry has not developed a unified unified software model for low-level access to the video accelerator registers. Unification is implemented solely at the level of the driver software interface. The developer of applications running in the environment of modern operating systems do not need to worry about low-level interaction with the video registers of the controller because its manufacturer has provided a driver that takes on this task. The problem is that for the UEFI environment such an infrastructure is not provided.
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 the Legacy BIOS software interrupts, lay the foundation for creating such an infrastructure. But today there is a foundation, but there is no infrastructure.
Compromises are possible
A number of modern technologies allowed to “breathe a second life” into the implementation of graphics by means of the central processor. This is primarily about the use of 128 and 256-bit SSE instructions, as well as Write Combining technology, which allows you to combine the results of several processor cycles of writing into a packet of up to 4 kilobytes in size to be sent over the PCI Express bus. Sometimes, this approach allows you to get an acceptable result for 2D graphics as part of using the UEFI Graphics Output Protocol in combination with the “old-fashioned” visualization method:
Figure 1 . Screenshot taken from the UEFI environment in the process of launching the game Tetris64
But it is obvious that to achieve the functionality and performance realized by means of hardware graphics processors, this method will not allow.
Summary
We have to admit the impossibility of writing a UEFI application that implements 3D graphics with cinematic quality. Why? Unified protocols and ready-made drivers that provide 3D support for UEFI do not exist. It is also unrealistic to solve this problem by directly referring to the hardware resources of the video accelerator from the UEFI application: the lack of equipment unification will require the developer to write drivers for all models of graphics processors.
Source: https://habr.com/ru/post/215105/
All Articles