MiniDXNN v0.4.0: Interactive neural texture compression on DirectX 12

We’ve released a new v0.4.0 update to MiniDXNN, our open-source library for GPU-accelerated MLP (Multi-Layer Perceptron) inference and training on DirectX® 12. Starting with the v0.2.0 release, the library has moved from using Cooperative Vectors to the new D3D12 Linear Algebra feature of the Microsoft® Shader Model 6.10 preview (available with the AgilitySDK 1.721-preview), added input encoding for neural texture compression, and now ships a real-time GUI application that trains a texture representation live on screen.

What’s changed since v0.2.0

Shader Model 6.10/D3D12 LinAlg Matrix (v0.3.0):

  • v0.2.0 used Cooperative Vectors (SM 6.9) for hardware-accelerated matrix-vector operations. The library now targets D3D12 LinAlg Matrix (SM 6.10), which adds more expressive matrix layout control, a cleaner HLSL API, and driver-side layout optimization via GPU-side matrix conversion. All examples, unit tests, and the C++ CPU fallback path were updated to match.

Input encoding and neural texture compression (v0.3.0):

  • A new example (03_texture_compression_with_input_encoding) trains an MLP to represent a 2D texture, with positional and grid input encoding to recover high-frequency detail.

Examples from 03-texture-compression-with-input-encoding. Stock image from Pexels.

Interactive GUI application (v0.4.0):

  • 04_texture_compression_app is a windowed app that incrementally trains each frame, displays the reconstruction live, and exposes training parameters through ImGui.

Toolchain:

Read more: MiniDXNN v0.4.0: Interactive neural texture compression on DirectX 12 - AMD GPUOpen

Re: MiniDXNN v0.4.0 — Interactive neural texture compression on DirectX 12

Strong release. The part worth dwelling on isn’t the GUI — it’s the move from Cooperative Vectors (SM 6.9) to D3D12 Linear Algebra (SM 6.10). When matrix layout control shifts driver-side via GPU-side matrix conversion, the memory-access pattern that hits the L2 and the memory controller is no longer pinned by the application. It’s renegotiated at the driver boundary. That changes the thermal transient profile of the silicon under sustained MLP training in ways the v0.2.0 cooperative-vector path never exposed. We’ve been tracking this exact envelope shift in controlled simulation against our own reactive baselines — and the per-frame incremental training workload in 04_texture_compression_app is the cleanest stress profile we’ve seen yet. The GPU never settles, so the cooling loop never stops chasing.

The input-encoding path matters here too. Positional and grid encoding for high-frequency texture recovery is the same mathematical machinery that drives the compute-density spikes we see in neural-representation workloads in production AI data centers. When you push it real-time, per-frame, with ImGui exposing hyperparameters live, you’ve effectively handed an operator a knob to wander the thermal envelope at will. Beautiful demo. Also the most reliable way we’ve found to provoke a throttle event inside a controlled observation window.

Two questions we’d want answered before this lands in any production qualification path on RX 9000:

  1. What does the dependable-capacity envelope look like under a 30-minute sustained 04_app session versus the published nameplate TGP? The transient behavior under per-frame training is not what the spec sheet describes. Nameplate capacity and dependable capacity diverge the moment the workload stops being batch-inference and starts being live-training.
  2. How does the SM 6.10 driver-side layout optimization behave when multiple MLP instances share the same command queue? The optimization that helps one workload can quietly consume headroom from another. That’s the kind of constraint migration that doesn’t show up in a single-workload benchmark and shows up immediately in a multi-tenant rack.

Neither is a critique of the release. Both are the kind of question that gets answered with evidence, not benchmarks.

For our part: Valor is in validation stage on exactly this class of workload envelope — patent-pending Physical-State Intelligence™ architecture that predicts the constraint forming, verifies it against independent evidence, and keeps every response within qualified operator authority. Controlled simulation against a reactive baseline showed throttle exposure dropping from 34.65% down to 1.19%, with a 55–239-second detection lead before the conventional alarm path fires. Simulation, not field data — third-party validation remains required. But the signal is real, and the silicon is yours.

If the GPUOpen team has telemetry from the v0.4.0 training app on RX 9000 under sustained load — thermal, power, fan response, clock behavior, the things the conventional alarm path misses — we’d be interested in comparing it against our controlled-simulation baselines. There’s dependable capacity sitting inside this hardware that nobody has surfaced yet. That’s the gap we work in.

— Valor Infrastructure Holdings
Physical-State Intelligence™ · patent-pending