UYVY for cuGraphicsEGLRegisterImage in 32.2 SDK

Robotics & Edge Computing Jetson Systems Jetson TX2
1

I use 28.2.1 SDK with cuda-9 for image processing on cuda and h264 encoding. Image from our cameras can be in uyvy or in yuyv formats.

Now I try to update our code for 32.2 release and faced with problem:
When I try to pass dmabuf to CUDA - cuGraphicsEGLRegisterImage function fails with 801 error (not supported) if buffer have uyvy color format. If color format is yuyv - it works.

If I will store uyvy data in yuyv buffer NvBufferTransform will doesn’t work correctly and video encoding will unavailable.

How I can resolve this issue?

2

Hi,
Please make a patch on tegra_multimedia_api samples so that we can build, run the samples to reproduce the issue.

3

sorry for long reply. I made example based on 12_camera_v4l2_cuda.
Now I reproduced this issue on the 32.3.1 L4T version.

12_yuyv_cuda.cpp (4.9 KB)

When I run it with:

input_params.colorFormat = NvBufferColorFormat_YUYV;
// input_params.colorFormat = NvBufferColorFormat_UYVY;

I have this output:

./camera_v4l2_cuda
nvbuf_utils: Could not get EGL display connection
Detected 2 devices
INFO: prepare_buffers(): (line:77) Succeed in preparing stream buffers
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage done
cuGraphicsSubResourceGetMappedArray done
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage done
cuGraphicsSubResourceGetMappedArray done
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage done
cuGraphicsSubResourceGetMappedArray done
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage done
cuGraphicsSubResourceGetMappedArray done

When I use UYVY:

// input_params.colorFormat = NvBufferColorFormat_YUYV;
input_params.colorFormat = NvBufferColorFormat_UYVY;

I have this output:

./camera_v4l2_cuda
nvbuf_utils: Could not get EGL display connection
Detected 2 devices
INFO: prepare_buffers(): (line:77) Succeed in preparing stream buffers
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage failed: 801
cuGraphicsSubResourceGetMappedArray failed 400
cuGraphicsEGLUnRegisterResource failed: 400
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage failed: 801
cuGraphicsSubResourceGetMappedArray failed 400
cuGraphicsEGLUnRegisterResource failed: 400
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage failed: 801
cuGraphicsSubResourceGetMappedArray failed 400
cuGraphicsEGLUnRegisterResource failed: 400
NvEGLImageFromFd done
cuGraphicsEGLRegisterImage failed: 801
cuGraphicsSubResourceGetMappedArray failed 400
cuGraphicsEGLUnRegisterResource failed: 400

5

Hi,
On Jetpack4.5.1(r32.5.1), will hit the issue if the buffer format is UYVY:

NvEGLImageFromFd: Failed to create EGLImage from dma-buf fd (1056)

If your source format if UYVY, we would suggest convert to YUYV for CUDA postprocessing, and then convert to NV12 block linear for h264 encoding.

6

Hi, DaneLLL
May be, we didn’t try to use 32.5.1

Why egl and cuda can’t support uyvy? Is there so big difference from YUYV?
It looks like regression, because It was working in 28.2.1.

Using NvConvert usually takes about 3-5 ms, but sometimes it takes up to 15ms under load in our system.
So we don’t want to add one more conversion into processing pipeline, because it will significantly increase latency.

May be it is possible to make cuGraphicsEGLRegisterImage and NvEGLImageFromFd interpret UYVY as YUYV? We are using EGLImage only to pass dmabuf to CUDA and format of dmabuf doesn’t matter when we’re using this frame in CUDA

8

Hi,
The performance of VIC engine is not expected. Please try

  1. Run VIC engine at max clock
    Please refer to
    Nvvideoconvert issue, nvvideoconvert in DS4 is better than Ds5? - #3 by DaneLLL
  2. Create session for each task
    If you call NvBufferTransform() to do conversion/downscaling/cropping concurrently, we suggest create session by calling NvBufferSessionCreate() for each task. This should give better scheduling to VIC engine.

The issue is known and we are checking to fix it in future release. On current releases, we suggest convert to YUYV as a quick solution.

9

Looks like I can’t setup at max clock, because I don’t have these files. May be because we have flashed production fuses? I saw topic about bpmp clocks and production fuse.

I will try to use NvBufferSessionCreate and check performance.
But it doesn’t resolve problem with YUYV and UYVY support.

10

Hi,
We can see vic-related device nodes on a fused device. Please check again.
On r32 releases the solution is to convert to YUYV, do CUDA processing, and convert back to UYVY. Hardware converter VIC is fast and the conversion should be neglectable.