From Graphics to GPU Compute: A Major Step Forward for the Axmol RHI (blog)

[halx99]

Axmol's Render Hardware Interface is evolving from a graphics-oriented abstraction into a broader foundation for modern GPU workloads.

This update introduces first-class cross-backend compute support to the Axmol RHI, together with the resource and shader infrastructure needed to make compute useful in real engine features.

The update includes:

• Compute programs, pipelines, and dispatch
• Storage buffers
• 3D textures
• Compute shader reflection
• Runtime sampler overrides
• Compute- and storage-related device capabilities and limits
• Compute-capable OpenGL / OpenGL ES context selection
• Per-shader target profiles in the shader toolchain
• Full Effekseer GPU particle integration

Compatibility note: GPU compute is an optional RHI capability and does not raise Axmol's minimum requirements for normal rendering. Compute requires OpenGL 4.3+, OpenGL ES 3.1+, or an equivalent compute-capable backend. Older GL 3.3 / GLES 3.0 devices can continue using the existing graphics path. WebGL is not supported by the current compute path.

The implementation has been tested successfully across the supported RHI backends.

This is more than adding a single compute API. It gives Axmol a portable way to express both graphics and general-purpose GPU workloads through the same RHI architecture.

---

Why Compute Support Matters

Traditional rendering pipelines are centered around vertex shaders, fragment shaders, render passes, and draw calls.

Many modern real-time workloads do not naturally fit into that model:

• GPU particles
• Particle simulation
• GPU animation
• Large-scale instance-data processing
• GPU culling
• Procedural generation
• Data preprocessing
• Other parallel simulation workloads

These tasks are often better expressed through compute shaders.

Without a portable compute abstraction, engine-level features tend to fall back to native platform APIs as soon as they need GPU compute. That quickly breaks the purpose of having an RHI in the first place.

The goal of this work is therefore not to add a special path for one effect. Compute is now a first-class RHI capability.

---

GraphicsPipeline and ComputePipeline

As part of the architectural cleanup, the previous:

RenderPipeline

has been renamed to:

GraphicsPipeline

and a new:

ComputePipeline

has been introduced.

The distinction is now explicit:

GraphicsPipeline
    └── graphics rendering

ComputePipeline
    └── compute dispatch

The graphics device can create compute programs and pipelines:

auto program = device->createComputeProgram(shaderData);
auto pipeline = device->createComputePipeline(program);

Compute work is submitted through GraphicsContext::dispatch():

rhi::ComputeDispatchDesc desc;
desc.pipeline = pipeline;
desc.programState = programState;
desc.groupCountX = x;
desc.groupCountY = y;
desc.groupCountZ = z;

context->dispatch(desc);

The first version submits compute work on the graphics queue, with backend-specific synchronization handled by the RHI implementation.

---

Storage Buffers: Connecting Compute and Graphics

Useful compute workloads need more than dispatch.

They need GPU-visible data that can be read, written, and consumed by later stages of the frame.

The RHI now supports storage buffers through BufferDesc:

rhi::BufferDesc desc;
desc.size = bufferSize;
desc.stride = elementStride;
desc.type = rhi::BufferType::STORAGE;
desc.usage = rhi::BufferUsage::DYNAMIC;
desc.access = rhi::BufferAccess::READ_WRITE;

auto buffer = device->createBuffer(desc);

The portable HLSL forms currently supported are:

StructuredBuffer<T>
RWStructuredBuffer<T>

Shader reflection records the information required by each backend, including:

• logical and backend binding
• descriptor space
• element stride
• size
• read-only / read-write access
• shader-stage usage

Storage buffers are not limited to compute shaders. Graphics stages can consume them as well.

That enables workflows such as:

Compute Shader
    ↓ write
Storage Buffer
    ↓ read
Vertex Shader
    ↓
Graphics Pipeline

Axmol's new compute dispatch test uses exactly this pattern.

---

3D Textures

Compute-heavy features such as particle simulation often depend on volumetric data, vector fields, or 3D noise textures.

The RHI now includes:

TextureType::TEXTURE_3D

and:

TextureDesc::depth

together with 3D update APIs:

updateData3D(...)
updateSubData3D(...)

Each backend maps this to its native resource representation. Vulkan, for example, uses 3D images and 3D image views for this texture type.

---

Compute Shader Reflection

Axmol remains HLSL-first.

Compute shaders are integrated into the existing shader archive and runtime reflection system rather than introducing a second, separate resource model.

A typical compute entry point looks like:

[numthreads(256, 1, 1)]
void main(uint3 id : SV_DispatchThreadID)
{
    // ...
}

axslcc stores the local workgroup size in shader reflection, and the runtime exposes it through the program.

Uniform buffers, sampled textures, samplers, and storage buffers continue to use the same Program / ProgramState model already used by graphics shaders.

This is important: graphics and compute are different pipeline types, but they share one resource-binding architecture.

---

Runtime Sampler Overrides

The update also adds per-ProgramState sampler overrides for custom samplers.

For example:

auto location = program->getSamplerLocation("mySampler");
programState->setSampler(location, desc);

This is useful when filter or wrap state needs to change dynamically without mutating a shared texture object.

Built-in sampler presets remain immutable.

---

OpenGL and OpenGL ES Without Raising Every Shader Profile

OpenGL and OpenGL ES require special care because compute support raises the minimum shader profile:

OpenGL compute   → GLSL 430
OpenGL ES compute → ESSL 310

That does not mean every ordinary graphics shader should be compiled for those profiles.

The shader build system now supports per-shader target overrides.

A compute shader can request:

set_source_files_properties(
    particles_cs.hlsl
    PROPERTIES AXSLCC_TARGETS "gl-430;gles-310;d3d11;d3d12;vk;mtl"
)

while ordinary graphics shaders can remain:

GLSL 330
ESSL 300

At runtime, Axmol selects the highest archived profile that is not newer than the active device profile.

As a result, an OpenGL 4.3 context can load both:

• GLSL 430 compute shaders
• GLSL 330 graphics shaders

while an OpenGL 3.3 context can continue loading normal graphics shaders but cannot activate the compute workload.

This avoids raising the minimum graphics requirements just because a subset of shaders needs compute.

---

Compute-Capable GL / GLES Context Selection

The context creation path has also been updated.

On Windows and Linux desktop OpenGL, Axmol prefers:

OpenGL 4.3

and falls back to:

OpenGL 3.3

when the newer context is unavailable and fallback is allowed.

On Windows GLES, Axmol prefers:

OpenGL ES 3.1

and can fall back to:

OpenGL ES 3.0

Android GLES follows the same general strategy: prefer a GLES 3.1 context, then fall back to GLES 3.0.

The important behavior is:

A device that can run compute gets the new feature, while older hardware can continue using the existing graphics path.

---

Cross-Backend Implementation

The compute infrastructure is implemented across:

• Direct3D 11
• Direct3D 12
• Metal
• Vulkan
• OpenGL
• OpenGL ES

Each backend maps the RHI abstraction to its native compute and resource model.

Engine-level code does not need to directly deal with platform-specific concepts such as:

ID3D11ComputeShader
D3D12 compute PSOs
MTLComputePipelineState
VkPipeline
OpenGL compute programs

Those details stay inside the RHI.

That is one of the most important outcomes of this work: compute no longer needs to be a platform-specific engine feature.

---

The First Real Consumer: Effekseer GPU Particles

The first large-scale consumer of the new compute path is Effekseer GPU particles.

Previously, the Axmol Effekseer backend did not provide a GPU particle system or GPU particle factory.

The new implementation enables them when the current device provides the required capabilities.

Before creating the GPU particle system, Axmol checks for:

• Compute shader support
• Storage buffers
• 3D textures
• Sufficient workgroup size
• Sufficient workgroup invocation count
• Enough storage-buffer bindings
• Adequate storage-buffer size limits
• Adequate 3D texture limits

If the requirements are not met, GPU particles are simply unavailable while the existing renderer continues to work.

In other words:

unsupported compute feature
        ↓
GPU particles disabled
        ↓
normal rendering continues

Compute is treated as a capability, not as a new hard requirement for the entire engine.

---

Effekseer Shader Migration

Effekseer's GPU particle compute shaders are now integrated into Axmol's HLSL-first shader toolchain.

Compute-related shaders are built for compute-capable profiles:

gl-430
gles-310
d3d11
d3d12
vk
mtl

while continuing to use Axmol's existing:

• shader compilation
• archive format
• reflection
• Program
• ProgramState
• samplers
• buffers
• textures

The Effekseer integration therefore does not bypass the RHI.

Instead, it acts as a real-world validation that the new compute abstraction is general enough for a substantial engine feature.

---

Validation: Compute Write, Graphics Read

In addition to Effekseer GPU particles, the update adds a dedicated compute dispatch test.

The test performs:

Compute Shader
    ↓
write float4 values
    ↓
Storage Buffer
    ↓
Vertex Shader reads the same buffer
    ↓
render a fullscreen quad

This validates much more than shader compilation.

The path covers:

• Compute program creation
• Compute pipeline creation
• Storage-buffer creation
• Compute dispatch
• Read/write storage-buffer binding
• Compute-to-graphics synchronization
• Storage-buffer access from the vertex stage
• A final graphics draw

The supported RHI backends have been tested successfully with the new implementation.

---

Scope of the First Compute API

The first compute API intentionally focuses on a portable and practical baseline.

It currently supports:

• Fixed local workgroup sizes
• Uniform buffers
• Sampled 2D and 3D textures
• Custom samplers
• StructuredBuffer
• RWStructuredBuffer
• Direct dispatch

It does not currently expose:

• Storage images
• Indirect dispatch
• Asynchronous compute queues

These can be added later when real engine workloads require them without changing the overall graphics/compute pipeline architecture introduced here.

---

What This Enables Next

Effekseer GPU particles are the first use case, not the last one.

With compute now available through the RHI, Axmol can gradually explore workloads such as:

• GPU-driven particle simulation
• GPU culling
• Procedural data generation
• GPU animation preprocessing
• Instance-data generation
• Compute-based post processing
• Other simulation workloads

The key difference is that these features can now be designed once at the RHI level instead of independently for Vulkan, Metal, Direct3D, and OpenGL.

---

From Render Hardware Interface to a Broader GPU Abstraction

The original role of the Axmol RHI was primarily to unify rendering across graphics APIs.

With compute support, that architecture is expanding:

Before

RHI
 └── Graphics

Now

RHI
 ├── GraphicsPipeline
 └── ComputePipeline

This does not change Axmol's lightweight and portable direction.

The goal is the opposite:

Bring modern GPU capabilities into one portable architecture without sacrificing simplicity.

Effekseer GPU particles are the first major feature built on top of the new compute path.

More can now follow.

---

Axmol
https://axmol.dev/