Energy Demand in AR Applications—A Reverse Ablation Study of the HoloLens 2 Device

Abstract

This study presents a comprehensive analysis of power consumption in the context of AR applications on the HoloLens 2. As an ablation study, the research systematically dissects various aspects, shedding light on both hardware and software components. The power consumption was examined in diverse scenarios, ranging from the device at idle to running AR applications of increasing complexity. Overall, the study provides insights into the power management aspects associated with Hololens 2 AR devices and applications, offering cues for optimizing energy efficiency and enhancing the user experience. The findings confirm that display-related factors, such as the screen brightness and content complexity, significantly impact power consumption. However, the results reveal that power usage does not scale linearly with the number of objects in an AR scene due to overhead factors and object occlusion. Furthermore, usage scenarios such as lighting conditions and large/minor user motions are analyzed. Moreover, the influence of different development platforms, Unity and Unreal, on power consumption is discussed, highlighting their respective contributions to energy usage. These findings might be useful for researchers, developers, and users of AR technology.

1. Introduction

Augmented reality appliances [1] are a class of modern devices that complement a real scene with computer-generated (CG) content (see Figure 1). Head-mounted holographic displays (HMDs) are the most advanced devices to date. They combine a real scene image with 3D computer graphics that are adopted interactively for the viewer. The latter is quite a complex task to ensure content coherence and hologram stability. During the user’s movement, it is necessary to perform SLAM (simultaneous location and mapping), orientation identification, recomputation, and visualization of the entire 3D scene for the changing PoV (point of view) [2]. The necessary calculations require significant computational capabilities enclosed into a small, glasses-like headset. This problem can solved with specialized hardware such as dedicated co-processors that perform the computations efficiently.

The challenges in terms of energy consumption arise from the fact that the HMD (head-mounted display) device is battery-powered and worn on the head. Therefore, the usability can be limited by frequent battery recharging and heat dissipation to the user’s head, which can quickly degrade user comfort [3]. The carbon footprint is of lesser importance for the case, as devices of this class are still not very numerous today, and they are battery-powered, so they are not power-demanding by design.

Since there are different variants and numerous points of view on the AR/VR technology, there is a proposal of a kind of continuum, with systems being MR (mixed reality) or XR (extended reality), given by Milgram and Kishino [4]. It is quite common to have reality at one end of the continuum and virtual reality as an entirely computer-generated environment at the other (see Figure 2). Various combinations are possible between them, each with varying contributions from these two basic image sources. In this model, AR (augmented reality) involves enhancing the primary real-world environment by seamlessly integrating CG (computer-generated) elements or leveraging CV (computer vision). On the other hand, AV (augmented virtuality) entails modifying a computer-generated environment with real-world information, such as the real-time status of visualized objects. Despite being more than 20 years old, the model still effectively describes the design of AR and VR systems. For the high-level design of applications, contemporary graphics engines like Unity and Unreal provide support for AR and VR through widely used XR toolkits. Additionally, the creators of OpenGL, known as the Khoros Group, have undertaken an initiative to develop a unified XR engine named OpenXR, which aligns with the concept of the AR/VR continuum.

Arguably, the earliest HMD for AR/VR, known as the Sword of Damocles, was conceived by Sutherland in 1968 [5]. It featured stereovision computer graphics with see-through capabilities and head tracking. The primary insight from its utilization was the significance of the “kinetic depth effect" (wherein the movement of the scene synchronized with the viewer’s head movement, akin to the real world) in enhancing immersion, surpassing the impact of straightforward stereovision and yielding a three-dimensional perspective.

The growing popularity of handheld AR devices with the increasing availability of VR headsets has spurred the development of sophisticated AR headsets as standalone, wearable devices. AR technology is closely related to conventional VR, which aims to immerse the user in an environment created entirely by computer graphics. Augmented reality, on the other hand, does not aim to hide the real environment but to introduce CG-generated content that enhances the visual information within the observed scene.

In this work, we report tests performed to evaluate the power consumed by the HoloLens 2 device (HL2). The tests were conducted systematically, employing various scenarios, which allowed us to determine how certain factors contribute to the HL2 power consumption while displaying a scene.

The choice of the device was based on several aspects. First of all, the HoloLens series of devices has a significantly larger market share than its direct competitor (Magic Leap One/Two), and Apple AR HMD (Apple Vision Pro) is about to be released to the audience in the near future. Moreover, the number of scientific articles returned by scholar.google.com indicates a significantly higher interest in the Hololens platform than its direct AR competitor platform. For a search since 2022 with the query “Hololens augmented reality”, we received 7570 results, whereas for the query “Magic Leap augmented reality”, there were 3750 entries, and for the query containing both names “Magic Leap Hololens augmented reality” there were 1220 results. This suggests that the HL platform is at least twice as popular as the competing one in the research community.

2. Power Management

Over the years, energy efficiency has become a crucial aspect of portable computing. It has been extensively studied at all levels of computer system design, starting with energy-efficient electronics [6] and progressing to optimizing software and system architectures. For the domain of this article, the focus is contributions to the design of computer systems on both hardware and software levels.

DVFS (dynamic voltage and frequency scaling) is a critical technique for energy efficiency in computing systems [7,8]. DVFS is a technique that dynamically adjusts the operating voltage and clock frequency (throttling) of a device’s processor(s) based on the real-time workload requirements. It enables peak performance for highly computation-intensive tasks while reducing power consumption when the device operations are less intensive. Voltage and frequency scaling are usually used together because lower frequency requires lower voltage.

The power gating technique involves the selective disconnection of certain components or subsystems within a device, effectively cutting off power to them [9]. It effectively addresses energy efficiency in portable devices and larger computing systems by eliminating unnecessary power dissipation and minimizing the standby power consumption.

Heterogeneous computing has emerged as a strategy for achieving significant energy savings in modern computing systems [10,11]. Heterogeneous architectures allow tasks to be allocated to the most appropriate processing unit based on their computational requirements by integrating different types of processing units, such as high-performance GPUs and specialized accelerators. This dynamic allocation ensures that energy-intensive tasks are offloaded to units optimized for high-performance computing. Less demanding workloads can be handled by more energy-efficient components. As a result, the overall energy consumption is reduced compared to traditional homogeneous architectures where all tasks are processed on a single type of unit.

Big.LITTLE is a variant of heterogeneous computing that optimizes energy efficiency while maintaining high performance in mobile and embedded devices. The architecture, developed by ARM [12], combines two compatible processor core types in a single SoC (system-on-chip). The SoC features “big” cores, which are designed for high-performance tasks, and “LITTLE” cores that are intended for low-power tasks. Big cores are designed for computationally intensive workloads, while LITTLE cores excel in power efficiency for lighter tasks and idle periods. The system switches intelligently between these cores based on the workload demands to achieve balanced performance and energy consumption by using the appropriate core type. This approach optimizes the energy usage by dynamically adapting to the workload. Modern operating systems should adopt big.LITTLE power-saving abilities for process scheduling. In Linux OS, the big.LITTLE architecture has been taken into consideration since kernel version 5.0 [13].

An interesting combination of the above is offered by Qualcomm in its Snapdragon processors. CPU is an asynchronous SMP (aSMP) architecture [14], similar to big.LITTLE. It features a heterogeneous approach by combining high-performance and low-power CPU cores on a single chip. The design includes both cores optimized for high-performance tasks and cores optimized for power-efficient operations (codenamed “Gold”, “Silver”, and so on). In addition, each core’s performance can be independently tuned to the current workload through DVFS, and cores can be turned on or off as needed. In addition, the entire SoC includes an integrated GPU and DSP, which further optimizes computations for power efficiency. All of this is especially important for the issues presented in this article, since Snapdragon serves as an SoC that functions as the primary processor of HL2.

Power monitoring and conservation have become an important consideration at the operating system (OS) level. With the advent of power management integrated circuits (PMICs) on motherboards, computers (especially notebooks) gained the ability to monitor the power consumed by applications actively. ACPI (Advanced Configuration and Power Interface) is a standard for power management [15], while its subset PMI (Power Meter Interface) is responsible for monitoring power consumption; these are supported at the operating system level [16]. On the user level, OSs offer a variety of software-level power management policies, such as suspending/hibernating, CPU frequency scaling, application-level power accounting, timed disk spin-down, screen savers, and display brightness adjustment based on ALSs (ambient light sensors).

3. Case Analysis of HoloLens 2 Device

The device of choice in our study is the HoloLens 2. The selection was carefully made among various proposals available, taking into consideration its capabilities, availability, and software support.

The HL platform runs on Windows 10 OS and has support for software development provided by the device vendor (MS Visual Studio + Mixed Reality ToolKit) as well as third-party solutions such as Unity or Unreal. The software development documentation in [17] provides detailed examples and addresses a broad range of topics relevant to the hardware and system’s capabilities. At the same time, Microsoft does not reveal extensive details regarding the hardware and software design, which impacts energy consumption management. The overall architecture for HoloLens 1 (Figure 3) was presented at the Hot Chips conference [18]. Then, the progress in the next generation—HoloLens 2—was revealed a few years later as a presentation [19] at the same conference.

Figure 3 shows the design of HL1. To the authors’ knowledge, the detailed architecture of HL2 has not been published, but on the basis of [19], we can assume that it generally follows the same concept. The main differences are:

• upgraded system-on-chip application processor from Intel Atom x5-Z8100P SoC to Qualcomm Snapdragon 850 Compute Platform (ARM-based);
• an improved HPU (holographic processing unit)—dedicated custom vision coprocessor. Changes include hardcoded operations for image processing and graphics, deep learning support for SLAM and object recognition, hologram stabilization, hand tracking, object recognition, and eye tracking.

Importantly, the HL device is designed with a focus on thermal comfort and low power consumption. It can be powered either with a USB DC power supply or with a custom-designed integrated battery connected through the PCM (protection circuit module). Although the manufacturer does not specify the battery capacity, it has been determined through reverse engineering [22] to be 4400 mAh at 3.78 V (16.7 Wh), which is comparable to modern smartphones. The power is supplied to the device’s components via PMIC chips.

One element that distinguishes HL and HL2 from other mobile computing devices is the display technology [23]. The image is rendered using LBS (laser beam scanning). The beam is directed by two moving mirrors into translucent waveguides that are the “screens”. The energy consumed by the display would be proportional to the brightness of the image projected by each of the RGB lasers. Importantly, the energy the laser device consumes might also depend on the wavelength (color) emitted.

By default, users and their applications do not have access to the HPU or most sensors. The operating system exposes data provided by these components as services through the Mixed Reality Toolkit (MRTK) development library. However, if the research mode [24,25] is enabled, direct access to sensor data is feasible. This mode allows developers to access the ToF (time-of-flight) depth camera, visual tracking cameras, and IMU sensors. An interesting aspect of the ToF camera is that it can operate in two (or three) different modes. It can sample for space mapping at either 1 Hz or 5 Hz, depending on whether the device is stationary or in motion, while it can sample at 45 Hz for hand tracking.

4. Materials and Methods

This analysis aims to identify the power consumption contribution of individual parts of the AR software and their usage in the HoloLens 2 HMD AR device by Microsoft, Redmond, WA, USA. From the point view of developers, the HMD device is a gray box. The general structure is known; however, the operational details, as well as the interaction between specific parts and intrinsic processes, are undisclosed or obscured by the design complexity.

4.1. Methodology

Ablation analysis, proposed in [26], is a useful technique employed in several fields of engineering [27,28,29] and scientific [30] research to evaluate the significance or impact of various factors or components in a complex system. This process systematically eliminates or disables specific elements or features of the system and observes how these changes impact the overall performance or behavior. The aim of ablation analysis is to gain comprehension of the significance of individual components and their effect on the system’s functionality.

In contemporary machine learning involving deep models [31,32], ablation analysis is frequently used to identify the role and/or importance of different features or neuron groups within a neural network. By selectively removing certain features or neurons and assessing how this affects the model’s performance, researchers can identify which components are critical to the model’s predictive power and which are less important.

An ablation analysis can also be performed in reverse order, which can be referred to as a “recovery” analysis. In a reverse ablation analysis, you first remove or modify components of a system and then reintroduce or restore them to observe how their presence or modification affects the system’s behavior or performance.

In our case, reverse ablation analysis is performed as follows. Having a complete AR application, we remove all its parts from the AR headset and “reconstruct” it from scratch by adding them incrementally in a series of successive test scenarios. Final tests involve a fully functional AR training application, displaying scenes of increasing complexity, from a single cube hologram to a scene where a massive amount of holograms is displayed.

4.2. Measurement Setup

The core of the experimental part is to measure the power consumption of an AR application running on an HL2 device. The measurements are performed with an external, custom-made measuring device connected to the USB power supply cable. The power source was the default charger supplied with the HL2. During the experiments, the tested device was placed on a custom-built stand. It was equipped with an electric motor that provided the drive and a gear that translated the rotation of the motor shaft into a horizontal swinging motion (between $-{35}^{\circ }$ and ${35}^{\circ }$ from the main view axis of the scene). The motor vibrations were intentionally not damped in order to mimic the micromovements of the user’s head (e.g., breathing). We considered three scenarios for the use of the platform: static, vibrating, and swinging (with vibrations). The overall experimental setup is shown in Figure 4a. Usually, the HL2 device was disconnected from the network or connected to a Wi-Fi network isolated from the external world in order to avoid uncontrolled HL2 device activity such as system or application updates.

The custom power monitor (Figure 4b) was based on the ESP32 (manufactured by Espressif Systems, Shanghai, China) and INA219 (manufactured by Texas Instruments, Dallas, TX, USA) modules provided the power consumption measurement. The HL2 was connected to the 18 W original power supply with a dedicated cable, which was extended by 50 cm using the USB-C 100 Gbps 100 W extender. The main VCC line of the extender was cut and connected with the Vin+ and Vin- ports of the INA219 module, and USB ground lines were connected with the GND module. The INA219 is a power monitor with a digital I2C interface that monitors both shunt voltage drop and bus supply voltage. The maximum power that the HL2 charger provides is 18 W (2 A at 9 V). The applied module can measure the voltage to 26 V and the current to 3.2 A with 12-bit precision. We decided to use the original power supply and the cables provided by Microsoft. The code for the ESP32 was developed using the Arduino framework and a simple INA219 library. In the main application loop, we report the timestamp, voltage, current, and calculated power as numbers with two decimal places using the serial interface. The applied text format of the output data could be easily grabbed, saved, and converted into a CSV file in any OS system. The timestamp resolution is measured in milliseconds since the device starts, which is sufficient for the 100 Hz measurement. The developed measurement method provides a transparent measurement of the USB power delivery without hardware modification using dedicated chargers and cables.

The tested application (Figure 5) is a training AR-based system (WrightBros Training System) that allows learning flight and maintenance procedures in complex technical facilities—flight simulators. The application is designed and compiled in the Unity environment. It involves displaying visual annotations (cubes or other shapes) in the scene, which are controlled by an external steering program (scenario player) running on a PC connected to the HL2 via local Wi-Fi, but the communication protocol utilized by the application is lightweight and minimizes network utilization. For spatial localization, we relied on the HL2 system’s default settings. When motion is detected, it automatically switches spatial sampling between 1 Hz and 5 Hz.

Additionally, for the needs of certain test scenarios’ execution, a generic application was compiled with an empty scene embedded into the code of the application.

4.3. Method Discussion

In the context of system energy consumption measurement, three competing approaches might be considered:

• external measurement—the measuring device is attached externally to the HL2 device. No modification to the software or operating mode is required. Therefore, this method does not affect the workload of the HL2 or the power consumed by the device. This method has certain drawbacks. The method assumes all the energy delivered into the HL2 device should be considered as used for the device activity. However, it measures the power delivered from the external power supply, but omits the energy stored in the internal battery of the HL2. The confusion might come from the fact that the battery is cyclically charged and discharged. To address this issue, the measurement procedure must be adjusted; the battery should be equally charged at the beginning and end of the experiment. The easiest way is to locate the state of the fully charged battery at the beginning and at the end of the whole charging/discharging cycle. Additionally, in order to verify whether the measurement is stable, it is favorable to capture several cycles. The case of capturing a whole charge–discharge cycle is illustrated in Section 4.4.
• operating system (OS)-level measurement—using API and services offered by the device OS, we can get access to the power consumption values reported by onboard sensors in PCM/PMIC. The advantages of this way are the fact that it does not need an external infrastructure and it is capable of measuring the power drawn directly at the battery level, so it can be convenient for application development. A notable disadvantage is the overhead to the power consumption caused either by the reporting and communication to the remote-controlling computer (using a web-based device portal or REST API) or by the system log process that stores the system status in a dedicated file. The other drawback is the fact that the HL2 API offers reporting only for the system consuming the power from the battery; an external power supply is not supported. Finally, the reports are 1 min average values, so deeper analysis (i.e., spectral) would not make much sense.
• application-level measurement—the tested application could trace power consumption by itself, utilizing the same API as the OS administrative tools. It has the same limitations as OS-level measurement—low time resolution and capability of measuring power consumption from the battery only. The advantage would be in the fact that no network connection is employed; furthermore, no additional process would be running in the background, so the overhead to the power consumption could be smaller than for OS-level measurement.

Of the above three methods, only the first one guarantees no influence of the measurement procedure on the results. The same drawback would affect further analyses, such as CPU, GPU, or memory utilization. When using external tools such as profilers, it is widely known that a “profiling overhead” to the computing is inevitable, so it would affect the results.

4.4. Preliminary Analysis

Before designing systematic experiments, a preliminary test was performed to observe whether any background processes or implicit activities were lurking in the OS. Such factors could potentially undermine the reliability of the results if not adequately considered in the experimental design. The preliminary test was to measure the power consumption of a stationary, idle HL2 device. It was conducted for over 67 h, with Wi-Fi and research mode on. The power time series is shown in Figure 6.

In general, the power time series is compound and, with exceptions, difficult to interpret, since it originates from the operations within a complex system. Nevertheless, it allowed us to identify some causes of power consumption. We visually recognized some quasi-periodic patterns. The long cycle is related to the day/night cycle and could result from the adaptation of the display to the ambient light measured by the ALS. The shorter cycle of about 15 min can be observed during the day and can be attributed to the battery discharge–charge cycle. Additionally, short peaks, repeating in about 5 min long cycles, are visible mainly during the night (because of low amplitude). They are of uncertain origin and could be any OS background activity. Further spectral analysis (Figure 7) also revealed a periodic pattern of 1 Hz fundamental frequency (and its presumed harmonics). We were able to link it to the depth camera’s operating cycle. Further analysis leads us to the conclusion that when motion is detected, the depth camera operates at 5 Hz.

Certain requirements for the measurement procedure are a corollary to the observations. First, the recording of successive scenarios should be performed under repetitive lighting conditions. Furthermore, the experiments should be conducted in both dark and illuminated environments. Notably, the length of the recording sequence must cover several recharge cycles so that the averaged values represent the overall energy delivered to the analyzed device.

4.5. Test Procedure

This study encompassed a dual-pronged analysis. Firstly, it exploited various levels of scene complexity; secondly, it involved the decomposition of the AR application and analysis of the contribution of certain components (such as the AR headset itself, SLAM, or just running app) to power consumption.

The tests were performed incrementally, from the idle device to the fully functional application, adding element-by-element to the system workload. This approach allowed us to determine the contribution of a newly engaged subsystem or software element to the overall power consumption.

The momentary energy consumption was measured for at least 40 min in each test scenario, so at least 2 charge/discharge cycles were present in the acquired data. The reported results are momentary values presented in the form of violin plots and accompanying statistical descriptors.

Additionally, Student’s t-test was applied to the results to compare the mean values in order to identify whether there were statistically significant differences in the power consumed for the selected cases. In the basic variant of the test, the null hypothesis suggests they are equal, whereas the alternative hypothesis indicates they are different. However, in our case, we employed the left-tailed variant, which identified whether one sample set had a median smaller than the other set at a significance level of 0.01.

4.6. Test Scenarios

Two sets of test scenarios were employed during the experiments. The first group was oriented to the analysis of power consumed by the system. These tests included several use cases that involved incremental system usage (reverse ablation) from an idle device to a fully functional AR application. Some of these tests were further extended to elaborate sub-variants. The second group was focused on the analysis of power consumption in relation to the complexity of scenes within the AR application.

System analyzing scenarios involved:

• idle device—causes minimal power consumption necessary to sustain the operating system. No content was displayed. The device remained stationary, resulting in rare SLAM computations. The Wi-Fi connection was turned off. The device was located in a well-lit room.
• idle device in a dark environment—all conditions from the “idle device” case were fulfilled; additionally, the room in which experiments were conducted was darkened.
• idle device with Wi-Fi connection active—All conditions from the “idle device” were fulfilled, besides the Wi-Fi connection. The router to which the HL2 was connected allowed internal traffic only.
• idle device vibrating—the same as “idle device”, but additionally, the HL2 was suspended on a moving platform that was vibrating.
• idle device swinging—the same as “idle device”, but additionally, the HL2 was suspended on a moving platform that was swinging horizontally from −35 to 35 degrees.
• “hello world” app—this case is similar to “idle device”, but a generic application developed in the Unity engine with an empty scene was running in the foreground. No visual effects were displayed on the screen; however, a scene representation in the memory was present.
• “hello world” app with white fullscreen—this case is similar to the previous one. The application was designed to maximize power consumption by displaying white pixels throughout the entire screen. The workload of the GPU was negligible since there were no contents of the scene. The screen color was obtained via the camera property configuration, so it can be considered a canvas.

In all the trials, the screen brightness was set to 5 out of 10 on the HL2 device’s scale.

Additionally, we elaborated on some of the basic scenarios, namely, p. 6 and 7, for deeper insight into the HL2 system:

• the full-screen-display experiment from p. 7 was modified and repeated in order to analyze the contribution of each individual color channel (red, green, blue) separately to the overall power consumption of the display.
• the “hello world” application (as in p. 6), originally created in the Unity development platform (v. 2022.3.6f1), was also implemented in the Unreal (v. 5.1) engine. It allowed us to compare the contribution of the software development platform to power usage.

The second phase of the experiments, scene analyzing scenarios, was designed to determine how power consumption scales with the increasing complexity of the AR scene. The test application was a complete AR application that interacted with the controller PC via Wi-Fi. The HL2 device was mounted on the moving platform in vibration mode, so moderate SLAM computations were involved. The screen brightness was set to 5 out of 10 on the HL2 device scale. The room was well-lit. The scene was anchored to the QR code placed in the test environment. The QR code detection was performed once, explicitly by the user, during the application initialization procedure. The virtual scene consisted of a number of holographic blue cubes evenly distributed in a volume in the center of vision, and no additional light source was placed in the scene. The only source of light in the scene was the emissive material of holographic objects in the scene. They do not interfere visually with each other because they cast no shadows and do not light the surroundings. The cases tested were as follows:

• 0 cubes—identifies the base power consumption level
• 10 cubes
• 50 cubes
• 100 cubes
• 200 cubes—as of this case, the cubes are located in planes; therefore, they partially occlude
• 500 cubes—the cubes are distributed in 5 planes one after another, so many are occluded

5. Results and Discussion

In this section, we present the measurement results of all the discussed experiments. The results in the respective figures are presented as violin plots based on the momentary power consumption values.

Violin plots [33] resemble box plots but give better insight into the distribution of values. They plot the probability density function obtained for the data using the kernel estimation method. Additionally, the plots are annotated with all the components known from more common box plots. The median is represented by a white dot, and a horizontal bar represents the mean value. The interquartile range is indicated by bold whiskers, and the adjacent value range is represented by thin whiskers (upper/lower quartile $+/-$1.5 IQR).

The cases were divided into two groups:

• analyzing the power consumed by the HMD system considering various hardware, software, and environmental aspects:

  −

  engaging/disengaging HL2 subsystems (Figure 8 and Figure 9),

  −

  analyzing the contribution of the display (Figure 10),

  −

  analyzing the role of the software development platform (Figure 11),

• characterizing the power consumed depending on the workload connected with displaying CG contents of varying complexity (Figure 12).

5.1. System Analysis

Figure 8 provides an overview of the general system characteristics, illustrating the power usage of the HMD with various subsystems engaged.

Figure 8. Power consumption violin plots for various HL2 subsystems engaged.

Figure 8. Power consumption violin plots for various HL2 subsystems engaged.

We clearly observe that engaging/disengaging certain subsystems of the device causes a change in the power consumption. However, since HL2 is a complex system, it is not so straightforward. Regarding the average power consumption, the observations can be summarized in a few key points (order as in Figure 8):

• The baseline power consumption level for the idle device is 6.05 watts, which serves as the reference point for other scenarios.
• Using the device in dark conditions leads to a reduction in power consumption of 0.7 watts (decrease of 11.6%).
• A low activity of turned-on Wi-Fi for an idle device increases the power consumption by 0.2 watts (increase of 3.3%).
• Minor HL2 motion (vibrations) does not significantly change the power consumed by an idle device. Apparently, minor movement did not cause an increased workload for the SLAM; the IR ToF camera worked at 1 Hz.
• Notable HL2 motion increases the power drawn by 0.2 watts (increase of 3.3%); the IR ToF camera worked at 5 Hz.
• Surprisingly, starting a “hello world” application led to a reduction in power consumption by 0.2 watts (decrease of 3.3%). A plausible explanation for this phenomenon is that when the foreground application was launched, the operating system adjusted the scheduling priorities, favoring the foreground process over the background ones. In this case, the foreground application had minimal computational demands, leading to an overall reduction in computing workload. Please keep in mind that the test application was minimalistic, but in general cases, when the CPU and/or GPU are intensely used, the power consumption would be notably higher.
• The same “hello world” application as above with a fully engaged display increases the power consumption by 2 W (increase of 33.1%).

The formal test (left-tailed Student’s t-test) is shown in Figure 9. It compares the mean values of the power consumed between scenarios. In the figure, each row and column represent the scenario, and in their intersection, “1” indicates that the test favors the alternative hypothesis over the null, i.e., that the mean value for the case in the row is statistically smaller at the given significance level ($\alpha =0.01$) than for the column. The test results clearly confirm the observations based on the violin plots.

Figure 9. Student’s t-test left-tailed test for power values. “1” indicates that the mean for the case in the row is statistically smaller ($\alpha =0.01$) than for the column.

Figure 9. Student’s t-test left-tailed test for power values. “1” indicates that the mean for the case in the row is statistically smaller ($\alpha =0.01$) than for the column.

Recognizing that the display exerts a substantial role in the power consumption of HL2, the investigation (as illustrated in Figure 10) looked into the energy consumption of individual RGB channels. It is important to note that power consumption is influenced by the ambient lighting conditions, so our tests also took this factor into account.

Changes in power consumption between dark and well-lit conditions remain consistent regardless of the colors tested. The green channel slightly exceeds the red and blue channels in power demand, but the difference is minimal, with a variation of only 0.1–0.2 watts. Interestingly, the power utilization for the white color does not result from the simple sum of the energy demands of its individual RGB channels.

Figure 10. Power consumption violin plots for basic colors displayed on full screen.

Figure 10. Power consumption violin plots for basic colors displayed on full screen.

The power consumption of the two main development graphics engines was another aspect we decided to work on. In addition to Unity, the “hello world” application was also developed and compiled in Unreal. Both applications were compared in the dark and well-lit conditions. The power usage for these two scenarios is shown in Figure 11.

Figure 11. Power consumption violin plots for “hello world” application for different development platforms.

Figure 11. Power consumption violin plots for “hello world” application for different development platforms.

We observed a noticeable difference in power consumption between “hello world” applications developed in these two engines. In both dark and well-lit conditions, the difference between Unity and Unreal is about 1.2 watts favoring Unity, which is an approximately 20% increase. We did not run the formal statistical test, since the difference is much larger than those noted as statistically significant in the previous scenarios, where a t-test was used.

It is worth mentioning that one should not draw too far-reaching conclusions about the energy efficiency of these engines based on these observations. The power consumption for complex scenes can vary, as it depends on many implementation factors.

5.2. Scene Analysis

Figure 12 presents how the energy demand scales with the growing complexity of the AR scene, ranging from 0 to 500 cubes. Additionally, average watts per cube values are provided in

Table 1. Average power consumed per cube.

Cubes	0	10	50	100	200	500
Watts per Cube	–	0.0068	0.0028	0.0028	0.0021	0.0016
Screen Coverage	0%	1.13%	4%	8.14%	11.29%	20.8%

.

Figure 12. Power consumption violin plots for various numbers of cubes in an AR scene.

Figure 12. Power consumption violin plots for various numbers of cubes in an AR scene.

The fact that the power consumed depends on the number of elements to be rendered is clearly visible in Figure 12. However, the scaling of power usage in these scenarios requires some interpretation.

For a small number of objects, the difference in power utilization between ten and fifty cubes is about 0.076 watt. However, despite the small difference in absolute power consumption for these cases, the relative cost per cube differs notably. We suppose this fact can be justified by the need to engage the graphical pipeline and set up the camera and the scene. In cases when there is a small number of (less than 50) object instances, the overhead is more evident than in alternative scenarios. Therefore, power consumption does not scale linearly. However, for further cases—50, 100, and 200 to some extent—since overhead has a relatively lesser significance, we obtained a linear dependency with a nearly constant cost per cube.

The deviation from linear scaling observed in scenes featuring a greater number of cubes can be attributed to the occlusion of cubes within the display. At first, it was observed for 200 cubes, of which 150 were visible in the foreground and 50 were partially behind the others. The effect was even more prominent in the case of 500 cubes, where 350 were partially behind the foreground cubes. Thus, the screen coverages did not scale linearly, resulting in a proportionally smaller contribution to the power demand from the display.

6. Conclusions

In this study, we described an analysis of the power consumed by an AR application deployed in the most common AR headset—HoloLens2. In this study, we adhered to the standard application development approach, as recommended by the HL2 vendor.

The contributions of this study are several-fold. They are related to the hardware, OS operating, and application development.

Firstly, the systematic approach helped to determine the power consumption caused by specific components of the HL2 system (hardware and software). We identified a small contribution to the power demand incurred by such elements as Wi-Fi or motion sensors. The display, on the other hand, can cause a significant power draw, which depends on the projected area of displayed contents and its color as well as the viewing conditions.

Another aspect is the displayed scene complexity. We identified that establishing the CG scene can be considered a constant, small overhead. Its contribution is notable for scenes of low complexity, but it becomes negligible when the number of objects in the scene increases.

Finally, we identified that graphical engines utilized for the purpose of AR application development could significantly influence the power consumption of the resulting applications. During the tests comparing graphical engines, we observed a 20% advantage in favor of Unity. This difference is significant both statistically and practically.

With efficiency in mind, we aim to deliver certain visual information to the user, using as little as possible power drawn (Watts). Aside from the trivial conclusion that a smaller/simpler scene implies smaller energy consumption, the optimizations might include:

• the selection of engine—our results favor Unity over Unreal.
• the scene design should remove or hide unused objects from the user’s view; this is because we have identified that visual coverage of the display by the contents contributes to the overall energy consumption.
• by employing occlusion of objects in UI/UX, if used smartly (e.g., layered layout), it could reduce the energy drawn by displaying mostly first-plane objects.
• also, the size of the displayed object may matter; however, it would be a trade-off with usability since larger objects are easier to notice and reach.

Summarizing, this study provides insights into the power usage and management aspects of AR devices and applications, offering cues for optimizing energy efficiency and enhancing usability. The findings can be useful for both application developers and users in improving the usability of AR systems. Further studies may explore other aspects of application development and alternative HMDs, including incoming Apple Vision Pro.