Visualization is a great tool for understanding large amounts of data, but transferring the data from an HPC system or from the cloud to a local workstation for analysis can be a painful experience. It’s increasingly popular to avoid the transfer by analyzing and visualizing data in situ: right where it is generated. Moreover, using server-side rendering lets you deliver high quality visual content to any client hardware, whether it’s a DGX station or a smartphone.
Visualization tool developers increasingly support server-side rendering. Popular open source visualization tools like ParaView, VisIt or VMD, or commercial tools like Intelligent Light’s FieldView all take advantage of server-side rendering for big data workloads.
Intelligent Light and Daimler AG use server-based pipelines to analyze the results of their large-scale vehicle simulations, as Figure 1 shows. To validate thermal operating bounds when designing new vehicles, Intelligent Light’s FieldView can be used to visualize the results of highly-parallel simulations. Sifting through the 15 terabytes of data from this simulation is much more quickly done on the server that ran the simulation, after which the salient time steps can be extracted and used to visually communicate results.
Data analytics and machine learning tools such as MapD are also moving towards server-side visualization, demonstrating huge performance gains from accelerating the full server-side analytics pipeline. MapD scales their backend rendering across multi-GPU servers to deliver tens of frames per second with the 11.5 billion record dataset shown in Figure 2. This heatmap from MapD’s Immerse depicts areas near the Nova Scotia coast where fishing boats spend most of their time.
With the arrival of EGL, taking advantage of OpenGL on a headless server has become even simpler, making it unnecessary to run an X server or any other tools. It does, however, require some slight modifications to your OpenGL context management code using EGL functions, as described in a previous post.
Using EGL also requires you to link your application to different libraries. This post is about how to correctly link a modern OpenGL application.
The Need for GLVND
When the classic OpenGL Application Binary Interface (ABI) was introduced 17 years ago, the only widely adopted windowing and display management system on linux was X11. OpenGL context management, which is not part of OpenGL itself, was therefore synonymous with the glX API. And because the only way to use OpenGL on Linux was via glX, functions for both OpenGL and glX were bundled into the same library, libGL.so.
Linking an OpenGL application was simple: you only needed to link against libGL.so.
Over the years, the situation has changed and a wide range of display managers have emerged. People want to have X11-based display managers on the same system with Wayland, or to use hardware-accelerated OpenGL on the same system with software-emulated OpenGL. This requires a cleaner separation between the OpenGL library and OpenGL context-management libraries.
GLVND, the OpenGL Vendor Neutral Dispatch for Linux, was born to meet this requirement.
To use glX and OpenGL today, you should link against libOpenGL.so as well as libGLX.so. The first contains the OpenGL symbols, the latter the GLX symbols. If you want to use EGL context management instead, link against libOpenGL.so and libEGL.so.
GLX and EGL use the Same OpenGL
The separation of OpenGL functions and context management functions into separate libraries allows developers to build applications supporting multiple context creation mechanisms.
For instance, this enables you to add an EGL backend to your glX-based application to deliver cloud-based rendering capabilities. You need to modify the context creation mechanism, as described in a previous post, to initialize either glX or EGL. All the other rendering code remains the same. But now you need to link against libOpenGL.so, libGLX.so, and libEGL.so.
If your application uses OpenGL extension functions, it is your responsibility to use the correct extension function loader mechanism for the initialized context. A GLX-based context should use glXGetProcAddress, whereas an EGL-based context should use eglGetProcAddress. Note that the use of a particular loader may be implicit: GLEW, for example, uses the GLEW_EGL C preprocessor macro to choose the loader.
GLVND support in CMake
For larger projects you probably don’t want to add the different libraries manually, but rather delegate this to a build system like Kitware’s CMake. Starting with version 3.10.0, CMake supports GLVND natively through its FindOpenGL module. To utilize a specific context library, just specify it in COMPONENTS and use the appropriate import targets. For example, the following snippet compiles an application with support for both EGL and GLX contexts.
find_package(OpenGL REQUIRED COMPONENTS OpenGL EGL GLX) add_executable(your_binary_name main.c) target_link_libraries(your_binary_name PRIVATE OpenGL::OpenGL OpenGL::EGL OpenGL::GLX)
To link against EGL only, simply drop GLX from COMPONENTS and remove OpenGL::GLX as an import target in target_link_libraries.
find_package(OpenGL REQUIRED COMPONENTS OpenGL EGL) add_executable(your_binary_name main.c) target_link_libraries(your_binary_name PRIVATE OpenGL::OpenGL OpenGL::EGL)
Learn more about server-side rendering
The preferred way to use OpenGL on a headless server is via EGL, obviating the need for an X server. In addition to modifying your application’s context creation mechanism, this requires using the new GLVND ABI. Using GLVND is as simple as changing your application to link against libOpenGL and libEGL instead of libGL.
GLVND was first enabled in NVIDIA driver version 361.28, released in February 2016 and now widely available. In addition to an EGL ABI, the library also allows for a number of OpenGL implementations to live side-by-side on a system, simplifying deployment for your OpenGL applications.
Server-side rendering offers a range of advantages for large-scale visualization, including reduced data transfer cost, simplified application deployment and support for a wider client base.
To learn more about server-side rendering take a look at our previous posts: EGL Eye: OpenGL Visualization without an X Server and HPC Visualization on NVIDIA Tesla GPUs.
https://developer.nvidia.com/blog/parallelforall/hpc-visualization-nvidia-tesla-gpus/
