The RK3588 is often introduced as a list of specifications: eight CPU cores, a Mali-G610 GPU, a 6 TOPS NPU, 8K-class video support, and high-speed I/O.
Those specifications are useful, but they do not explain how the chip behaves under real workloads.
An application does not simply “run on the RK3588.” Latency-sensitive work may run on the four Cortex-A76 performance cores while background tasks use the four Cortex-A55 efficiency cores. A neural network may run on the NPU, but image resizing and post-processing can still use the CPU or RGA. A media server may use very little CPU while dedicated video hardware handles a 4K transcode.
All of these engines also depend on the same external memory system. In some workloads, moving a buffer one extra time can matter more than adding more theoretical compute.
This article uses the Turing RK1 compute module to explain how the main RK3588 blocks work together. It focuses on how the CPU, GPU, NPU, memory, media engines, and software stack affect one another during real workloads.
This is not a replacement for the RK1 benchmark article, the RK3588 LLM benchmark, or the Jellyfin hardware-transcoding guide. Those articles focus on individual workloads. Here, we use some of their results to explain what is happening inside the SoC.
By the end, you should understand why four CPU threads can beat eight for some LLM workloads, why a 6 TOPS rating does not mean every AI model can use the NPU, and why shared memory is both useful and a possible bottleneck.
Quick Overview: RK3588 Architecture at a Glance
The RK3588 combines two CPU clusters with a Mali-G610 GPU, a three-core NPU, dedicated media hardware, RGA image processing, camera ISPs, display controllers, and a shared LPDDR memory system. The RK1 is available with 8 GB, 16 GB, or 32 GB of LPDDR memory.
| Component | Best suited to |
| Cortex-A76 cluster | Latency-sensitive code, compilation, and application logic |
| Cortex-A55 cluster | Background services and lighter parallel work |
| Mali-G610 GPU | Graphics and supported GPU compute |
| Three-core NPU | Supported neural-network inference through RKNN |
| VPU | Hardware video decode and H.264/H.265 encode |
| RGA | Scaling, cropping, rotation, and color conversion |
| ISP | Camera input, HDR, noise reduction, and image preparation |
| LPDDR memory | Shared data store for CPU, GPU, NPU, media engines, and I/O |
Part 1: Reference Platform
The reference platform for this article is a 32 GB Turing RK1 installed in a Turing Pi 2.5 with a 1 TB NVMe SSD and Ubuntu Server 24.04 LTS.
| Item | Configuration |
| Compute module | Turing RK1 with Rockchip RK3588 and 32 GB RAM |
| Baseboard | Turing Pi 2.5 |
| Storage | 1 TB NVMe SSD |
| Operating system | Ubuntu Server 24.04 LTS |
| Kernel | Linux 6.1.0-1025-rockchip |
| CPU configuration | 4× Cortex-A76 at up to 2.4 GHz + 4× Cortex-A55 at up to 1.8 GHz |
| CPU governor | Performance |
| GPU | Mali-G610 MP4 |
| NPU | RK3588 three-core NPU |
| Cooling | Turing RK1 Heatsink with 5 V PWM fan |
The software stack matters because the CPU uses standard Linux interfaces, while the NPU and media engines depend more heavily on matching drivers, firmware, and userspace libraries. Different kernel and userspace combinations can expose different accelerator features, so the software environment is part of the platform.
The new CPU and memory-contention measurements in this article were collected on Linux 6.1.0-1025-rockchip. The CPU benchmarks used the performance governor, and each benchmark was warmed up and run three times with the median result reported. CPUs 0-3 were the Cortex-A55 cluster and CPUs 4-7 were the Cortex-A76 cluster. The Turing RK1 Heatsink remained installed throughout the tests.
Part 2: The RK3588 Is More Than an Eight-Core CPU
A useful way to think about the RK3588 is as several specialized processors connected to one shared memory system.
At the center are two CPU clusters: four high-performance Cortex-A76 cores and four smaller Cortex-A55 cores. Alongside them sit the Mali-G610 GPU, three-core NPU, video codecs, RGA image engine, camera ISPs, display controllers, DMA engines, and I/O.
Each block has local storage or caches that reduce repeated trips to external memory. In the RK3588 implementation, each CPU core has private L1 and L2 caches, while the CPU side has 3 MB of shared L3 cache. Rockchip’s block diagram shows four 256 KB GPU L2 slices, for 1 MB total, and 1 MB of shared on-chip NPU memory. These caches reduce repeated memory access, but large models, frames, and buffers still depend on LPDDR. The cache and memory figures come from Rockchip’s RK3588 brief datasheet.
Linux drivers can allocate or import buffers, make them available to an accelerator, submit work, and synchronize access between stages. Rockchip MPP uses MppBuffer for media buffers, while RKNN supports memory import and synchronization. When layouts, alignment, formats, and ownership rules match, these interfaces can reduce unnecessary copies between stages.
This is why shared memory does not mean that data movement is free. Avoiding a physical copy can save bandwidth and latency, but the producer and consumer still have to agree on buffer layout, pixel or tensor format, alignment, and synchronization. If the VPU outputs a format that the next stage cannot consume, software may allocate another buffer and convert the frame. The data never leaves the RK3588, but it can still cross LPDDR multiple times.
The important distinction is between sharing the same memory system and actually avoiding extra copies between stages.
Part 3: CPU Architecture: Four Fast Cores and Four Efficient Ones
The RK3588 combines four Cortex-A76 cores running at up to 2.4 GHz with four lower-clocked Cortex-A55 cores.
The Cortex-A76 is designed for strong single-thread performance and can execute instructions out of order to keep more of the core busy. Arm describes it as a four-wide decode design with high-bandwidth branch prediction and instruction fetch, prefetching, and 128-bit SIMD. Latency-sensitive code, compilation, compression, and CPU inference generally perform best here. See Arm’s Cortex-A76 architecture overview.
The Cortex-A55 is a smaller efficiency-focused core. It runs the same ARM64 software, but completes less work per clock. The A55s suit background services, operating-system work, networking, and lighter parallel tasks.
The RK3588 cache layout explains part of the behavior:
| Cluster | Private L1 instruction/data | Private L2 | Shared CPU L3 |
| 4× Cortex-A76 | 64 KB + 64 KB per core | 512 KB per core, 2 MB total | 3 MB |
| 4× Cortex-A55 | 32 KB + 32 KB per core | 128 KB per core, 512 KB total | 3 MB |
Linux schedules runnable threads using demand, core capacity, power state, and affinity. An eight-thread job uses both clusters, increasing aggregate compute but also creating uneven completion times between four fast and four slower cores.
Earlier GGUF benchmarks already showed this behavior. Four CPU threads produced better token-generation throughput than eight across the tested models, even though eight threads sometimes improved prompt processing. With four threads, the hot generation loop could stay on the four A76 cores. With eight, the workload also used the slower A55 cluster and created more cache and memory traffic.
This does not mean “never use eight threads.” Kernel compilation, rendering, compression, and batch processing may scale well across all eight cores. It means the correct thread count depends on whether the workload is compute-bound, memory-bound, synchronized between threads, or dominated by one serial stage.
A76, A55, and all-core benchmark
The tested RK1 mapped CPUs 0-3 to the Cortex-A55 cluster at up to 1.8 GHz and CPUs 4-7 to the Cortex-A76 cluster at up to 2.4 GHz.
| Workload | 4× A76 | 4× A55 | All 8 cores |
| Sysbench CPU throughput | 3904.34 events/s | 1452.89 events/s | 5298.59 events/s |
llama-bench tg256 | 5.462 t/s | 1.493 t/s | 3.846 t/s |
Sysbench scaled well across both clusters. The four A76 cores reached 3904 events/s, about 2.7 times the throughput of the four A55 cores. Using all eight cores increased throughput to 5299 events/s, about 36% above the A76-only result. For workloads that parallelize cleanly, the A55 cluster adds useful extra throughput.
llama-bench behaved differently. With Qwen2.5-7B-Instruct Q4_K_M, the four A76 cores reached 5.462 tokens/s. The four A55 cores reached 1.493 tokens/s, while all eight cores reached 3.846 tokens/s, about 30% below the A76-only result. In this memory-sensitive generation workload, adding the slower A55 cores did not improve throughput.
Together, the two results show why workload-aware scheduling matters on the RK3588. More cores can help highly parallel CPU work, while latency-sensitive or memory-heavy workloads can perform better on the four faster A76 cores. Variation across the three measured runs stayed below 1.3% for every configuration.
Peak temperatures were 75.77°C during the A76 llama-bench run, 62.85°C on the A55 cluster, and 72.08°C across all eight cores. Frequencies remained stable, and no frequency throttling was observed.
Part 4: Memory Architecture: The Shared Resource Behind Every Headline Number
Rockchip’s block diagram shows a four-channel LPDDR interface, with each channel 16 bits wide. Together, that creates a 64-bit external memory path. The RK3588 supports LPDDR4, LPDDR4X, and LPDDR5 at the SoC level; the Turing RK1 is specified with up to 32 GB of LPDDR memory.
Capacity and bandwidth solve different problems. Moving from an 8 GB RK1 to a 32 GB model lets the system hold larger datasets, more containers, and bigger models. It does not make the memory interface four times faster. Our earlier RK1 testing found broadly consistent bandwidth across memory capacities because the controller and memory configuration, not the number of installed gigabytes, set throughput.
In our earlier RK1 benchmark article, measured bandwidth reached approximately 21-22 GB/s in STREAM, 17-19 GB/s in the mbw block-copy test, and 8-9 GB/s for memcpy. The numbers differ because each test moves memory in a different way and uses caches and CPU instructions differently. Those earlier measurements provide a useful baseline for the contention test below.
The earlier concurrency test was even more revealing. With two simultaneous memory-bound sessions, each received roughly 60-65% of the single-session bandwidth. With three sessions, each received about 40-50%. The contention benchmark below shows the same shared-memory effect with a real application workload.
That behavior reaches far beyond synthetic memory tests:
- CPU-based LLM generation repeatedly streams model weights from memory.
- A GPU renderer reads textures and geometry, then writes framebuffers.
- NPU inference reads weights and tensors while the CPU prepares inputs and handles outputs.
- A video pipeline reads compressed packets, writes decoded frames, transforms them, and reads them again for encode or display.
- NVMe and network devices use DMA to move data into and out of system memory.
The engines have local caches, but large working sets eventually depend on LPDDR. The system can show low CPU use and still be limited by memory bandwidth.
Shared-memory contention benchmark
To make the shared-memory effect visible, llama-bench was pinned to the four A76 cores while STREAM used four OpenMP workers on the four A55 cores. The workloads therefore used separate CPU clusters while sharing the same LPDDR memory system.
| Workload | Baseline | With STREAM load | Change |
llama-bench generation throughput | 5.462 t/s | 2.939 t/s | 46.2% lower |
With STREAM active on the A55 cluster, llama-bench fell from 5.462 to 2.939 tokens/s. STREAM used a 2.2 GiB working set and reached a median Triad bandwidth of 11.75 GB/s during contention, compared with 21.53 GB/s when run by itself.
The result makes the shared-memory behavior easy to see. The competing workload never used the A76 cores running llama.cpp, yet generation still slowed substantially because both clusters were moving data through the same LPDDR system. CPU utilization alone would not reveal that bottleneck.
Peak temperature during the contention test was 74.85°C. Frequencies remained stable on both CPU clusters, and no frequency throttling was observed.
Part 5: Mali-G610 MP4: Graphics Processor and Parallel Compute Engine
The RK3588 integrates an Arm Mali-G610 MP4. Here, “MP4” denotes a four-core GPU implementation; it does not refer to the MPEG-4 video format, and GPU cores are not directly comparable to CPU cores. The G610 uses Arm’s third-generation Valhall architecture and is built for modern graphics APIs. Rockchip lists OpenGL ES up to 3.2, Vulkan up to 1.2, and OpenCL support. On Linux, the APIs available to applications depend on the installed kernel and userspace driver.
The GPU is designed to run many similar operations at the same time. In graphics, the CPU prepares application state and submits command buffers. The GPU transforms vertices, runs shaders, samples textures, rasterizes geometry, and writes the completed image. In a compute workload, the same parallel execution resources can run kernels for image filters, parallel calculations, or supported machine-learning operations.
The GPU has its own cache hierarchy, including 1 MB of L2 in the RK3588 implementation, but it does not have discrete VRAM. Textures, buffers, shader data, and framebuffers occupy system LPDDR. This reduces the need to copy data across a discrete PCIe link, but it also means the GPU competes with the CPU, NPU, media engines, and I/O.
Arm Frame Buffer Compression can reduce memory traffic by compressing compatible graphics surfaces without losing image data. That helps within graphics and display pipelines, but compatibility matters. If another engine cannot consume the same compressed layout, the frame may need conversion before it can move to the next stage.
On Linux, the driver determines how much of the GPU applications can use. Vendor libmali and upstream Mesa drivers can expose different feature sets depending on the kernel and userspace versions, so graphics output alone does not describe the full compute or API support available.
The important architectural point is that the GPU has its own execution resources and caches, while large graphics and compute buffers still live in system memory. In practice, driver support and shared memory behavior can matter as much as a single graphics score.
Part 6: The 6 TOPS NPU: Dedicated AI Acceleration
The RK3588’s three-core NPU is rated for up to 6 TOPS under supported low-precision workloads. Rockchip lists INT4, INT8, INT16, FP16, BF16, and TF32 acceleration.
TOPS means trillions of operations per second under a specific data format and ideal conditions. It does not mean the NPU can execute six trillion arbitrary CPU instructions, and it does not guarantee that an entire neural network maps to the accelerator.
A model normally begins in PyTorch, TensorFlow, or ONNX. RKNN Toolkit2 converts the graph on a development system, changing layouts, fusing operations, and quantizing when requested. On the RK1, the runtime loads that compiled model, assigns NPU cores, binds memory, and submits inference.
RKNN exposes NPU core-mask selection, including masks that enable more than one RK3588 NPU core, and provides memory-import and synchronization interfaces. Multi-core scaling depends on the graph, runtime, execution mode, and workload; enabling all three cores does not guarantee three times the performance. These interfaces matter because inference contains more than matrix multiplication:
- The CPU receives or loads the input.
- The image is decoded, resized, normalized, and converted to the model’s tensor layout.
- The NPU executes supported graph operations.
- The CPU decodes outputs, applies thresholds or non-maximum suppression, and turns tensors into useful results.
- A GPU, RGA, or CPU may render boxes and labels.
For example, if preprocessing takes 8 ms, NPU execution takes 6 ms, and post-processing takes 5 ms, the complete pipeline takes about 19 ms before queuing and synchronization. That is roughly 52 fps, not the 166 fps suggested by the NPU execution time alone. Extra frame copies can reduce throughput further.
Rockchip’s current single-core RK3588 model-zoo results include approximately 467.0 fps for INT8 MobileNetV2, 99.0 fps for INT8 ResNet-50, and 90.2 fps for INT8 YOLOv8n at 640×640. These are model-execution references measured at the platform’s maximum NPU frequency; Rockchip explicitly excludes preprocessing and post-processing. They are not end-to-end RK1 results, and performance can change with the model-zoo and RKNPU SDK versions. See the RKNN Model Zoo benchmark table.
| Model | Rockchip RK3588 single-core execution reference |
| MobileNetV2 INT8, 224×224 | 467.0 fps |
| ResNet-50 INT8, 224×224 | 99.0 fps |
| YOLOv8n INT8, 640×640 | 90.2 fps |
Part 7: VPU, RGA, ISP, and Display: The Blocks That Keep Pixels Away from the CPU
The RK3588 contains several multimedia engines that are easy to overlook because they are neither CPU, GPU, nor NPU.
The RK3588 contains dedicated hardware for supported video decode and encode paths. Rockchip advertises 8K-class decoding for formats including H.265, H.264, VP9, AV1, and AVS2, plus H.264/H.265 encoding. The maximum resolution and frame rate depend on the codec, profile, bit depth, and software path, so an “8K60 decode” claim should not be applied to every format. MPP connects applications to these codec blocks.
RGA is a separate 2D engine for scaling, cropping, rotation, color conversion, and composition. It can bridge decoded or camera frames into the size and format required by the NPU or encoder.
The ISP processes camera data and supports features such as HDR and noise reduction. Available camera paths and throughput depend on the sensor, board routing, drivers, and camera stack.
The display controller scans finished surfaces out to HDMI, DisplayPort, eDP, or MIPI. Display composition is distinct from 3D rendering, although the GPU may create displayed surfaces.
Our earlier Jellyfin benchmark shows why these dedicated media blocks matter. A 4K HEVC Main10 to 540p H.264 transcode used about 727% CPU and reached only 0.65× real time in software. With RKMPP hardware acceleration, CPU use fell to roughly 3-8% and throughput reached about 306 fps. A 4K AV1 source showed a similar change. These are previously measured results from the setup documented in that article.
That speedup does not come from the GPU alone. Dedicated codec blocks handle supported decode and encode, RGA can handle scaling and format conversion, and the CPU still manages Jellyfin, FFmpeg control, audio, packaging, and delivery. FFmpeg and Jellyfin logs show which hardware path is active, while low CPU use by itself does not identify the exact engines involved.
| Source → output | Software CPU | Hardware pipeline |
| 4K HEVC Main10 → 540p H.264 | 727% CPU, 39 fps | 3-8% CPU, ~306 fps |
| 4K AV1 Main → 540p H.264 | 733% CPU, 37 fps | 4-8% CPU, ~306 fps |
If the selected software path cannot use RKMPP, Jellyfin can fall back to CPU transcoding even though the VPU is present. This is why software support matters just as much as the hardware block itself.
Part 8: What Typically Happens During Real Workloads
The clearest way to understand the RK3588 is to follow complete workloads.
Workload 1: Running a GGUF language model with llama.cpp
In the CPU-only path tested in our earlier article, Linux maps the model file from NVMe through the page cache and virtual-memory system. The CPU tokenizes the prompt and performs inference with optimized ARM64/NEON code. Model weights exceed CPU caches, so generation repeatedly depends on LPDDR; the GPU and NPU remain uninvolved unless a separate offload path is explicitly configured and verified.
This explains two measured results from the series: Q4_K_M was consistently faster and smaller than higher-precision GGUF formats during generation, and four CPU threads beat eight. Lower-bit weights reduce the number of bytes that must move for each generated token; keeping execution on the four A76 cores avoids adding slower A55 threads and extra contention to a memory-sensitive loop.
Workload 2: Running a converted vision model on the NPU
On a supported RKNN software stack, an image can arrive from storage, network, or camera. RGA can resize and convert it while the CPU handles remaining normalization and tensor metadata. RKNN submits the tensor to the NPU; the CPU post-processes outputs; then RGA, GPU, or CPU draws the result.
The NPU accelerates only the middle of that chain. A weak preprocessing path can leave the NPU idle between frames. A copy-avoiding buffer path can improve throughput without changing NPU clock speed or TOPS.
Workload 3: Transcoding 4K video in Jellyfin
NVMe or network storage supplies compressed packets. In a supported RKMPP pipeline, MPP submits them to a hardware decoder; RGA may scale or convert compatible DMA-backed frames; and a hardware encoder produces the output stream. The CPU handles Jellyfin, FFmpeg control, audio, packaging, and delivery. A supported GPU/OpenCL filter may also participate in a configured tone-mapping path. The exact mix of engines depends on the FFmpeg graph and is visible in the application logs.
When RKMPP is missing, much of the decode and encode work falls back to the CPU. That is why the same physical RK3588 can look either exceptionally efficient or completely overwhelmed depending on the software path.
Workload 4: Compiling Linux while services remain online
Compilation creates many CPU tasks across both clusters. Files move through the page cache to NVMe while compiler working sets pressure every cache level. There is no specialized accelerator: CPU, memory, storage, and cooling determine the result.
Our earlier testing found that a Linux 6.1 build took approximately 28-32 minutes from eMMC, while the tested NVMe-backed configuration improved compile time by roughly 20-30%. The exact gain depends on the build and storage setup, but the result shows how faster storage can keep the CPU fed during I/O-heavy work.
Workload 5: AI camera pipeline with a live overlay
A typical AI camera pipeline shows the different RK3588 engines working together clearly. The ISP receives camera data and performs image correction. RGA produces an NPU-sized input. The NPU runs object detection. The CPU interprets detections and manages application state. The GPU or RGA draws overlays. The display controller scans the final image out, while the VPU can simultaneously encode a recording.
No single utilization number describes that pipeline. One engine can be idle while the system waits on memory, a format conversion, synchronization, or a CPU step.
Part 9: What Shapes RK3588 Performance
RK3588 performance depends heavily on how software maps work to the available hardware. The SoC provides several specialized engines, and the biggest gains usually come from using those engines well and keeping data movement efficient.
Choosing the right engine. Software video decode, CPU-based image resizing, or neural inference without RKNN can use far more CPU time and power than a supported dedicated hardware path. Selecting and verifying the right accelerator lets the RK3588 use its specialized blocks more effectively.
Keeping buffer movement efficient. Large video frames and tensors create a lot of memory traffic. Shared memory helps, but stages still need compatible formats, layouts, and synchronization. A copy-avoiding path is useful only when the producer and consumer can share the buffer correctly.
Scheduling across the two CPU clusters. More threads can bring the slower A55 cores into a latency-sensitive workload. That may help, hurt, or increase variance depending on the workload.
Matching models to the NPU toolchain. The NPU delivers its best results when the model converts cleanly and uses supported operators. Precision, tensor layout, preprocessing, and post-processing all shape end-to-end performance.
Planning for shared-memory traffic. The CPU, GPU, NPU, video engines, display, storage, and network I/O all create memory traffic. Several fast workloads can compete for the same LPDDR bandwidth.
Keeping the software stack aligned. The GPU, NPU, MPP, RGA, kernel, firmware, and userspace libraries work as a stack. Different kernel branches can expose different upstream and vendor accelerator features, so the best software choice depends on the workload.
Maintaining thermal and power headroom. Sustained workloads can reduce clock speeds if cooling or power headroom runs out. In our CPU and contention tests, frequencies remained stable and no throttling was observed, so the measured performance differences were not caused by thermal limits.
Part 10: How to Design Software Around the RK3588
The RK3588 works best when each stage is sent to the right engine.
- Keep latency-sensitive code on the A76 cores when testing shows a benefit.
- Use A55 cores for background work, lower-priority services, and parallel tasks that scale efficiently.
- Use the VPU for supported video decode and encode instead of treating the GPU as a universal media accelerator.
- Use RGA for compatible scaling and pixel-format operations before spending CPU cycles on full frames.
- Convert and quantize NPU models for the actual RKNN target, then measure the complete application rather than quoting TOPS.
- Reuse DMA-capable buffers and compatible layouts between stages when the software stack supports it.
- Treat memory bandwidth as a shared budget. Benchmark important workloads both alone and under realistic concurrency.
The best RK3588 application uses the appropriate engine for each expensive stage and avoids moving the same data unnecessarily.
Conclusion: The RK3588’s Real Advantage Is Coordination
The RK3588 is powerful because it combines several different types of compute on one SoC. The Cortex-A76 cores handle fast general-purpose work, the Cortex-A55 cores handle lighter tasks, the Mali-G610 handles graphics and supported compute, the NPU accelerates compatible neural networks, and the media blocks handle video and image processing.
The important part is how those blocks work together.
A fast NPU can still sit idle while the CPU prepares an image. Eight CPU cores can lose to four when extra threads add slower cores and more memory pressure. Hardware video can be extremely efficient, but only when the software stack actually reaches the codec hardware.
The specification tells us what hardware is available. Real performance depends on choosing the right engine, keeping data movement under control, and using a software stack that exposes the hardware correctly.
That is what makes the RK3588 more than an eight-core ARM CPU with a few accelerators attached. It is a compact platform with several different compute engines, and its performance depends on how well those parts work together.
FAQ: RK3588 Architecture
Does the RK3588 have eight identical CPU cores?
No. It has four Cortex-A76 performance cores and four Cortex-A55 efficiency cores. They run the same ARM64 software but have different core designs, cache sizes, clocks, and performance levels.
Does the GPU have dedicated video memory?
No. The Mali-G610 uses system LPDDR. Its local caches reduce traffic, but large textures, buffers, and framebuffers share external memory bandwidth with the rest of the SoC.
Can any AI model use the 6 TOPS NPU?
No. A model must be supported and converted through Rockchip’s RKNN toolchain. Operator support, tensor layout, precision, preprocessing, and CPU post-processing all affect whether NPU acceleration is useful.
Is the GPU responsible for hardware video transcoding?
Usually not. The RK3588 has dedicated video decode and encode hardware exposed through Rockchip MPP/RKMPP. RGA handles many image transformations, while the GPU may assist with particular filters such as OpenCL tone mapping.
Why can four CPU threads outperform eight?
Four threads can remain on the four Cortex-A76 performance cores. Adding four more may use the slower Cortex-A55 cores and create additional cache and memory contention. Whether eight cores help depends on the workload.
Does 32 GB of RAM provide more bandwidth than 8 GB?
Not automatically. Capacity determines how much data can remain resident. Bandwidth depends on the memory interface, memory devices, frequencies, timings, and access pattern. The earlier RK1 tests found similar bandwidth across capacity tiers.
Can the CPU, GPU, NPU, and VPU operate simultaneously?
Yes, but performance does not increase evenly just because more engines are active. They share memory bandwidth, power, and cooling limits, so one workload can slow another even when they use different engines.
Is mainline Linux or the Rockchip BSP better for the RK3588?
It depends on the workload. Mainline kernels can provide newer upstream support and maintenance, while Rockchip BSP kernels may expose vendor media, NPU, and GPU interfaces required by specific applications. The better choice depends on which accelerators and software interfaces the deployment needs.