Server evolution has largely overlooked the role of graphics. It's an understandable oversight -- client/server computing has traditionally focused on static, business-intensive workloads like databases and file serving. But the explosive growth in media delivery, application virtualization and even full desktop imaging through a virtual desktop infrastructure (VDI) has generated an acute need for visualization technology on the server side. Existing systems may warrant a graphics processing unit upgrade, while new systems will likely include a native GPU to accompany the processors.
Graphics goes beyond games
The term graphics often evokes images of gaming in all its fast-paced, visceral glory. And such applications have been completely inappropriate for enterprise client/server computing. But modern businesses are recognizing the increasing value of other graphics-intensive tasks like streaming media, image rendering and even advanced scientific mathematics -- tasks where server-side computing resources can easily be overwhelmed by the intense computing demands imposed by graphics operations. Desktop virtualization based on VDI has also been a driving force behind server-side graphics, allowing servers to support more demanding graphics tasks for each VDI instance. This in turn frees processor time and allows more VDI instances on each server.
Although the need for graphics support is growing, it's anything but clear that enterprises have the means to deploy graphics support at the server. If an existing server does not provide a graphics processing unit (GPU), one may need to be added. This can be accomplished by adding a GPU through a standardized expansion interface such as PCIe. One example is the NVIDIA Tesla K20X card. But expansion cards present wrinkles because server-class GPU expansion cards are large, power-hungry devices. Servers with adequate expansion room and power supply capacity can usually accommodate an internal GPU card. Otherwise, GPUs can be added externally using a self-powered GPU subsystem and connected through a PCIe adapter. An example of that includes the NVIDIA Tesla S1070 1U rack unit.
It's important to remember that graphics support is not an all-or-nothing proposition. Organizations do not need to spend the capital to upgrade every server immediately. Servers with graphics or visualization-based workloads can be migrated to a server fitted with GPU support. Other more traditional server workloads can remain on systems without GPUs. This can help organizations phase in GPU support over time.
But GPU support is quickly becoming standard fare for next-generation processors. Major processor makers like Intel, AMD and even ARM Holdings are fielding new processors with built-in GPUs. Examples include Intel's Xeon E3 family and AMD's Opteron X2150, and ARM's Cortex-A53 reference design includes such features for multimedia as video encoding and decoding and 2-D and 3-D graphics. In many cases, graphics support may be natively included in your next server refresh cycle by default, so consider your business needs and server vendor product roadmap for future graphics support before you make a substantial investment in GPU adapters for current systems.
Choosing a graphics processor
The choice of GPU will be tightly coupled to your hypervisor. When considering graphics support for a virtualized server, it's important to verify that the selected GPU hardware is fully supported by the hypervisor. This is critical in ensuring that the hypervisor can adequately virtualize the GPU and present a working virtual GPU (vGPU) to the VM.
As one example, VMware vSphere 5.1 could only use such NVIDIA-based GPUs as the NVIDIA Grid K1 and K2 cards, but vSphere 5.5 includes support for GPUs from Intel and AMD as well. IT professionals should take the time to test a prospective GPU with their selected hypervisor and perform benchmark testing under varied graphics loads to gauge performance over time.
Don't underestimate the importance of aligning GPU hardware with the hypervisor. Broader GPU support also allows greater heterogeneity in your selection of a server and GPU and reduces your reliance on specific vendor GPU models. But be careful to evaluate the future roadmap for your servers, GPU (especially if it's a separate or expansion-based subsystem) and hypervisor. It can be devastating for IT planners if a server refresh uses an integrated GPU that the current hypervisor doesn't support.
Configuring the vGPU
A processor typically has two options when it encounters an instruction or task: It can render, or handle, the task directly through hardware, or (if hardware is not available to tackle the task) it can handle the task through software (a process called emulation). IT administrators can select hardware- or software-based rendering when they configure a server's graphics resources.
If a GPU is available, graphics tasks (such as rendering) are handled quickly and efficiently through the GPU hardware at hardware speeds. This is the principal benefit of a hardware-based coprocessor.
If a GPU is not available or not supported, the graphics task typically can still be handled, but only through a series of software steps. In this situation, the main processor usually has to deal with many complex instructions in order to achieve the same output. So, software emulation inevitably results in poor graphics (and workload) performance.
The choice between hardware or software rendering typically depends on whether a supported GPU is available on the system. A selection can be made through the hypervisor or VDI management platform. For example, VMware administrators can set rendering through the vSphere Web client or VMware Horizon View console. If the hypervisor is able to detect the GPU, it may be best to set the choice to "automatic" and allow the hypervisor to set hardware rendering if it is able.
The choice of rendering modes can also affect VM migration planning. For example, if a VM is configured to use hardware rendering, it can't be migrated to another server unless the destination server also has hardware rendering. Otherwise the VM will incur a serious performance penalty. If the VM is set to use automatic rendering (a GPU is available), the VM can migrate to a target server that either has a GPU or doesn't.
GPUs are essential for any enterprise server handling graphics, visualization, desktop virtualization, and many forms of scientific computing or mathematics. While most current servers do not include GPUs, graphics subsystems can be added as upgrades on an as-needed basis, or an enterprise might choose to wait until it does a broader server-technology refresh, then select new systems that natively incorporate GPUs. Virtualized systems must also use GPUs that are supported by the hypervisor. This may limit the choice of available GPUs for the near term, but hypervisor GPU support will expand over time, allowing for greater system heterogeneity.