Fast Readbacks on Intel and NVIDIA

OpenGL OpenGL: Advanced Coding
17

I’m not sure what else to tell you. You’re just going to have to profile your app and determine where exactly the extra CPU usage is coming from (from what component). With that information, you then need to figure out what option(s) you have to reduce it, if any.

Just a few notes and suggestions for you to try:

  • Having a glBlitFramebuffer() in all this doesn’t serve any useful purpose unless you are rendering to a format besides GL_RGB565. For the case that you are rendering to GL_RGB565, just remove this needless overhead.

  • Did you ever try the export __GL_YIELD=USLEEP, just in case the extra overhead was in the GL driver twiddling its thumbs with a busy-wait? (Other possible options to try and compare against: export __GL_YIELD= and export __GL_YIELD=NOTHING

  • Try doing 2 glReadPixels() operations back-to-back (for different pixels in the FBO). Time each separately. If the 2nd takes significantly less time, it could be that the 1st glReadPixels() is including pipeline “flush” behavior, which could help explain some of your extra CPU usage.

  • Consider comparing the glReadPixels() timings and CPU usage against glGetTexImage().

  • A tip suggested by @GClements recently (LINK)… See if your NVIDIA Jetson Xavier NX platform supports one of the EGL lock surface extensions (EGL_KHR_lock_surface, EGL_KHR_lock_surface2, EGL_KHR_lock_surface3). From gpuinfo.org, apparently some NVIDIA Tegra platforms do. If so, it appears that you may be able to request that the graphics driver exactly match the RGB565 format you’re targeting with a specified byte order in an EGL surface it creates, as well as provide you a way to access the RGB565 framebuffer data directly without doing a glReadPixels(). If supported, that may be what you need to reduce CPU usage accessing the rendered pixel data.