DwImageCUDA - direct data access

Autonomous Vehicles DRIVE AGX Xavier DRIVE AGX General
,
#1

Dear nvidia-Team,

I am having problems accessing a dwImageCUDA’s data in RGBA_UINT8 pitch configuration. The problem does not occur with RAW_UINT16.
I am aware that I cannot access the data from host directly, but copying any data from dptr[0] does not work, neither by cudaMemcpy (as it works for the RAW_UINT16 case) nor by cudaMemcpy2D, neither to device nor host. Both give error 700, which is Illegal Memory Access. It does not matter if I try for a subspace of the data or even only the first byte.

The image gotten from the camera gives all the right infos as far as I can see.

Format: 1012 (RGBA_UINT8)
Dimensions 1920x1208
Memory type 1 (Pitch)
Image type 2 (CUDA)
Element size 1
Number of Planes 1
Channels 4
Plane size 1920x1208
Pitch[0]: 7680
dptr[0] has a value, the others do not, neither does array[0]

Copying the data from RAW_UINT16 works with
the call
cudaMemcpy(dst, frame->dptr[0], 1920x1208x2, cudaMemcpyDeviceToX),
but not for RGBA_UINT8 with e.g.
cudaMemcpy(dst, frame->dptr[0], 1920x1208x4, cudaMemcpyDeviceToX) or
cudaMemcpy2D(dst, dstPitch, frame->dptr[0], frame->pitch[0], 1920x1208x4, cudaMemcpyDeviceToX)

I also tried dwImageStreamer as a converison tool to dwImageCPU (just for test purposes), but it crashes on the producerSend step without an error message.

I am starting the camera with the following parameter string:
output-format=yuv,isp-mode=yuv444-uint8,camera-type=ar0231-rccb-bae-sf3324,camera-group=a,slave=0,camera-mask=1000,camera-count=4,mode=mailbox

RAW_UINT16 has the following changes:
output-format=raw+data,camera-type=ar0231-rccb-bae-sf3324,camera-group=a,slave=0,camera-mask=1000,camera-count=4,mode=mailbox

Alternatively, I would also be happy with a performant transformation of the raw uint16 image to rgba_uint8, though I think having the driveworks function taking that processing step directly when grabbing the frame should be the most optimal path.

Please provide the following info (check/uncheck the boxes after creating this topic):
Software Version
DRIVE OS Linux 5.2.6
DRIVE OS Linux 5.2.6 and DriveWorks 4.0
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other

Target Operating System
Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.7.0.8846
other

Host Machine Version
native Ubuntu 18.04
other

#3

Hi, @josua.zscheile
Which Camera protocol are you using? camera.gmsl?

#4

Dear Vick,

yes, I use camera.gmsl

#5

Dear @josua.zscheile,
dptr[0] has a value, the others do not, neither does array[0]

As it is single planar with pitch linear memory only dptr[0] array is expected to have data.

I see you have used cudaMemcpy2D(dst, dstPitch, frame->dptr[0], frame->pitch[0], 1920x1208x4, cudaMemcpyDeviceToX). The cudaMemcpy2d signature seems to be different here.

#6

Dear @SivaRamaKrishnaNV,

you are right, this was an error of me copying the memcpy call (since I altered the variable names for clarity) into the forums. I used it correctly with width and height separately as intended.

#7

Dear @josua.zscheile,
Could you share the used cudaMemcpy2d() call with parameters?

#8

Sure.

cuError = cudaMemcpy2D(dstPtr, dstPitch, frame->dptr[0], frame->pitch[0], 1920/* *4*/, 1208, cudaMemcpyDeviceToDevice),
where

  • dstPtr is of type void*, and allocated with cudaMallocPitch for 1920*4 width and 1208 height
  • dstPitch is a size_t and the pitch (7680 as expected) from the malloc call
  • frame is the the dwImageCUDA*, that got its content by dwImage_getCUDA from the frameHandle of the frame from the camera. It has the right properties as outlined above
  • as you see I have tried both 1920 and 1920*4 as width.

As I already said I also tried with transferring the data to host instead, no success.
I get the feeling that it somehow has to do with the configuration for the camera access (as in the parameters above).

#9

Do your parameters work well with sample_camera_gmsl application?

#10

That would be -isp-mode=yuv444-uint8, and yes, that works.

#11

Didn’t you see the issue with sample_camera_gmsl application?

#12

No, there was no problem with that.
It seems to me that the image is created normally by the driveworks function (as evidenced by the image property values) fetching it from the camera, but for some reason the data is corrupted, so whenever I try to access it in any way, it gives the error.

#13

Please clarify the difference between sample_camera_gmsl and your application.
hope you can figure out the problem from it.