u/Common_Sorbet3873

Built and open-sourced qingming-qwen3-tts, a device-native Qwen3-TTS inference backend for AMD RX 7900 XTX 24GB and NVIDIA RTX 4090 24GB.

For ROCm, the RX 7900 XTX backend uses native HIP kernels with BF16 storage and FP32 accumulation.

No PyTorch. No ONNX Runtime. No TensorRT. No CuBLAS. No rocBLAS.

Supports Qwen3-TTS 0.6B / 1.7B, streaming, Once and Resident execution.

The benchmark image uses a first audio packet of 8 codec frames = 640 ms of playable audio, so TTFA should not be directly compared with systems using 2-frame or 4-frame first packets.

GitHub: https://github.com/uulong950/qingming-qwen3-tts

Hi,

I have open-sourced qingming-z-image-turbo, a native HIP/C++ implementation of Z-Image-Turbo optimized specifically for the AMD Radeon RX 7900 XTX 24GB / gfx1100.

GitHub:

https://github.com/uulong950/qingming-z-image-turbo

This is a device-level implementation rather than a wrapper around an existing inference framework. The current execution path includes:

• Custom gfx1100 BF16 WMMA kernels
• Persistent GEMM scheduling
• Fused QKV, attention and FFN operations
• Fully GPU-resident inference graph
• One GPU graph launch with no intermediate CPU transfers
• BF16, Q8_0, Q6_K and Q5_K_M execution paths
• 512×512, 576×1024 and 1024×1024 output resolutions
• One-shot and resident interactive modes
• No PyTorch, Diffusers, ComfyUI or Python runtime dependency

Test environment:

• Ubuntu 24.04
• ROCm 7.2.4
• AMD Radeon RX 7900 XTX 24GB
• 8 inference steps
• Prompt: “A cinematic portrait in the rain”
• Seed: 42

Selected full-graph results:

Model	512×512	576×1024	1024×1024
BF16	10.23 s	17.72 s	31.49 s
Q8_0	7.41 s	14.91 s	28.32 s
Q6_K	5.60 s	11.91 s	23.27 s
Q5_K_M	5.68 s	11.91 s	23.46 s

The repository includes source code, build instructions, model download scripts, benchmark data and output comparisons. Model weights are not included.

This is an unofficial community implementation and is not affiliated with Tongyi-MAI, Alibaba or AMD.

I built and released an open-source Goldilocks/G64 STARK proving backend targeting AMD ROCm/HIP.

Repository:

https://github.com/uulong950/qingming-stark-g64

I wanted to share it here because it is a real ROCm/HIP workload.

The artifact exposes a complete proving pipeline:

CLI prover → QSPG64 .qsp proof file → standalone verifier

The prover writes an explicit .qsp proof file. The standalone verifier reads the proof file and checks public input binding, statement digest, trace openings, quotient FRI, local AIR checks, and quotient relation checks.

Verified target:

AMD RX 7900 XTX 24GB
ROCm/HIP
Goldilocks/G64 field
QSPG64 proof format

The build surface is intentionally small:

make -C rx7900xtx-24g

The scale/latency boundary from the verified matrix:

SCALE24:
2^24 rows
1,048,576 trace rows
~342 ms proof generation
standalone verifier PASS

SCALE26:
2^26 rows
4,194,304 trace rows
~1.04 s proof generation
standalone verifier PASS

SCALE27:
2^27 rows
8,388,608 trace rows
~2.04 s proof generation
fast_prelayout_xyz path
standalone verifier PASS

What I find interesting from the ROCm side is that this is a complete GPU-resident cryptographic proving workload on a consumer AMD GPU:

field arithmetic
NTT / layout-sensitive kernels
Merkle commitments
FRI proof material
retained GPU-side data structures
proof serialization
standalone verification boundary

To me, this is a useful ROCm/HIP reference workload because it is:

open source
source-visible
small build surface
consumer AMD GPU target
end-to-end cryptographic pipeline
standalone-verifiable output

I would be interested in feedback from ROCm users on portability, build assumptions, kernel structure, and what would make this easier to reproduce across more AMD GPUs.

I built and released an open-source Goldilocks/G64 STARK backend on AMD ROCm/HIP:

https://github.com/uulong950/qingming-stark-g64

The artifact exposes a complete proving boundary:

CLI prover → QSPG64 .qsp proof file → standalone verifier

The prover writes a real .qsp proof file. The standalone verifier reads that file and checks public input binding, statement digest, trace openings, quotient FRI, local AIR checks, and quotient relation checks.

The scale/latency boundary is the main point:

SCALE24: 2^24 rows, ~342 ms, verifier PASS
SCALE26: 2^26 rows, ~1.04 s, verifier PASS
SCALE27: 2^27 rows, ~2.04 s, fast_prelayout_xyz, verifier PASS

So this is not only a primitive benchmark. It is an open-source STARK backend producing standalone-verifiable proof files at million-row, sub-second scale on a consumer AMD GPU.

The build surface is small:

make -C rx7900xtx-24g

I am interested in what this latency/scale boundary makes possible:

local proving
proof-carrying APIs
low-cost prover markets
near-real-time verifiable computation
privacy-preserving business logic
hardware-neutral proving infrastructure

My current framing is:

SCALE24 = practical real-time region
SCALE27 = upper benchmark path

I would appreciate feedback on the artifact boundary and on what kinds of cryptographic systems could use open-source STARK proving at this scale.

I am the author of Qingming G64 NTT, an open-source HIP/ROCm implementation of a native Goldilocks-field NTT for a STARK-style LDE workload.

Repo: https://github.com/uulong950/qingming-g64-ntt

I am not posting this as a promotional comparison. I am looking for feedback on benchmark methodology, reproducibility, and fair baselines.

The workload is deliberately native rather than a proxy benchmark:

• Field: Goldilocks / G64
• Modulus: p = 2^64 - 2^32 + 1
• Logical data size: 2^24
• LDE expansion: exact 8x
• Transform domain: 2^27
• Backend: AMD HIP / ROCm
• Validation GPU: RX 7900 XTX
• ROCm/HIP: ROCm 7.2.4 / HIP 7.2.53211

On the validated 2^27 target, the fast interface reports:

• Median latency: 19.1927 ms
• P95 latency: 19.4936 ms
• Throughput: 52.10 size-2^27 NTT/s
• Element rate: 6.99 billion elements/s
• Butterfly rate: 94.41 billion butterflies/s

The standard compatibility interface is around 21.99 ms median, and tiled prelayout-only is measured separately at around 3.14 ms median.

The motivation is to measure the native STARK proving boundary directly: no proxy field, no reduced modulus, no scaled-down domain, and no hidden layout cost.

I would appreciate feedback on:

1. Whether 2^24 logical data with exact 8x LDE into a 2^27 Goldilocks domain is the right boundary to study for STARK proving cost.
2. What would be a fair comparison protocol against GPU-NTT, ICICLE, sppark, or Plonky3-style internals.
3. Whether device-resident forward NTT should be the main table, with host-to-host and layout/prelayout costs reported separately.
4. What AMD/NVIDIA profiler counters would make the result more useful.

I especially want to avoid comparing incompatible “64-bit NTT” results when the field, modulus, layout contract, batch size, and timing scope are not the same.

Criticism of the benchmark methodology is very welcome.