GoPoint on i.MX95: NPU object detection shows no boxes while CPU works

[EOF]

Dear NXP Support Team,

I am seeing a likely i.MX95 Neutron/NPU issue on the EVK.

On the same board and camera setup, object detection works on CPU, but when switching to NPU/Neutron there are no boxes, or only weak/static boxes at very low thresholds. This happens not only with my custom YOLOv8 flow, but also with the default GoPoint object-detection application, which makes me suspect a BSP / runtime / Neutron stack issue rather than a model-only problem.

Environment

• Board: i.MX95 EVK

• Kernel: Linux imx95evk 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT Wed Sep 3 05:59:19 UTC 2025 aarch64 GNU/Linux

• /etc/os-release:

  • NXP i.MX Release Distro

  • VERSION="6.12-walnascar (walnascar)"

  • VERSION_ID=6.12-walnascar

• Installed packages:

  • imx-gopoint lf-6.12.34_2.1.0

  • libtensorflow-lite2.19.0 2.19.0-r0

  • tensorflow-lite-neutron-delegate 2.19.0-r0

  • litert-neutron-delegate 1.2.0-r0

  • neutron 1.0.0-r0

  • nnstreamer-tensorflow-lite 2.4.2-r0

• Files present on target:

  • /lib/firmware/NeutronFirmware.elf

  • /lib/libNeutronDriver.so

  • /usr/lib/libneutron_delegate.so

Observed behavior

1. CPU path works for object detection.

2. NPU path does not show valid detections.

3. In the GoPoint/default app, CPU shows boxes and works fine, but NPU shows no boxes at all. 

4. In my own YOLOv8 tests, Neutron inference runs, but detections are either absent or become static/weak and only appear at very low thresholds such as --score-threshold 0.01.

Neutron benchmark results

I ran benchmark_model to isolate model/delegate behavior from the application pipeline.

1. mobilenet_v1_1.0_224_quant.tflite

• Command uses --external_delegate_path=/usr/lib/libneutron_delegate.so

• Result:

  • NeutronDelegate delegate: 0 nodes delegated out of 31 nodes with 0 partitions.

  • Though EXTERNAL delegate is explicitly applied, the model graph will not be executed by the delegate. I think this result makes sense since this model is not converted but only quantized

1. efficientdet_lite0_int8_converted.tflite

• Result:

  • NeutronDelegate delegate: 4 nodes delegated out of 33 nodes with 4 partitions.

  • stable run

  • average inference about 11481.8 us

• Interpretation:

  • partial NPU offload is happening and is stable

1. yolov8n_converted.tflite 

• Result:

  • NeutronDelegate delegate: 2 nodes delegated out of 40 nodes with 2 partitions.

  • stable run

  • average inference about 8689.25 us

• Interpretation:

  • partial NPU offload is happening and is stable

Why I suspect a platform/runtime issue

• The default GoPoint object-detection application also fails on NPU while CPU works.

• The Neutron delegate loads correctly.

• Some converted models do partially offload and benchmark stably.

• However, official/default detection on NPU still produces no boxes, and my own object-detection tests can produce static/weak detections even when delegation is active.

This makes me suspect a BSP / runtime / model compatibility issue on this software stack, rather than a simple application-level bug.

Request

Could you please advise:

1. Whether this is a known issue on i.MX95 with 6.12-walnascar / LF_6.12.34_2.1.0

2. Which exact Neutron converter / runtime / BSP version combination is recommended for reliable object detection on i.MX95

3. Whether there is a newer BSP or Neutron package set that fixes the “CPU works, NPU gives no or static boxes” behavior

4. Whether you can provide a known-good i.MX95 object-detection model/package pair that is confirmed to work on NPU on this release

I can provide full logs, exact commands, and converted models if needed.

Best regards,
EOF

[Chavira]

Hi @EOF,
Thank you for contacting NXP Support!

At the moment, the i.MX95 is still in the pre production stage. I recommend using the latest BSP version available in order to benefit from the most recent updates and fixes for the i.MX95.

Object detection is working correctly on the latest BSP releases, I have personally tested it on both available versions.

If you are observing poor NPU delegation during model execution, this may indicate that the model needs to be recompiled using INT8 quantization with the eIQ Toolkit prior to deployment. Models that are not fully optimized or quantized may not achieve optimal NPU utilization.

Overall, the recommendation is to continue using the latest BSP version and apply all available updates until the official release of the i.MX95.

Best regards,
Chavira

[EOF]

Hi @Chavira ,

Thank you for your reply, 

Regarding GoPoint, I used the default object detection demo, that is why I expected to work, since it was by default in the Linux 6.12.34 BSP. Meaning, I did not compile the model myself, but used default model by GoPoint.

1) Do you recommend using then Linux 6.12.49_2.2.0 BSP with eIQ Toolkit 1.17.0.110 or eIQ Neutron SDK 3.0.1 neutron converter?

2) Regarding the compilation, do you mean, that is recommended to convert the float model into int8 model in eIQ first and then convert it with neutron delegate?

Best regards,

EOF

[Chavira]

Hi @EOF,

1) I recommend always using the latest Neutron SDK version. If you want to work with Neutron SDK 3.0.1, you must also install the required runtime packages on your board, as described in the Neutron SDK documentation.

2) Yes, that is the correct behavior of the Neutron NPU,  it only executes INT8 operations.
If the model is not quantized to INT8 before converting it with the Neutron tools, most of the operations will fall back to the CPU

[EOF]

Hi @Chavira ,

Thank you for your reply.

I have two follow-up questions:

1) First, would you recommend that I also update my Linux BSP, for example to Linux 6.12.49_2.2.0, or should I keep my current setup with Linux imx95evk 6.12.34-lts and simply use eIQ Neutron SDK 3.0.1, provided that the required 3.0.1 runtime packages are installed?

2) Second, I may not have explained myself clearly in my previous message. What I meant is that I am considering first quantizing the float model using the eIQ tools, and then running the Neutron converter on the resulting int8 model. Is this what you meant by "model needs to be recompiled using INT8 quantization with the eIQ Toolkit prior to deployment"?

At the moment, without using eIQ for quantization, I already have a quantized model and have only used the Neutron converter to make it compatible with the NPU. My question is whether I should instead use eIQ itself to perform the quantization step as well, meaning that eIQ would generate the quantized version of the model before I run the Neutron converter.

I understand that the model must be quantized before conversion.

Best regards,

EOF