• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 104 subscribers
  • Views 2552 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DRA756: How to load imags from GPU's framebuffer to ARM's memory quickly?

user4684340
Intellectual 290 points
Part Number: DRA756

I use SGX 544 GPU to render a 3d sence, then I want to get the rendered images from GPU to ARM's memory. So I use glReadPixels to read images from GPU's framebuffer. But glReadPixels taks 200ms to get one frame. Is there another way to read images from GPU's framebuffer(shared memory or other ways)? 

By the way my framebuffer's size is 1280*720.

  • 0
    TI__Intellectual 1285 points
    Hi,

    The question has been forwarded to a GPU expert.

    Best regards
    Lucy
  • 0 in reply to user4684340
    TI__Expert 5130 points
    Hi,

    Yes, glReadPixels is very slow since it involves a copy. Which SDK are you using?

    If you are using Processor SDK Linux Auto 3.02, you have an option to create a DMABUF FD and import it to a GBM BO using gbm_bo_import function. After this, you can use it as GBM Pixmap surface for rendering.

    Regards,
    Anand
  • 0 in reply to Anand Balagopalakrishnan
    Intellectual 290 points

    Hi, thanks for the reply. We are using VISION_SDK_02_09_01_00, so we need to upgrade to Processor SDK Linux Auto 3.02. Is that right?

    Best regards,

    Mason Su

  • 0 in reply to Anand Balagopalakrishnan
    Prodigy 70 points
    Hi Anand,

    Thanks for the reply. I don't think my colleague made it quite clear in the last post.

    What we were trying to do was to get the texture out of the frame buffer and then encode it in H264 format for further use. I am not sure whether we are on the right track.

    The SDK version we are using is VISION_SDK_02_09_01_00. Do you have any suggestions for this SDK?

    Regards,
    Matt
  • 0 in reply to user4684340
    TI__Expert 5130 points
    Hi,

    Yes, I think you should move to Vision SDK 3.x which supports Processor SDK Linux Auto 3.02. The existing Surround View demos on K4.4 already use this option for importing a DMABUF.

    Essentially, you don't read from a GPU buffer. Create a DMABUF, map it as a Pixmap and render to it. Since the DMABUF was supplied by the application, there is no need to use glReadPixels(). The application already has the framebuffer mapped in its address space.

    Regards,
    Anand

    PS:
    Since you are using Vision SDK, should this post go to TDA forum?
  • 0 in reply to Anand Balagopalakrishnan
    Intellectual 290 points

    So DMABUF is ARM's memory, is that right? Then I can use this meory to encode the rendered imaged to H.264 format video. Beacause I need to send this video to another device and dispaly the video on that device in real time, so the speed is the key point. Do you know how long it will need to render one fame (1280X720) on this DMABUF?

    Best regards,
    Mason Su

    I think this thread can go to TDA forum.

  • 0 in reply to user4684340
    TI__Genius 13395 points

    Hi

    As Anand suggested please move to Vision SDK 3.0, where we already have one usecase almost matching your requirement.

    refer the one under \vision_sdk\apps\src\hlos\adas\src\usecases\avbrx_sv_display_avbtx

    This does the 3D SRV rendering on SGX then does a DSS M2M write back to convert the data format from ARGB32 to YUV420 (IVA encoder support only this format), then H264 encode and stream out using AVB Tx.

    The buffer for rendering is allocated from IPU space (shared memory) and provided to GPU hence no frame copy is required.

    regards, Shiju

  • 0 in reply to user4684340
    TI__Expert 5130 points
    To answer the previous question, yes, DMABUF is a feature provided by Linux kernel. As such, this memory is owned by ARM Cortex-A15. Since the GPU uses entire DDR address space (NUMA architecture), this can be accessed by GPU.

    Application allocates DMABUF using a driver that is capable of exporting a DMABUF. On J6, omapdrm driver supports buffer allocation that can be exported as a DMABUF.

    In the VisionSDK use case, we are taking an M4 allocated buffer and wrapping it as a DMABUF. This may not be exactly required for your use case - you can just use omapdrm to allocate a DMABUF.

    Even so, you can use the ARM side code pointed by Shiju to refer how a DMABUF can be mapped as GPU render surface.

    Regards,
    Anand
  • 0 in reply to Anand Balagopalakrishnan
    Intellectual 290 points
    Thank Shiju and Anand for detailed replies for this question. Now my colleagues are trying to use Vision SDK 3.0 from VISION_SDK_02_09_01_00. For my understanding, we need to use new kernel and modify our boot enviroment. So we will need sometimes before we can use new DMABUF. Then I will give you some updates after we test DMABUF.

    Thank you.

    regards,
    Mason Su