Frequently asked questions.

Chameleon is a real-time GPU reengineering service powered by the Essence® platform. It generates hardware-tuned machine instructions at runtime — as Composite Job Designs — that execute directly on the target hardware via the SPIR-V path. No CUDA, ROCm, OneAPI, or PyTorch dependency. No code changes required in your application.

A compiler optimizes once, offline, and freezes decisions before execution starts. A profiler tells you where time is spent but doesn't change what runs. An AI code assistant proposes source code that still has to be compiled and inherits the same static execution limits.

Chameleon is a real-time execution optimization system. It restructures execution itself — instruction-level realization, kernel boundaries, scheduling, memory access — and adapts continuously based on observed hardware behavior.

No. Chameleon produces execution-ready optimized outputs that integrate into your existing pipeline. Integration is usually a drop-in kernel or compute module replacement, or workload harness optimization — not a rewrite of your application.

These gains were independently validated across AWS, Oracle Cloud, and Rowan University pilots using standard GPU telemetry (NVIDIA SMI) alongside chip-time measurements reported by the Chameleon runtime. Results were collected on live GPU instances — Nvidia Tesla T4, A10G, A100-SXM4-40GB, and A10 — with zero changes to customer workloads.

Peak observed speedups across our pilot workloads range from roughly 10× on lighter jobs to 140× on Fire_Spinner running at Rowan University. Most workloads cluster in the 30–50× range on hyperscaler hardware. Your workload's result depends on baseline quality and characteristics — we don't promise the same multiplier for every workload.

The gains come from eliminating wasted execution and memory pressure — not from increasing raw compute. When a GPU runs at 40% utilization because four abstraction layers sit between its silicon and the actual instruction, 60% of the power drawn produces heat, not results. Chameleon replaces that abstraction stack with direct instruction generation, so the hardware spends power on work instead of overhead.

Maybe — results depend on your workload's baseline quality and structure. The most scopable workloads have a stable execution boundary, well-defined outputs, and clear validation criteria. Ask us to scope your specific workload and we'll give you an honest answer before you commit to a pilot.

The current pilot runs a set of built-in workloads and measures performance and power on a single GPU at a time. No workload integration is required for Phase 1. You get a repeatable baseline vs. optimized comparison for the tested GPU, plus logs and results for review.

Phase 1 validates a single GPU per run. On multi-GPU systems or modules — for example, an 8-GPU NVIDIA A100 or H100 platform — each pilot run targets one selected GPU rather than optimizing all GPUs concurrently. Multi-GPU optimization is planned for Q3 2026.

No. Pilot binaries and workflows are for evaluation only. Once pilot results are validated, teams typically evaluate next steps for broader rollout, integration, or service-based deployment — including Chameleon as a managed service.

NVIDIA and AMD are validated today via the Vulkan (SPIR-V) execution path. Cross-Linux interoperability has been verified across NVIDIA, AMD, and Intel GPUs. For the pilot specifically, a modern NVIDIA GPU is the smoothest known-good path because it minimizes driver and environment variability.

Chameleon is designed for compatibility with 50+ Linux distributions and has been validated on 30+. Ubuntu 24.04 is the pilot-certified known-good path. Other validated distros include Debian, Fedora, Arch, and SUSE. Windows, macOS, Android, and iOS are on the roadmap.

Edge and mission environments — ISS / space edge, satellite / austere edge, 5G / MEC, rugged / tactical — are on the roadmap. For the current pilot, focus is on cloud and data center hardware. If you have a specific edge deployment in mind, contact us and we'll discuss feasibility.

Yes. A working Vulkan runtime is required for pilot execution because the pilot uses the SPIR-V execution path. For NVIDIA, the standard driver stack includes Vulkan support. For AMD, RADV or AMDGPU (where applicable) provides the Vulkan runtime.

Usually no. You can provide the workload or representative artifacts, and we return optimized outputs for your target environments. Validation can be performed on your side (or by a partner lab) using your own telemetry and benchmark harness. Direct access is only requested when a cloud provider uses proprietary variants or restricted toolchains that require a representative environment to ensure output correctness.

Drop-in kernel or module replacement, shader/compute module integration (for graphics and visual workloads), or workload harness optimization for repeatable benchmark scenarios. The best candidates have low dependency surface area and clear validation boundaries. Workloads with heavy framework entanglement or unclear output validation usually start by isolating a representative unit first.

SPIR-V is the primary portable target. PTX (NVIDIA), GCN (AMD), DXIL (DirectX), and MSL (Apple/Metal) paths are also supported depending on the integration pattern and vendor toolchain. Output target availability depends on the vendor toolchain, driver constraints, and your chosen integration pattern.

Pick one of the three pilot paths: cloud (AWS or OCI, fastest for hands-on), on-prem (for secure networks and labs), or hosted (no cloud account required, guided demo). Share your GPU model, driver version, and OS — we'll confirm the best pilot path.

Chameleon is environment-agnostic and we're adding more platforms continuously. Tell us what you need and we'll give you a feasibility assessment. Same intent, same Meaning Coordinates, different hardware.