How Jingang GC3 Uses RISC-V and Dataflow Computing for Video AI

Jingang GC3, also known as King Kong GC3, is reported as a specialized video-AI and generative-AI processor from SmarCo HT Tech. Rather than treating video decoding, AI inference, and video generation as separate jobs handled by separate devices, the chip is designed to bring those paths together under one dataflow-oriented architecture. Reported specifications include 12 RISC-V cores, 200 TOPS of INT8 compute, and 128GB of unified LPDDR5 ECC memory. 35

The important point is not simply the headline TOPS figure. GC3’s pitch is that video workloads often spend substantial time and energy moving frames, model data, and intermediate results between processors and memory. Its dataflow engine, shared memory, and integrated video and AI paths are intended to reduce that movement.

Why video AI creates a data-movement problem

A conventional video-understanding pipeline may decode a stream into frames, transfer those frames to a GPU, run vision inference, and then move results through additional processing stages. As the number of simultaneous streams rises, transferring and synchronizing data can become a bottleneck alongside the actual computation. 3

Video generation creates a related challenge. Diffusion and Transformer-based systems work with large model parameters and intermediate results. The reporting around GC3 says those intermediate data sets can reach hundreds of gigabytes, making repeated reads, writes, and transfers expensive in bandwidth, power, and time. 3

This is the problem GC3 is designed to target: not just a shortage of arithmetic units, but the cost of coordinating many stages of a large, highly parallel workload.

What the GC3 architecture combines

Dataflow computing

In a conventional control-flow design, a central processor or scheduler fetches and issues instructions, while data moves through a memory hierarchy. That approach is flexible, but the GC3 reports describe it as a poor fit for some regular, massively parallel video operations. 3

A dataflow design instead allows computation to proceed when the data required by an operation is available. In principle, this can expose more parallelism and reduce waiting caused by centralized scheduling and global coordination. For video workloads, the intended benefit is to keep more processing stages active without repeatedly funneling work through a single control path. 3

This is an architectural objective, not proof of a specific speedup. The available sources do not provide independent end-to-end comparisons with named CPUs, GPUs, or video-AI platforms.

RISC-V control cores

The 12 RISC-V cores serve as the programmable control layer in the reported design. Specialized processing paths handle video and AI operations, while the RISC-V cores provide general-purpose control and scheduling rather than making a conventional CPU responsible for every stage. 35

In this arrangement, RISC-V is not being presented as the entire compute engine. It works alongside the dataflow engine and dedicated video and AI functions, giving the platform programmable control while reserving high-throughput operations for specialized hardware.

Unified 128GB memory

GC3 is reported to use 128GB of unified LPDDR5 ECC memory shared across its CPU, VPU, GPU, and NPU paths. 35 The intended advantage is to reduce the need to copy data between separate CPU and GPU memory pools.

A shared pool could allow decoded frames, model weights, and intermediate tensors to remain available to multiple processing blocks without the same degree of device-to-device transfer. ECC adds error-protection capabilities to the memory subsystem; research on RISC-V processors has also examined ECC-protected memory as a way to improve fault tolerance. 1

Unified memory does not eliminate all bandwidth limits. It changes how the different compute blocks access data, while the practical benefit will depend on the chip’s memory bandwidth, software stack, scheduling, and workload.

Integrated video and AI paths

The reported design combines video encode and decode with AI compute on the same platform. That creates a more direct path from video ingest to understanding, and from generated content to encoding. 35

The proposed workflow is therefore:

• decode video on the platform;
• keep frames available to the relevant AI path;
• run understanding or generation without repeatedly crossing separate device boundaries; and
• encode the output on the same integrated system.

This does not mean every operation runs in one indivisible step. It means the architecture is intended to reduce unnecessary handoffs between otherwise separate processors and memory systems.

How GC3 aims to reduce cost, power, and latency

The chip’s intended economic effect follows directly from its architecture. If a workload performs less copying, fewer memory round trips, and less cross-device synchronization, it may spend less time and energy moving data instead of computing on it. That could be useful for multi-stream video understanding, local video processing, and video generation with large intermediate tensors. 3

The potential benefits can be grouped into three areas:

• Latency: fewer transfers between decoding, AI, and encoding stages could shorten the path from input frame to result.
• Power: reducing data movement can reduce the energy spent on memory access and interconnect traffic.
• Cost: a single integrated platform could reduce the infrastructure and operational overhead associated with coordinating multiple specialized devices.

These are the goals described by the available reporting, not independently verified results. The sources provide the headline specifications and architectural rationale, but they do not establish a measured reduction in dollars per video, watts per stream, or milliseconds of end-to-end latency.

What the specifications do—and do not—show

The reported 200 TOPS figure describes INT8 AI compute capacity, not guaranteed application performance. Real video-AI throughput would also depend on model compatibility, precision, memory bandwidth, compiler and runtime support, video formats, batch size, stream count, and the effectiveness of the dataflow scheduler.

Likewise, 128GB of unified memory may help accommodate large models and intermediate data, but capacity alone does not demonstrate that a particular video-generation model will run efficiently. Software support and actual memory traffic remain critical.

The bottom line

Jingang GC3 is best understood as a specialized attempt to redesign the video-AI processing path around data locality. Its reported combination of dataflow execution, RISC-V control cores, integrated CPU/VPU/GPU/NPU paths, and 128GB of unified memory is intended to address the transfers and synchronization barriers that can limit conventional CPU-and-GPU pipelines. 35

If the software and hardware work as intended, the architecture could make multi-stream video understanding and video generation more efficient. For now, however, the strongest defensible conclusion is that GC3 presents a credible architectural strategy and a set of vendor-reported specifications—not independently verified proof of lower cost, power consumption, or latency.