CrossGL: Unified Intermediate Representation

• CrossGL is a unified intermediate representation that normalizes heterogeneous programming languages for GPU compute, graphics shading, and systems programming.
• It operates through a three-stage pipeline—parsing, IR conversion, and code generation—to simplify cross-language translation and reduce engineering costs from O(n²) to O(n).
• Empirical evaluations show 100% success across eight backends, validating its capability to preserve high-level semantics and support modern, diversified programming paradigms.

CrossGL most directly denotes the unified, language-agnostic intermediate representation at the core of CrossTL, a universal programming language translator for bidirectional translation across GPU compute, graphics shading, and systems languages. In that role, CrossGL functions as the central “pivot” language through which CUDA, HIP, Metal, DirectX HLSL, OpenGL GLSL, Vulkan SPIR-V, Rust, and Mojo are imported and regenerated, with Slang support in development. Its stated purpose is to replace the pairwise translator model, whose engineering cost grows as $O(n^2)$, with a single-intermediate-representation architecture that scales as $O(n)$ in language-specific components (Niketan et al., 28 Aug 2025).

1. Definition and conceptual scope

CrossGL, expanded in the paper as “Cross Graphics Language,” is presented as a unified intermediate representation rather than as a conventional single-platform shading language or a viewer runtime. Within CrossTL, it mediates translation by receiving source-language structure from language-specific parsers and ToCrossGLConverter modules, then serving as the basis for target-language CodeGen backends. The paper attributes three central roles to it: mediation of translation, preservation of high-level semantics, and extensibility through language-specific frontend and backend components (Niketan et al., 28 Aug 2025).

The motivating problem is translator combinatorics. Traditional multi-language translation requires distinct translators for each language pair; CrossGL is introduced to eliminate that requirement by routing all conversions through one IR. This establishes a uniform representation for languages that differ in surface syntax, type systems, resource models, and domain emphasis, including GPU kernels, graphics shaders, and systems-language constructs. A plausible implication is that CrossGL is intended not merely as a syntactic interchange format, but as a semantic normalization layer for heterogeneous programming environments.

2. Position within the CrossTL architecture

CrossTL is organized as a three-stage pipeline: parsing, IR conversion, and code generation. Source code is first parsed into a language-specific abstract syntax tree. That AST is then mapped into CrossGL by a ToCrossGLConverter, after which the CrossGL program is traversed by a target-specific CodeGen module to produce target-language AST or source code. The paper depicts this architecture explicitly as:

[Source Code] | V (Language-specific Parser) | V [Language AST] | V (ToCrossGLConverter) | V [CrossGL IR] | V (CodeGen) | V [Target Language Code]

This organization makes CrossGL the canonical internal form of the entire framework. Frontends handle operator precedence, control-flow reconstruction, type reification, and language-specific idioms; backends perform template-based generation with context-aware adaptation for resource bindings, memory models, and target syntax. The paper’s extension model follows directly from this structure: adding a new language requires only a parser and a code generator for CrossGL, after which translation to and from all existing languages becomes available (Niketan et al., 28 Aug 2025).

The architecture is explicitly bidirectional. The same CrossGL representation is used for import from diverse source languages and export to diverse targets, which is important because the framework is not limited to one-way lowering from a high-level language into backends. Instead, it is designed for cross-compilation among multiple peer languages.

3. Internal representation and semantic model

CrossGL’s internal design is described in terms of a unified type system, language constructs, an attribute and annotation system, and IR classes or interfaces. The type system includes primitives such as int, float, and bool; vector types such as vec2, vec3, and vec4; arrays with dimensional metadata; and structs for aggregate data such as vertex formats. The paper gives representative examples including float values[1024];, vec3 positions[256];, and a Vertex struct containing position, normal, and texCoord fields (Niketan et al., 28 Aug 2025).

Its construct space covers arithmetic, logical, and comparison expressions with explicit types; statements including declarations, assignments, if, for, while, and switch; first-class functions with annotated parameter and return types; struct definitions and member access; memory operations over buffers, arrays, and pointers as appropriate; and GPU- or graphics-specific entities such as shaders, kernel definitions, and resource bindings. This is the basis for the paper’s claim that CrossGL captures semantics from multiple programming paradigms rather than only from shading languages narrowly construed.

The annotation system is central to preserving intent during lowering. The paper specifically identifies GPU kernel qualifiers such as __global__ and __device__, shader stage labels such as vertex and fragment, and target-sensitive metadata such as resource bindings and buffer layouts. These annotations are intended to preserve source semantics without “polluting the core IR,” allowing target-specific adaptations to be deferred until backend generation (Niketan et al., 28 Aug 2025).

CrossGL is also modeled as an explicit object structure. The paper states that each core IR entity—Program, Function, Struct, and Variable—is represented as a class, with methods for validation, optimization, and code generation through visitor or template patterns. An illustrative specification appears as a Pythonic CrossGLProgram class holding lists of functions, structs, and globals. This suggests that CrossGL is designed as a manipulable compiler IR with internal APIs, not merely as a textual interchange syntax.

4. Translation mechanics and extensibility

The frontend phase translates language-specific ASTs into CrossGL. Each supported source language has a dedicated parser, and the converter bridges language-local idioms into CrossGL’s abstractions. The paper’s examples include normalizing constructs such as Metal’s float4 into CrossGL’s vec4, as well as mapping kernel or shader forms into CrossGL functions and stages. This process handles control flow, typing, and construct reification in a unified representation (Niketan et al., 28 Aug 2025).

The backend phase performs the inverse operation. A target-language CodeGen traverses CrossGL and emits code appropriate to CUDA, HIP, Metal, HLSL, GLSL, SPIR-V, Rust, or Mojo. Generation is described as template-based and context-aware, with annotations directing language-specific syntax and layout choices. The paper uses examples such as CUDA launch configuration and Metal buffer setup to illustrate how backend adaptation can remain idiomatic while still being driven by one universal IR.

Extensibility is treated as a first-order design constraint. Because CrossGL is the only intermediate target each language must import to and export from, the framework’s complexity scales linearly in the number of languages rather than quadratically in the number of translation pairs. The paper characterizes this as the practical basis for universal translation and also reports that the extension model was tested conceptually for additional languages such as JavaScript and Go, which would require only parsing and code-generation modules (Niketan et al., 28 Aug 2025).

The paper further states that CrossGL is expressive enough to represent “all major GPU/graphics-specific concepts,” “systems-level facilities,” “all imperative constructs,” and advanced features including function recursion and pattern matching. In context, this semantic range is essential: without it, linear scaling in translators would be offset by unacceptable loss of source-level structure.

5. Expressive range and empirical validation

The CrossTL evaluation presents CrossGL as practically viable rather than purely conceptual. The paper reports a 100% success rate on test programs, including both basic and complex programs up to 499 lines, with successful compilation and execution across all 8 fully implemented backends: CUDA, HIP, Metal, HLSL, GLSL, SPIR-V, Rust, and Mojo (Niketan et al., 28 Aug 2025).

The examples used in evaluation span multiple programming domains. They include basic shaders such as UV mapping, matrix multiplication with tiled or shared-memory techniques, particle simulations involving atomic operations and workgroup synchronization, and full physically based rendering pipelines. The paper also presents a large “ComplexShader” example containing structs for materials and lights, vertex-stage logic, and fragment-stage logic including a Cook–Torrance BRDF and loops over lights. According to the description, this shader translates correctly across CUDA, Metal, HLSL, GLSL, Rust, Mojo, and other supported targets (Niketan et al., 28 Aug 2025).

These results are used to support several claims about code quality. Generated code is said to preserve complex control flow, data structures, and high-level semantics, while the backends maintain idiomatic target usage through attribute-based adaptation. The paper frames this as empirical validation that a single IR can span GPU compute, graphics programming, and systems-language workflows without collapsing everything to a lowest-common-denominator representation.

A common misunderstanding would be to treat CrossGL as only a shader IR. The reported benchmark set argues against that reduction: the framework explicitly targets both graphics and non-graphics compute patterns, and the supported languages include systems-oriented targets such as Rust and Mojo in addition to graphics APIs and shader ecosystems. The paper therefore positions CrossGL as a broader universal IR for heterogeneous programming domains, not merely as a graphics interchange format.

6. Terminological ambiguity and adjacent usages

The label “CrossGL” is not used uniformly across the provided literature. In one paper it is the formal name of an intermediate representation; in others it appears as shorthand for cross-platform or cross-view Gaussian Splatting contexts. This suggests a nomenclatural ambiguity rather than a single established term across subfields.

Usage	Meaning in context	Source
CrossGL	Unified, language-agnostic intermediate representation in CrossTL	(Niketan et al., 28 Aug 2025)
“CrossGL” integration	Cross-platform integration of real-time Gaussian Splatting viewers via GPU IPC, external clients, and hybrid rendering pipelines	(Xu et al., 21 Jan 2026)
“CrossGL” in explanatory material	Cross-view Gaussian Splatting context associated with multi-branch construction and fusion for large-scale reconstruction	(Zhang et al., 3 Jan 2025)
GLC	“General Line Coordinates” for interpretable, interactive, lossless 3D visualization of $n$-dimensional data	(Martinez et al., 2024)

In SplatBus, the term is used in connection with decoupling a Gaussian Splatting renderer from external viewers such as Unity, Blender, Unreal Engine, and OpenGL clients through Nvidia CUDA IPC. There, the emphasis is not on program translation but on client–server rendering, zero-copy GPU buffer sharing, cross-API interoperability, and hybrid composition of Gaussian splats with mesh pipelines (Xu et al., 21 Jan 2026).

In CrossView-GS, the explanatory material associates “CrossGL” with cross-view Gaussian Splatting for large-scale scene reconstruction. The substantive method there is built from dual-branch construction and fusion, gradient-aware regularization, and Gaussian supplementation, all aimed at improving aerial-ground reconstruction under large view disparity. That usage is methodologically unrelated to CrossTL’s IR, even though the shorthand overlaps lexically (Zhang et al., 3 Jan 2025).

A separate but nearby source of confusion is GLC, meaning “General Line Coordinates,” which designates a 3D visualization space for interpretable and lossless high-dimensional data visualization. GLC integrates Shifted Paired Coordinates, Shifted Tripled Coordinates, and GLC-L, and is distinct from both CrossTL’s CrossGL and Gaussian Splatting contexts (Martinez et al., 2024).

7. Significance within current research

Within the CrossTL paper, CrossGL is presented as the enabling abstraction for “write-once, deploy-everywhere” translation across multiple language families. Its significance derives from four stated contributions: a unified IR capturing semantics across multiple programming paradigms, a modular architecture enabling extensibility, comprehensive support for GPU compute, graphics programming, and systems languages, and empirical validation demonstrating practical viability (Niketan et al., 28 Aug 2025).

The broader significance is methodological. By centralizing translation around one semantic IR, CrossGL reframes cross-language interoperability as a problem of frontend normalization and backend lowering rather than pairwise compiler engineering. This suggests a research trajectory in which optimization, verification, and language design could be performed against a shared intermediate substrate rather than reimplemented separately for each language pair.

At the same time, adjacent uses of the same label in neural rendering and viewer-integration papers indicate that “CrossGL” is not yet a globally standardized term across arXiv domains. For precision, the most stable technical meaning in the provided literature is the one defined by CrossTL: CrossGL as a unified intermediate representation for universal programming-language translation (Niketan et al., 28 Aug 2025).