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.

TDA2SX: It takes too long to call API in OpenGL

Part Number: TDA2SX
We want to read the rendered image back to memory from the video memory through the "glreadpixels" function in OpenGL; When we use this function to read an image with a resolution of 360 * 400, we find that the execution time of this function is about 450ms, which is obviously abnormal. Therefore, we would like to ask what problems may cause the execution time of this API to be so long? What is the normal execution time of this API?
  • Now, instead of calling "glreadpixels", we only perform the rendering operation, which takes about tens of milliseconds; Rendering + calling "glreadpixels" takes about 450ms; It is proved that "glreadpixels" takes at least 300 ms. I would like to ask within what time range the approximate execution time of glreadpixels should be considered normal without considering pending. Should more than 300 ms be far beyond the normal range? When we call "glreadpixels" on other platforms where GPU performance is not as good as TDA.

  • Besides pending, what factors affect the timing of glreadpixels? What are some ways to optimize this time? Is there any other more efficient way to get rendered images from video memory, such as memory sharing?

  • Hello,

    glReadPixels would have to finish rendering everything till the point of the function call - including previous frames if any thus loosing parallelism. Ideally, you would want to render to an offscreen EGLImage and then use fences to wait on GPU operation to complete and then read the memory.

    Also, it might be worth using PVRTune for SGX to profile the GPU rendering to identify any bottlenecks. 

    developer.imaginationtech.com/.../

    Regards

    Hemant

  • Is there a better way to replace glreadpixels? If so, can you provide a code demo?

  • Supplementary note: we bound FBO before calling glreadpixels; We first render the image off screen to FBO, and then read the image from FBO through glreadpixels. This operation takes about 450ms, and the 450ms is fixed. It will not take different time because the size parameters passed when I call glreadpixels (there will be a parameter to read the image size in glreadpixels. Theoretically, the smaller the parameter, the fewer pixels will be read and the less time will be spent).Now we have tried to call glreadpixels to read without binding FBO. The whole time is much less. It only takes about 100ms to read a 360 * 400 image. If the read image is reduced, the time will be less. But now this time-consuming still can not meet our needs. In theory, reading images on FBO should be faster, but now it is slower, so I think this is the problem. Why does glreadpixels become abnormal after binding FBO?

  • Hello Huan,

    Please note that when you call glReadPixels it has to finish every command submitted and render to the buffer. The time is not just reading time but also the time needed to finish rendering. This is why it does not matter. The best thing to do would be to optimize the rendering to not take as long as it may be taking. As an experiment, you can try glFinish instead of glReadPixels and see if that is much quicker.

    Regards

    Hemant

  • I know that calling glreadpixels will include the rendering time. I have excluded the rendering time. I only measured the time of glreadpixels after calling glfinish, which is 450ms. I can confirm that it has nothing to do with rendering. Moreover, as I mentioned above, the time will be much faster without FBO, which is also an evidence of the problem of calling glreadpixels in FBO.

  • Hello Huan,

    I believe you might be better off with creating an offscreen surface using EGLImage. You can look at the solution here:

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/769511/linux-tda2pxevm-offscreen-gpu-rendering-to-userspace-mapped-buffer

    Regards

    Hemant