i.MX8M Plus: Intermittent Downward Frame Shift and Green Top-Band Flicker During Concurrent VIP8000 1. System and Environment Parameter Configuration SoC NXP i.MX 8M Plus Quad Silicon Revision A1 / B0 Kernel 6.12.20-lts-next-g604d4ef7a1e4 BSP NXP linux-imx / LTS-Next Vivante / Galcore Driver 6.4.11.p3.1049711 Galcore Location drivers/mxc/gpu-viv/galcore (built-in) 2D Engine Vivante GC520L (imxvideoconvert_g2d / libg2d.so) NPU VeriSilicon/Vivante VIP8000 NPU Performance 2.3 TOPS Video Encoder Hantro VC8000E (v4l2h264enc) RAM ~5.7 GB LPDDR4 CMA Total ~960 MB 2. Problem Description We are observing an intermittent video corruption issue when VIP8000 NPU inference runs concurrently with hardware scaling/color conversion using the GC520L G2D engine. The affected H.264 stream does not become completely green. Instead, an individual frame occasionally shows the following behavior: The active image appears to shift downward by a small number of pixels/scanlines. A horizontal green band appears at the top of the frame. The following frame immediately returns to the correct position. The result is an intermittent downward frame jump / green top-edge flicker. The issue is reproducible during concurrent accelerator workloads but cannot be reproduced reliably when the NPU or G2D workloads are tested independently. 3. Key Observations 3.1 G2D-only workload is stable We can run up to three concurrent G2D video branches: Main: 1080p Sub: 360p MJPEG: 480p with the NPU disabled. The video remains stable for extended periods with no observed green frames or frame shifts. 3.2 NPU-only workload is stable Heavy VIP8000 NPU inference at approximately 15–30 FPS runs continuously without observed inference errors or video corruption when G2D processing is not active. 3.3 Replacing G2D with CPU processing eliminates the issue When hardware G2D processing is replaced with: videoscale ! videoconvert the system remains stable while the NPU continues running at full workload. The green-band/frame-shift issue is no longer observed. 3.4 Concurrent NPU + G2D triggers the issue When the NPU is active and G2D is simultaneously used for video/AI processing, the corruption appears. The frequency increases when additional G2D workloads are introduced. This suggests that the issue is related to concurrent accelerator activity rather than the individual NPU or G2D workload alone. 4. Test Matrix We performed the following tests to isolate the failure condition. Test NPU AI Processing Video G2D Result 1 OFF None Main + Sub + MJPEG (3 G2D branches) PASS — No flicker 2 OFF SHM attached Main + Sub + MJPEG PASS — No flicker 3 ON G2D enabled Main G2D FAIL — Intermittent green-band/frame-shift observed 4 ON CPU (videoscale ! videoconvert) Main G2D PASS — Main stream clean 5 ON CPU Main + Sub G2D FAIL — Issue appears when additional G2D workload is introduced 6 ON CPU All video branches converted to CPU scaling PASS — All streams remain clean Note: We are currently preparing a smaller standalone reproducer to determine the exact minimum number of concurrent G2D clients required to trigger the issue. 5. Current Investigation Based on the above results, we would like to understand whether this behavior could be related to one of the following areas. A. Galcore / Accelerator Concurrency In our device tree, the GPU/NPU components are part of the same GPU/ML subsystem: mix_gpu_ml@40000000 {
compatible = "fsl,imx8mp-gpu", "fsl,imx8-gpu-ss";
cores = <&gpu_3d &ml_vipsi &gpu_2d>;
reg-names = "phys_baseaddr", "contiguous_mem";
memory-region = <&gpu_reserved>;
}; The interrupts are also handled by galcore: 34: 520 0 0 0 GICv3 35 Level galcore:0
35: 13583 0 0 0 GICv3 45 Level galcore:3d-1
36: 1737916 0 0 0 GICv3 57 Level galcore:2d We would like to understand: Does galcore share synchronization primitives or locks between the GC520L, GC7000 and VIP8000? Are G2D and NPU command queues completely independent? Are there any known limitations when multiple G2D clients/processes submit work while VIP8000 inference is active? Could command submission, context management, interrupt handling, or resource locking introduce delays under concurrent workloads? B. NoC / DDR Bandwidth or QoS Both the GC520L G2D and VIP8000 NPU are active bus masters accessing external LPDDR4 memory. We would like to determine whether heavy NPU inference could: Increase NoC/DDR traffic significantly. Increase memory access latency for G2D. Cause G2D transactions to be delayed. Expose a timing/synchronization issue between G2D and downstream consumers. Be affected by NoC/DDR QoS priorities. Could NXP provide guidance on the recommended NoC/AXI/DDR performance monitoring and QoS facilities available on i.MX8MP for investigating this type of workload? C. G2D Buffer Synchronization / Fence / Stride Issue The visual artifact is particularly interesting because the entire frame is not corrupted. The affected frame appears approximately as follows: +----------------------------------+
| GREEN HORIZONTAL BAND |
+----------------------------------+
| |
| |
| IMAGE SHIFTED DOWN |
| |
| |
+----------------------------------+ This makes us question whether the issue could involve: G2D destination buffer synchronization. DMA-BUF ownership/reuse. Fence signaling/completion. Temporary G2D destination offset/stride state. Delayed G2D memory writes. Downstream VPU access occurring before the G2D operation has completely finished. In particular, could a delayed G2D completion or synchronization event cause v4l2h264enc / VC8000E to consume a destination DMA-BUF before all G2D writes have completed? Is there a documented synchronization mechanism in the NXP G2D/V4L2 pipeline that guarantees G2D completion before the destination DMA-BUF is consumed by the VPU? D. Memory / CMA We monitored memory usage while reproducing the problem: Total RAM : ~5.7 GB
CmaTotal : ~960 MB
CmaFree : ~677 MB CMA is therefore not close to exhaustion during the failure. However, we would like to know whether there are other memory-related considerations that could affect concurrent NPU/G2D/VPU workloads, such as: DMA-BUF synchronization. Cache coherency. Memory-domain mapping. Physical buffer alignment. Buffer reuse. IOMMU/MMU mappings. Reserved-memory interactions. 6. Additional Diagnostic Experiments We are currently preparing a minimal standalone reproducer to remove application-level complexity. The planned reproducer will contain: Thread 1 → VIP8000 NPU inference
Thread 2 → GC520L G2D processing
Thread 3 → Additional GC520L G2D processing We also plan to test the following configurations: NPU OFF + G2D
NPU ON + G2D
NPU ON + 2 × G2D
NPU ON + G2D → buffer inspection
NPU ON + G2D → VPU encoder This should help determine whether the corruption occurs in the G2D output buffer itself or only after the buffer is consumed by the VPU. 7. Questions for NXP We would appreciate NXP's guidance on the following. 1. Known hardware/software limitations Is concurrent operation of: VIP8000 NPU
+
GC520L G2D
+
VC8000E VPU fully supported on i.MX8M Plus, including multiple simultaneous G2D clients? Are there any known hardware limitations, errata, or software restrictions related to this combination? 2. Galcore Are there known galcore issues involving concurrent VIP8000 and GC520L operation? In particular, are there known issues involving: shared locks, command queues, context switching, interrupt handling, synchronization, or resource management? 3. DMA-BUF / synchronization What mechanism is used to guarantee G2D completion before a destination DMA-BUF is consumed by downstream V4L2/VPU components? Are there known fence or buffer-ownership issues in imxvideoconvert_g2d / libg2d under concurrent accelerator workloads? 4. NoC / QoS What debug registers, debugfs nodes, performance counters, or tools does NXP recommend for measuring: GC520L AXI traffic, VIP8000 AXI traffic, VPU traffic, DDR bandwidth, NoC contention, and QoS/arbitration behavior? 5. Driver version We are currently using: Kernel:
6.12.20-lts-next-g604d4ef7a1e4
Galcore:
6.4.11.p3.1049711 Is this combination a validated/recommended configuration for i.MX8MP? Is there a newer galcore / G2D driver or patchset that addresses concurrent NPU/G2D workloads? 6. Silicon errata Could you please confirm whether the applicable i.MX8M Plus silicon errata for our A1/B0 revisions contain any issues related to: G2D, VIP8000, VPU, AXI/NoC arbitration, DDR, cache coherency, or concurrent accelerator operation? 7. Recommended configuration For an application requiring: VIP8000 NPU inference
+
multiple G2D scaling/color-conversion pipelines
+
VC8000E H.264 encoding what configuration does NXP recommend? Are there specific: driver parameters, QoS settings, memory/buffer-pool configurations, synchronization mechanisms, or GStreamer pipeline practices that should be followed? 8. Information We Can Provide We can provide the following if required: Complete GStreamer pipelines. Device-tree configuration. Kernel configuration. dmesg output during reproduction. /proc/interrupts. G2D/NPU workload details. v4l2-ctl information. Minimal NPU + G2D reproducer. Video samples containing the corrupted frames. Driver versions and build information. We would appreciate any guidance on the recommended debug procedure or additional traces/registers that would help determine whether the root cause is related to G2D/NPU synchronization, DMA-BUF/fence handling, NoC/DDR contention, galcore, or a silicon limitation. Thank you. Vishnu S i.MX 8M | i.MX 8M Mini | i.MX 8M Nano
記事全体を表示
