This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VE-Q1: sdk8.5 vxSwapImageHandle

Part Number: TDA4VE-Q1

Hi team,

The customer has successfully implemented zero copy using vxSwapImageHandle function in 7.3 SDK. Currently switching to 8.5 SDK and using the vxSwapImageHandle function has the following problems: 

1) In 8.5 SDK, the physical addresses of the y component and the UV component of the nv12 format image are contiguous, so an image can only be converted to ONE DMA FD. 

2) The arguments to vxSwapImageHandle are virtual addresses, and an image in nv12 format under 8.5 SDK has only one virtual address since there is only one DMA fa. However, two virtual addresses are required in the arguments of vxSwapImageHandle (the virtual address of the y component and the virtual address of the UV component). 

Could you help look into these 2 questions? Thanks.

Best Regards,

Cherry

  • Hi,

    May I know is there any updates?

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Sorry for the delay in the response.

    In 8.5 SDK, the physical addresses of the y component and the UV component of the nv12 format image are contiguous, so an image can only be converted to ONE DMA FD

    Let me check regarding this change internally.

    But from the vxSwapImageHandle() , this takes in the argument num_planes. Here, this is the number of planes in the image.

    This must be set equal to the number of planes of the input image.

    I think, this should take care of both Y and UV plane.

    May I know what is the error that you are facing currently?

    Regards,
    Nikhil

  • Hi Cherry,

    Follow-up question on the same.

    I see that the single plane implementation is already present in SDK 7.3.
    Could you please confirm if the customer is on SDK 7.3 and they have implemented zero copy on SDK 7.3?

    If yes, then they should have the latest changes with them.

    Regards,
    Nikhil

  • Hi Nikhil,

    Thanks for your support.

    I see that the single plane implementation is already present in SDK 7.3.

    For nv12 image, the argument num_planes=2 passed when the vxSwapImageHandle function is called in SDK7.3. Dose "Single plane" refer to num_planes be equal to 1 for nv12 image? 

    May I know what is the error that you are facing currently?

    1) The image for nv12 has two planes(Y and UV), and when the customer calls the vxSwapImageHandler function, the incoming argument num_planes=2 corresponds to an image in nv12 format. However, there is only one virtual address, so the function call will go wrong. 

    2) Why is the physical address of y plane for nv12 type image created in SDK 7.3 separate from the physical address of UV plane? While the physical address of y plane for nv12 type image and the physical address of UV plane created in SDK 8.4 are contiguous?

    Could you please confirm if the customer is on SDK 7.3 and they have implemented zero copy on SDK 7.3?

    Yes, zero copy was previously implemented on SDK 7.3. Now they are using SDK 8.4 and want to implement the same zero copy, but it is hard to continue with the above issues. 

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Is there some testcase or conformance test that the customer is running with which we could try to reproduce this issue at our end?

    Regards,
    Nikhil

  • Hi Nikhil,

    Their program is not a testcase for the system, it is a function code written by the customer.

    You could check the physical address of the image according to the tivxReferenceExportHandler function and the tivxMemTranslateVirtAddr function.

    Thanks and regards,

    Cherry

  • Hi,

    May I know is there any update?

    Thanks and Regards,

    Cherry

  • Hi Cherry,

    Sorry for the delay.

    Let me brief you the difference between the previous implementation and current implementation.

    Previous Implementation (Before SDK 7.3) 

    - When you allocate the buffer for a Multi-planar image (like NV12, plane = 2), we call MemBufferAlloc twice (once for each plane). Hence, in this case, the memory allocation may or maynot be contiguous.

    Current Implementation (From SDK 7.3 onwards)

    When you allocate the buffer for a Multi-planar image (like NV12, plane = 2), we call MemBufferAlloc only once (for the first plane host_ptr[0]), but we fill the host_ptr[1] too with an address based on host_ptr[0] + size [0] .

    Hence, there still would be 2 addresses available to swap when this image is passed through a vxSwapImageHandle.

    Now this would be the scenario when the image is created using vxCreateImage() and not from any Handle.

    In case of creation of image from handle, there is no change as the buffers are allocated by the user.

    The image for nv12 has two planes(Y and UV), and when the customer calls the vxSwapImageHandler function, the incoming argument num_planes=2 corresponds to an image in nv12 format. However, there is only one virtual address, so the function call will go wrong

    In this case, there won't be an error in the function as we still have 2 addresses available because of "fill the host_ptr[1] too with an address based on host_ptr[0] + size [0] "

    Also, from the code changes from the SDK, I do not see a change from SDK 7.3 to SDK 8.5 regarding this aspect.

    The change was from SDK 7.2 to SDK 7.3 as per the code in the SDK.

     

    Could you please share some error logs or provide more details on the customer usecase?
    Like how are the images created and how is it being swapped etc.?

    Regards,
    Nikhil