Garage @ Xplicit Computing
last update: 20 Jan 2026
This page is useful to current and future teammates, as a sort of centralized linking page to relevant XCOMPUTE info and infra. Some of this is fully-operational, while other aspects are listed as R&D areas. The purpose of this page is to generally education the state and trajectory of XCOMPUTE so that we may attract teammates aligned with our vision.Background
Prototype FDM LES simulations from Space Energetics LLC kicked off R&D in 2011-2014. This family of 2D Matlab CFD and E&M codes are considered the "X1" prototype. "X2" then applied the C++11 spec and evolved through requirement capture and engineering process. In 2020, C++20 was standardized and the foundations of XC and XCOMPUTE technologies were defined. It took three small teams a decade to reach the premiere public release in late Dec 2025.
Introduction
XCOMPUTE is an Integrated Engineering Environment (IEE) -- covering a broad scope with a carefully-designed stack, so research is organized and pursued based on a technology taxonomy. This page outlines some of our forward-looking research with a few useful links for public and internal use.
User Docs | Internal Ops Docs | Platform Paper | Platform PatentContinuous Integration
XC uses Git for revision control and our internal Buildbot to periodically compile software package candidates that are then tested for release. Available to XC teammates, we heavily rely on a centralized (v3) implementation, but are soon deploying a distributed (v4) upgrade to enable automatic compilation across a broader range of operating systems. Architecture targets include: x86-64 and ARM64 with OpenCL/OpenGL.
To build and execute reliable and complex software technology with minimum dependencies (with the latest architecture optimizations such as AVX512), metaprogramming and conventional techniques (OOP hierarchy, modularity, regularity) generate efficient runtime binaries, but in doing so, consume non-trivial resources for compilation (~4 thread-hrs per build at 500-1000 MB/thread).
Experimental package downloads can be found here.
IEE Taxonomy and Landscape
Human/Machine vs Interaction/Automation
0. Underlying Modules
XC apps [300] are based on the XC common module and the XC messages submodule. This middleware provides the remote procedure protocol [200], cryptography, and machinery for object serialization and deserialization [105]. XC libraries and executables are designed to be performant, cross-platform, and bind to most all programming languages via Google's Protocol Buffer compiler.
API Page | Messages Library | Common Library1. Server Host R&D
Product Page | Geometry Paper | Data Patent | Source Code1.1. Computational Geometry
Newer approaches represent shapes and surfaces implicitly, where field functions and operators permit more efficient, organic, and automatable processes conducive to multiphysics and optimization.
Using implicit shapes and operators, there are virtually no limits to geometric complexity or resolution.. Shapes are implicitly defined by a net field equation (or sampling) that generally has the property of an increasing monotonic slope normal to (away from) the implicit surface. The implicit boundary (surface if 3D) is defined as the interface where the value of the field function is zero (by default).
The family of ideal implicit shape fields are Signed Distance Functions/Field); SDF are usually only possible with primitive SDF shapes and a small subset of operations; many implicit operators introduce systemic error -- and while non-ideal gradients can be corrected to first-order accuracy, for engineering purposes, non-SDF implicit fields come with caveats that must be carefully handled. One issue that engineers face: the actual/manufacturing accuracy of shapes, most notably: the large errors in the interior field after union operations are performed.
If you're only raytracing solids, this is not a problem (as only the exterior field is evaluated), but if you're trying to make a computable volumetric mesh, solve solid-body FEM, or do photonic engineering of lenses -- then the interior field needs to be accurate -- essentially an SDF. This is the current gap between implicit representation for entertainment vs science/engineering.
These trinket real-time renders are outputs of technology tests; they are not inteded for beauty -- but rather, to demonstrate underlying mathematics for engineering representations. These tests are intended to run on budget computers with low-mid grade dedicated GPU through more powerful modern GPU. They are part of the xcompute-client integration_test.
Left: quasi-3D visualization of an implicit field resulting from the dynamic combination of two SDF shapes. In this test, the viewing plane is also dynamically adjusted to produce "slices" where red bands indicate interior and green indicates exterior. As the cube and sphere cross, the union operator produces a perfect exterior field. However, the interior field is progressively more incorrect the further from the boundary. The remedies used in the visual effects industry are not suited, so this requires inventive solutions.
Center: a more typical 3D view of dynamic mixing of two simple shapes: mix(octahedron,torus,t)
Right: getting more complex: introducing a rudamentary complex shape pipeline that runs within a GLSL shader. A basket is made from the smooth union of a torus (handle) and the bottom section. The bottom section is made from the difference between a cut hollow sphere and a gyroid. Once implemented, the shapes and operators were trivially-easy to customize. However, the dimensional parameters were hardcoded, highlighting the difficulty of an arbitary-complexity implicit shape pipeline (that could perfom the necessary tree traversals/assignments) without using recursion and restrictive OpenGL buffer mechanisms. Many of these challenges are due to an attempt to keep the OpenGL requirement modest (e.g. v4.1) so that it can run on almost all modern consumer computers (as our existing explicit rasterizer does).
1.2 Conventional Physics
1.3. Advanced Physics
1.4. ML/AI
As our focus is on tuning and applying LLM, PINN, and other methods to directly benefit our company and users, we generally adapt existing frameworks and base models, aligning these tools with our use cases via carefully-curated fine-tuning inputs on modest (33 TFLOP) local hardware. Inference is then performed on smaller power-efficient service machines:
2. Client Interface R&D
Product Page | Source Code2.1. Rendering and Interaction
2.2. End-User Extensions
2.3. Web Services
note: uptime stats are measured minimums over a 24-month period, as of 11 Oct 2025
3. Edge Metaware R&D
Source Code3.1. Microprocessor (MPU) Peripheral
A Linux-based soft-RTOS for multi-core microprocessors (such as quad-core ARM Cortex-A72) consists of an edge application built atop the common module, communicating with a server host via sockets (as the client does), and one or more MCU via USB/UART. Effectively mapping systems on a server host to peripheral hardware, it performs mid-level signaling operations as well as embedded level I/O such as SPI. The MPU acts as a 1 Gb/s funnel between MCU and server host CPU, interpreting commands from the server and pre-processing data from the MCU. Because of this, the MPU requires 2GB+ RAM and a 1GHz+ 64-bit processor.
3.2. Microcontroller (MCU) RTOS
A bare-metal OS for dual-core microcontrollers (such as the ARMv0 RP2040) consists of an instrumentation & control loop, and a separate thread communicating high-level commands/data to/from the parent MPU via USB/UART. It performs timing-critical low-level operations such as digital device interfaces via SPI and medium-speed protocols. Due to the breadth of required functionality in industrial and flight controllers, the design philosophy assumes relatively large 200kB+ RAM and a 100MHz+ 32-bit processor. Several such MCU form a 1 Gb/s funnel with the connected MPU (which performs pre-processing, feedback, and integrates with the server host.)
3.3. Sensor & Effector Fusion
