Garage @ Xplicit Computing

last update: 10 June 2026

This page is useful to current and future teammates, linking to relevant XCOMPUTE paths 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 Feb 2026.

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 Patent

Continuous 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 (~2 thread-hrs per build, requiring 500-1000 MB/thread).

Experimental package downloads can be found here.

IEE Taxonomy and Landscape

Human/Machine vs Interaction/Automation

  • 1. machine-automation = server host [311] (operational)
  • 2. human-interaction = client interface [322] (operational)
  • 3. machine-interaction = edge peripheral [321] (in R&D)
  • 4. human-automation = terminal utility [312] (in R&D)
    •

    0. Infrastructure

    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 Library

    0.1. Xplicit Web Services (XWS)

  • 0.1.1. xcadmin (arm64, 99.9997% uptime)
  • 0.1.2. xcweb (arm64, 99.9993% uptime)
  • 0.1.3. xcbuildbot (arm64, ~99% uptime)
  • 0.1.4. d1/d2/f1/f2/w1/w2 workers (amd86_64, WoL)

    • 1. Server Host R&D

    Product Page | Geometry Paper | Data Patent | Source Code

    1.1. Computational Geometry

  • 1.1.1. Implicit Shape Definition and Processing
  • 1.1.2. Dynamic Parallel Octree

    • 1.2 Conventional Physics Modeling

  • 1.2.1. Lattice-Boltzmann Method (LBM)
  • 1.2.2. Finite Volume Method (FVM)
  • 1.2.3. Contacts and Tribology (SDF)
  • 1.2.4. Adjoint Optimization (FEM)

    • 1.3. Advanced Physics Modeling

  • 1.3.1. Applied Buckingham Pi Theorem (via property-keys)
  • 1.3.2. Classical Electromagnetism
  • 1.3.3. Relativistic Electromagnetism
  • 1.3.4. Chemical and Nuclear Reactions

    • 1.4. ML/AI Implementations

    A few essential productivity adapters are implemented in 2026:

  • 1.4.1. Public Info LLM "ai::info" (d1)
  • 1.4.2. Dev-Ops LLM "ai::rick" (d2)
  • 1.4.3. Code Dev LLM "ai::proto" (f1)
  • 1.4.4. File Transformers "ai::filo" (f2)

    • 2. Client Interface R&D

    Product Page | Source Code

    2.1. Rendering and Interaction

  • 2.1.1. Explicit Rasterization
  • 2.1.2. Implicit Ray-Marching
  • 2.1.3. Stereoscopic 3D

    • 2.2. End-User Extensions

  • 2.2.1. Marketplace
  • 2.2.2. Agents and Games

    • Uptime measured over a 24-month period (Oct 2023 - Oct 2025).

    3. Edge Metaware R&D

    Source Code

    3.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.1.1. Delta High-Order Sampling and Reconstruction

  • 3.1.2. Gigabit Data and Command Funnel

    • 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.2.1. Synchronous Circular Buffer (cbuffer.c)
  • 3.2.2. Asynchronous Command Pipe

    • 3.3. Sensor & Effector Fusion

  • 3.3.1. Abstractions for SPI and I2C devices

    • 4. Terminal Utility R&D

    Source Code