Visualizing data — analytic rendering via Khronos

Data science and visual computing - by Jon Peddie

Credit: Jon Peddie - TechWatch JPR

Last month I wrote about a new book on Data science and visual computing. The book tells us, as we already well know, we are awash in data. It’s like the weather, we know it, we can’t manage it. We are struggling to get a grip on it, understand it, use it and exploit it, but it is being generated faster than we can harness it.

What’s more, there are a dozen or more ways to funnel that data to a display with multiple pipelines and APIs. It is a hodgepodge of software that has evolved from the early 1980s (I know because I contributed to the mess we have today).

With SaaS, and DaaS, and virtual displays, plus VR, CAVEs, and holographic display systems, streamlining the data-flow process would be a godsend.

Here comes Khronos to save the day with an exploratory committee to discuss the standardization of an analytic rendering API for data visualization. Khronos is inviting all interested parties to participate. There is no cost or IP obligations to share perspectives, requirements, and use-cases to help determine whether there is an industry need for such an API and to help set the direction for any standardization activities.

Analytic rendering, as defined by Khronos, is image generation performed primarily to gain and communicate insights into complex data sets. Scientific visualization is the primary application domain using Analytic Rendering today, followed by the emerging data analytics space.

Recent advances in rendering technology, especially the introduction of real-time ray tracing, has the potential to significantly impact data visualization by providing physically accurate imagery and visual cues for an intuitive understanding of complex data. However, using these graphical techniques can come at the expense of increased application development cost and complexity. Graphics APIs such as Vulkan, and its upcoming ray tracing extension, provide powerful rendering hardware abstractions but might be too low-level and time-consuming for many visualization applications to utilize effectively.

Consequently, several hardware vendors have developed higher-level rendering APIs, such as Intel’s OSPRay and Nvidia’s VisRTX, but this leads to ecosystem fragmentation as visualization applications need to be ported to multiple, incompatible platforms.

An open, higher-level analytic rendering API standard has the potential to significantly reduce software development costs and make advanced rendering techniques more accessible for visualization applications that require rendering as a matter of course. In addition, an API could provide portability to multiple platforms that support the common API. Khronos summarizes the problem and proposed solution with the following visualizations.

Situation Before

Visualization applications must be ported to multiple rendering APIsVisualization applications must be ported to multiple rendering APIs

Situation After

Diverse rendering backends can be accessed through a single high-level APIDiverse rendering backends can be accessed through a single high-level API

The goal of this initiative would be to define a high-level API to simplify the development of visualization applications and exploit the full potential of modern rendering capabilities. Khronos’ Analytic Rendering Exploratory Group is proposing to define a concise, high-level API as a contract between visualization domain experts and rendering technologists, enabling a “win-win” by simplifying implementation and deployment for both groups. Some key goals include:

  • Create an open, royalty-free API that is platform-independent—enabling visualization applications to portably access diverse rendering backends
  • Provide visualization applications access to the full range of modern rendering capabilities and engines, including—but not restricted to—the latest ray tracing techniques
  • Free visualization domain experts from the necessity of dealing with non-trivial rendering details and multiple incompatible backend rendering APIs
  • Enable developers of rendering backends to avoid the need to implement domain-specific functionality and optimizations through supporting a well-designed, cross-platform API standard, making their backend renderers accessible to a wider range of disciplines and audiences.

Analytic Rendering API Design

Rather than specifying the details of the rendering process, the Analytic Rendering API would enable a visualization application to simply describe the relationship between objects in a scene to be rendered and leave the details of the rendering process to a backend renderer. Unlike more general scene graph APIs, the proposed initiative would focus specifically on the needs of the visualization domain—and as with any successful interoperability standard, the proposal would enable and encourage a diverse range of competitive API implementations.

Visualization-focused applications simply describe objects in a scene to gain portable access to a competitive range of rendering backend implementationsVisualization-focused applications simply describe objects in a scene to gain portable access to a competitive range of rendering backend implementations

If there is industry support, Khronos will form a Working Group to enable any interested company to join Khronos and participate under its proven multi-company governance process. to gather industry input, the Exploratory Group is open to any company without cost or IP licensing obligations. Those interested in learning more and joining the Exploratory Group are invited to .(JavaScript must be enabled to view this email address).

What do we think?

We like it. Imagine if you could take a dataset to any display device in any facility and run it in any heterogeneous environment without needing IT people to write special drivers or containers for you.

Khronos doesn’t usually get this public about their potential initiatives unless there’s strong initial support. Therefore, we encourage everyone who is interested to get involved and have their say so we can get this API underway, and—like other Khronos APIs—have it come to fruition and be widely adopted very quickly. It’s one of those cases of why wouldn’t you want such a thing?

Authored by