Using predictive scheduling for GPU virtualization in automotive infotainment designs
Editor’s Note: In this Product How-to development article the author uses Freescale’s i.MX Quad processor platform to describe the problems faced when using hypervisor virtualization in GPU-based automotive infotainment, navigation and instrumentation modules and some possible predictive scheduling solutions.
Hypervisor-based virtualization has become a hot topic in the field of consumer electronics design because it allows applications to share in the use of the new powerful graphics processor units (GPUs) from companies such as AMD and Nvidia. Designing with hypervisor-based virtualization is not simple to begin with, but the challenges become daunting when applied to automotive applications where the safety of the driver and the passenger is a crucial factor.
Three automotive subsystems that make use of the capabilities of a GPU include the instrumentation cluster, the electronic navigation subsystem, and infotainment options (Figure 1). In addition, but not shown in Figure 1, Camera based ADAS (Advanced Driver Assistance Systems) will be included in many next generation automobiles.
Figure 1: Independent cluster/GPU configuration
There is now a trend in new automotive designs toward consolidating these applications such that they can share in the use of a single GPU, which both increases processor utilization and lowers costs (Figure 2).
Figure 2: Virtualization-enabled sharing of GPU functions
This sharing is being achieved through the use of hypervisor-based virtualization middleware architectures, which in the automotive environment present a unique set of challenges including:
- Mixed criticality – Unlike the infotainment and navigation subsystems, the instrument cluster is a critical module that immediately affects the safety of the driver and passengers. It needs to access the GPU in a timely manner and with a certain level of determinism.
- Security – Software or media installed on the infotainment system by the driver and/or passengers may be infected with malware that could take over the GPU and affect the instrument cluster output.
Hypervisor virtualization can be used to deal with these challenges utilizing memory space isolation of applications and time frame isolation of applications (this is an inherently difficult task since GPUs are not preemptive).
Intelligent scheduling
Using Freescales’s i.MX 6 Quad (4x Cortex-A9@ 1.2GHz) platform (Figure 3), as an illustration, this article will describe how these goals can be achieved in an automotive environment.
Figure 3: The main features of the i.MX 6 Quad platform
An important factor that influences the approach taken is the GPU driver architecture. While the platform has three GPUs, we will concentrate the following exposition only around the infotainment cluster’s 3D GPU, as it is inherently the most complicated one and the approaches discussed will apply to the other GPU functions as well. The GPU’s software driver architecture is shown in Figure 4.
Figure 4: GPU software driver architecture
The GPU driver software is divided into two sections, one for user space operations and the other for kernel space functions. Data and commands are sent to the GPU through a front end interface. The data sets communicated deal with information about vertex position, attributes, color, and other “normal” vectors.
There are two types of commands: those that modify the state of the GPU and those that do not. LoadState commands modify the state of the GPU and include such things as shader instructions, choosing the type of primitive to draw, and setting the window size or the number of attributes per vertex. Commands that do not modify the GPU state include drawing a primitive, stall, wait, etc.
Loading comments... Write a comment