2412035_en-US

Yes

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