I have implemented a deepstream based software on the Jetson NX platform, which can run normally. When I ported it to the NX Super platform.
I refer to this link to replace the whole “sources/apps”
I refer to this link to recompile the dependency library “nvdsinfer_custom_impl_Yolo.so”
When I was converting the .pt model to an engine by using
“/usr/src/tensorrt/bin/trtexec
–onnx=model_jetson_pgie_n_20250226.onnx
–saveEngine=./model_jetson_pgie_n_20250411_fp16_batch4.engine
–memPoolSize=workspace:4096MiB
–fp16”
on the super platform, I noticed an issue with the workspace(workspace_small.png) which should like this pic(workspace_normal.png) during the conversion process .And it led the issue “Some tactics do not have sufficient workspace memory to run. Increasing workspace size will enable more tactics, please check verbose output for requested sizes.” :
so I remove the “–memPoolSize=workspace:4096MiB” in order to it can conversion normally.
After use the model and lib, running the program (similar to “deeps tram_python_apps” DeepStream-test2), the initial display of the loaded model is as follows of super70.txt :—start----
After running for a period of time, the error is as follows of super70.txt :—error down—
here is super70.txt (running in super) and normal_out.txt(running in orin nx): super70.txt (6.0 KB) normal_out.txt (5.3 KB)
My Question is:
My operation should be standardized and there should be no problem, right?
How to solve the workspace issue raised in the second point? Did it cause CUDAMem error after running for a period of time?
If the error is not related to the workspace issue during model conversion, how to solve the CUDA problem encountered on the super platform?
Hi,
Do you re-flash the whole system to r36.4.3 to enable super mode? The mode is enabled with update in some config files and device tree. It is supposed to have no impact to userspace application.
Do we have a method to compare two models? I wonder why my new model cannot be used normally (the bounding box is not displayed), while the old model can display it. It’s amazing that both the new and old engine models come from the same .pt model.
My operation should be standardized and there should be no problem, right?
right, when I use old onnx file to conversion as you recommend, it can display the bounding box. but still when it run around 10 minutes, window display will stop with exception and the terminal output:
GPUassert: an illegal memory access was encountered /dvs/git/dirty/git-master_linux/deepstream/sdk/src/utils/nvmultiobjecttracker/src/modules/cuDCFv2/cuDCFFrameTransformTexture.cu 693
0:10:40.834126732 15627 0xaaaad3a8a240 ERROR nvinfer gstnvinfer.cpp:1267:get_converted_buffer: cudaMemset2DAsync failed with error cudaErrorIllegalAddress while converting buffer
0:10:40.834163060 15627 0xaaaad3a89c60 ERROR nvinfer gstnvinfer.cpp:1225:get_converted_buffer: cudaMemset2DAsync failed with error cudaErrorIllegalAddress while converting buffer
0:10:40.834212318 15627 0xaaaad3a89c60 WARN nvinfer gstnvinfer.cpp:1894:gst_nvinfer_process_objects: error: Buffer conversion failed
ERROR: Failed to add cudaStream callback for returning input buffers, cuda err_no:700, err_str:cudaErrorIllegalAddress
ERROR: Preprocessor transform input data failed., nvinfer error:NVDSINFER_CUDA_ERROR
0:10:40.834189754 15627 0xaaaad3a8a240 WARN nvinfer gstnvinfer.cpp:1576:gst_nvinfer_process_full_frame: error: Buffer conversion failed
0:10:40.834359582 15627 0xaaaad3a89c00 WARN nvinfer gstnvinfer.cpp:1420:gst_nvinfer_input_queue_loop: error: Failed to queue input batch for inferencing
0:10:40.834324726 15627 0xaaaad3a89c60 ERROR nvinfer gstnvinfer.cpp:1225:get_converted_buffer: cudaMemset2DAsync failed with error cudaErrorIllegalAddress while converting buffer
0:10:40.834432046 15627 0xaaaad3a89c60 WARN nvinfer gstnvinfer.cpp:1894:gst_nvinfer_process_objects: error: Buffer conversion failed
!![Exception] GPUassert failed
An exception occurred. GPUassert failed
gstnvtracker: Low-level tracker lib returned error 1
/dvs/git/dirty/git-master_linux/nvutils/nvbufsurftransform/nvbufsurftransform_copy.cpp:552: => Failed in mem copy
The nvbufsurftransform_copy reports “Failed in mem copy” is a known issue and is fixed in the upcoming Deepstream release.
Please find below comment for more info:
Do you mean this issue is normal in current version of Jetpack6.2 with deepstream-7.1.
I am curious why Jetpack6.0 with Deepstream-7.0 seems not have this question. And if I decrease the ai video channel from 4 to 2, it seems solved.(I say this because the 2 channel video has been running normally since 6pm yesterday until now)
This is a known issue as it has been reported by other users before.
There is a WAR shared in the above link. Could you give it a try to see if it can also help your issue?