FBO=>PBO transfer, glMapBuffer is impossibly slow

OpenGL OpenGL: Advanced Coding
1

Hi, happy new year 2011!

I write OpenGL application (MS Windows, for now). I sometimes need to read data from frame buffer object (FBO - GL_BGRA, 32x32 pixels, every 200 ms.). But glMapBuffer blocks application approx for 60-100 miliseconds! Before writing this post, I have read great many forums, websites etc…without success.

here is proces of rendering:

  1. bind FBO
  2. render to FBO
  3. bind PBO
  4. glReadPixels(0, 0, m_Width, m_Height, GL_BGRA, GL_UNSIGNED_BYTE, NULL); // this works fine, no blocking, async reading starts ok…
  5. unbind PBO
  6. unbind FBO

Then I render some other things and wait several frames (1, 2 and 3 frame waiting tested).

And finally I read from PBO data:

  1. bind PBO
    2) glMapBufferARB(GL_PIXEL_PACK_BUFFER_ARB, GL_READ_ONLY_ARB)
  2. …doing something with data
  3. unmap buffer

(2) blocks application about 100 miliseconds. Without reading data from FBO, application is quite fast… < 20 msec. BUT! When I disable some features related to FBO - shadow mapping for example - step (2) lasts about 40-60 msec, that is fewer, but still lot for 32x32 px texture.

I have AMD Opteron 1.8GHz, 1GB RAM, ATI X1600 with leatest drivers, Windows XP SP3.
Notice, that FBOs are strange on this graphic card, or is strange my code…when I use FBOs (3 full-screen for example), explorer.exe eats processor time (~10%), which causes performance peaks, when I kill explorer.exe, everything is ok.

Do you have any idea…?

thank You

2

I have AMD Opteron 1.8GHz, 1GB RAM, ATI X1600 with leatest drivers, Windows XP SP3.

I think the issue is NOT your code, but the ancient ATI X1600, that card came out in Oct 2005, now 5 years ago… that chip’s drivers are “legacy display drivers”, I highly suspect that such drivers are not, err, at the top of the list for love from ATI/AMD. Having dealt with some ATI Mobility Xxxxx cards myself, I was horribly underwhelmed by their GL (however new ATI cards: read 4xxx and 5xxx) have much better GL support.

As an alternative, you can try glGetBufferSubData to read the values (since you are mapping with GL_READ_ONLY_ARB), but I would not get one’s hopes up too much.

Another desperate idea: do NOT wait several frames before reading the buffer data, rather read the buffer data just after unbinding the FBO… this is a desperation measure (and I highly suspect it won’t help, but it cannot hurt to try).

BUT! When I disable some features related to FBO - shadow mapping for example - step (2) lasts about 40-60 msec, that is fewer, but still lot for 32x32 px texture.

How big is the buffer object (i.e PBO)? [i.e. how many bytes do you make it when you first call glBufferData?]… glMapBufferARB has to map the entire buffer object… and since you are asking for read back access… if the range is huge, it could get ugly underneath.

3

Thank You for reply, I will try test my application on other machines. Maybe, is this “new render style” with lot of screen space oprerations, FBOs, etc…too heavy load for ATI X1600 :slight_smile: