Cross-platform evaluation of graphics capabilities in the context of UEFI
Unlike systems with x86 architecture, the use of UEFI ( Unified Extensible Firmware Interface ) on ARM platforms did not become a top in IT news. It does not follow from this that the extensible interface of proprietary software is an idea only for the personal computer market. The UEFI specification declares universal approaches for initializing any hardware and its interaction with the operating system.
Due to the fact that the UEFI specification supports all common computer system architectures, I would like to compare their hardware performance from a “clean slate”, i.e. before running driver support. It is especially interesting to look at the work of graphics on competing processor platforms. Is it as good as the producers say? NVidia, for example, releases Tegra to work with ARM, and GeForce for personal systems.
To answer this question, we decided to use our UEFImark utility , which measures the recording speed in video memory and displays information about the graphic capabilities of the system, on the EFI Byte Code rails .
')
As you know, the EFI Byte Code (EBC) is a fairly elegant method for developing cross-platform software within the UEFI specification. His idea is obvious and not new - a program written in the command system of the nowadays registered virtual machine can be executed on any hardware platform equipped with a command interpreter program.
For visualization of graphic information in the UEFI environment, as well as as an object for benchmarks, the GOP ( Graphics Output Protocol ) is used. As part of this UEFI protocol, the BLT ( Block Transfer ) function is used. This function builds on the screen of a rectangular object, receiving from the calling procedure as input parameters its coordinates, dimensions and contents.
Unlike UEFImark x64 Edition, the UEFImark EBC Edition application does not use direct access to video memory, as in systems with architectures other than PCs, this visualization method may not be supported. To declare this situation, a special attribute BltOnly is provided. More precisely, it is planned to use direct access to video memory, but only when an x86-compatible platform is detected and video memory is available in the address space.
Refer to the last line of the system information screen - GOP.BLT, FPS. It contains two parameters:
The result of running the utility UEFImark, EBC Edition, on the platform of ASUS T100T, equipped with a 64-bit Intel Atom Z3740 processor, running 32-bit UEFI firmware
In these tests, the size of the rectangle is set equal to the size of the screen. To measure time, a timer is used implemented in the framework of the CPU Architectural Protocol (CAP), the access method to which does not depend on the hardware features of the platform. The amount of video memory used to represent the screen depends on the horizontal and vertical resolution, as well as the number of bits per pixel. Accordingly, the greater the resolution and the number of bits per pixel, the greater the volume required to process. Therefore, the number of frames per second or FPS (frames per second) will be different for different video modes. When comparing the performance of two systems, they need to use the same video modes.
Why in the benchmarks of the EBC version we switched from measuring the recording speed to video memory in megabytes per second, to measuring the integrated performance of the video subsystem in frames per second or FPS?
Accurate bus bandwidth measurement is possible only for native code that directly writes to video memory, since between those moments of reading the initial and final states of the timer, only those operations whose execution time is to be measured must be located. When using the GOP.BLT and UEFI API technologies, this condition is not feasible, since the called API procedure performs not only the block transfer itself, but also a number of auxiliary operations. The main ones are the preparation of parameters for sending the block, transferring control to the subroutine, saving the parameters, restoring the parameters, returning from the subroutine, etc. Therefore, the integral parameter FPS is used for these graphical visualization methods.
The upcoming version 0.13 supports issuing 8-bit debugging codes to an 8-bit port with the address 80h. When debugging, the device is IC80v5.0 manufactured by IC Book Labs. In order to ensure the operation of the program on platforms with architectures other than x86, issuing codes to port 80h is performed only if the x86 platform is successfully detected in conjunction with the firmware IA32 EFI or x64 UEFI. In order to ensure operability in an emulated environment, the issuance of codes to port 80h is performed only if the program is running in supervisor mode, namely the current privilege level (CPL) defined by bits [1.0] of the code segment register (CS) is zero , which means the absence of an emulator or the absence of a mode for intercepting calls to I / O ports. Practice has shown that output to port 80h can cause an abnormal termination of the emulator.
EBC support is implemented today in the framework of the UEFI firmware of the following four types of platforms: IA32, x64, IPF (Itanium Processor Family) and ARM, therefore, our maximum program is this: the functionality of the information utility UEFImark v0.96, implemented today exclusively for the x64 UEFI environment, provide in a single utility UEFImark EBC Edition for the four types of platforms listed above.
Due to the fact that the UEFI specification supports all common computer system architectures, I would like to compare their hardware performance from a “clean slate”, i.e. before running driver support. It is especially interesting to look at the work of graphics on competing processor platforms. Is it as good as the producers say? NVidia, for example, releases Tegra to work with ARM, and GeForce for personal systems.
To answer this question, we decided to use our UEFImark utility , which measures the recording speed in video memory and displays information about the graphic capabilities of the system, on the EFI Byte Code rails .
')
As you know, the EFI Byte Code (EBC) is a fairly elegant method for developing cross-platform software within the UEFI specification. His idea is obvious and not new - a program written in the command system of the nowadays registered virtual machine can be executed on any hardware platform equipped with a command interpreter program.
Work with graphics
For visualization of graphic information in the UEFI environment, as well as as an object for benchmarks, the GOP ( Graphics Output Protocol ) is used. As part of this UEFI protocol, the BLT ( Block Transfer ) function is used. This function builds on the screen of a rectangular object, receiving from the calling procedure as input parameters its coordinates, dimensions and contents.
Unlike UEFImark x64 Edition, the UEFImark EBC Edition application does not use direct access to video memory, as in systems with architectures other than PCs, this visualization method may not be supported. To declare this situation, a special attribute BltOnly is provided. More precisely, it is planned to use direct access to video memory, but only when an x86-compatible platform is detected and video memory is available in the address space.
Benchmarks
Refer to the last line of the system information screen - GOP.BLT, FPS. It contains two parameters:
- The Fill parameter is the result of measuring the performance of the GOP.BLT.Fill procedure, which performs the construction of a monotone rectangle on the screen, by filling specified sections of the video memory with a given constant.
- The Copy parameter is the result of measuring the performance of the GOP.BLT.Copy procedure, which builds a rectangle on the screen, the pixel content of which is provided to this procedure in a buffer stored in RAM. The contents of this buffer are copied to specified parts of the video memory.
The result of running the utility UEFImark, EBC Edition, on the platform of ASUS T100T, equipped with a 64-bit Intel Atom Z3740 processor, running 32-bit UEFI firmware
In these tests, the size of the rectangle is set equal to the size of the screen. To measure time, a timer is used implemented in the framework of the CPU Architectural Protocol (CAP), the access method to which does not depend on the hardware features of the platform. The amount of video memory used to represent the screen depends on the horizontal and vertical resolution, as well as the number of bits per pixel. Accordingly, the greater the resolution and the number of bits per pixel, the greater the volume required to process. Therefore, the number of frames per second or FPS (frames per second) will be different for different video modes. When comparing the performance of two systems, they need to use the same video modes.
Frames or megabytes per second
Why in the benchmarks of the EBC version we switched from measuring the recording speed to video memory in megabytes per second, to measuring the integrated performance of the video subsystem in frames per second or FPS?
Accurate bus bandwidth measurement is possible only for native code that directly writes to video memory, since between those moments of reading the initial and final states of the timer, only those operations whose execution time is to be measured must be located. When using the GOP.BLT and UEFI API technologies, this condition is not feasible, since the called API procedure performs not only the block transfer itself, but also a number of auxiliary operations. The main ones are the preparation of parameters for sending the block, transferring control to the subroutine, saving the parameters, restoring the parameters, returning from the subroutine, etc. Therefore, the integral parameter FPS is used for these graphical visualization methods.
Debugging Features
The upcoming version 0.13 supports issuing 8-bit debugging codes to an 8-bit port with the address 80h. When debugging, the device is IC80v5.0 manufactured by IC Book Labs. In order to ensure the operation of the program on platforms with architectures other than x86, issuing codes to port 80h is performed only if the x86 platform is successfully detected in conjunction with the firmware IA32 EFI or x64 UEFI. In order to ensure operability in an emulated environment, the issuance of codes to port 80h is performed only if the program is running in supervisor mode, namely the current privilege level (CPL) defined by bits [1.0] of the code segment register (CS) is zero , which means the absence of an emulator or the absence of a mode for intercepting calls to I / O ports. Practice has shown that output to port 80h can cause an abnormal termination of the emulator.
Summary
EBC support is implemented today in the framework of the UEFI firmware of the following four types of platforms: IA32, x64, IPF (Itanium Processor Family) and ARM, therefore, our maximum program is this: the functionality of the information utility UEFImark v0.96, implemented today exclusively for the x64 UEFI environment, provide in a single utility UEFImark EBC Edition for the four types of platforms listed above.
Source: https://habr.com/ru/post/212363/
All Articles