Question about "PBO"

I found the “PBO” ext can speed up the I/O transfer rate,it is help of in my app,but I also have some questions:
-If I allocate many “PBO” objects(every pbo is 1024x1024*4 bytes,and allocate 10 or more objects),will it hurt the system performance?
-Can I write data to pbo in the thread that does not create it(means can I use “glMapBuffer”,“glUnmapBuffer”,“memcpy” in different thread)?If it is,does the different pbo can be written data in parallelly?
-Does the pbo’s data write & read can be executing in parallelly?

<mighty_confused> :confused:

  1. Obviously allocating 10 objects of 1024x1024x4 is gonna be a bigger overhead as compared to allocating just one object of that size.
  2. Are you sure, you are referring to PBO? The calls you gave are for VBOs i.e. Vertex Buffer Objects. In any case, you can use you can use the objects in multiple threads.
  3. I wouldn’t suggest doing that. If you are talking of PBOs then i think it could lead to stalls/crashes. The newer FBO extension explcitly calls for avoiding such scenarios. If you are talking about VBOs then it might be possible if you are not performing read/write operation on the same vertex data, but i have never tested it and don’t know for sure.
    </mighty_confused>

Uhmm, I think you confused pbuffers and PBOs (pixel buffer objects). The procs pango was writing about are used vor PBOs as well. Just think of them as of VBOs, but instead storing vertices, they just store pixel data…

AFAIK, you can’t use glMapBuffer and glUnmapBuffer in a different thread, but you can manipulate the mapped data in a different thread (for example memcpy).

PBO’s should allow the read/write operations to be performed asynchronously, if that’s what you mean. That is, the data manipulation calls (glBufferData, glUnmapBuffer, …) should return immediately, and the transfer is performed in the background. But it may be that the call that uses the data (for example glTexImage, …) will block if the transfer is not yet complete.

Thanks everyone,I had understood some questions for your reply,now below is the matter I want to know:

-Is the PBO’s buffer allocated in system memory?If it is,is it a burden to system that allocate many huge size PBO(such as 10 102410244bytes PBOs)?

-I use “memcpy()” to write data to different PBOs in different threads,then the copy operations can be running in parallelly?

As far as I know the PBO resides in a piece of memory called the AGP/PCI-E aperture. Which is a block of main memory that the graphics card uses as swap space. You can set the size of this in your system bios.

Yes, if you use memcpy in other threads you can write be many PBOs in parallel (along with doing other work).

Oringinally posted by HellKnight

Uhmm, I think you confused pbuffers and PBOs (pixel buffer objects). The procs pango was writing about are used vor PBOs as well. Just think of them as of VBOs, but instead storing vertices, they just store pixel data…

Ooops!!! Yeah i did. Sowwie :rolleyes:

It depends on what you mean by “burden” :wink:

PBOs can in theory be allocated anywhere, that is, on the graphic card, in AGP/PCI-E memory or in system memory (sorted by performance, access from GPU is fastest to graphic card memory, access from the CPU is fastest from system memory).

Of course if you try to allocate more PBOs than you have memory available, they will have to be stored in the next slower type of memory (worst case being on disc swap space :stuck_out_tongue: ), so in that sense allocating many large PBOs will be a burden for the system.

Thanks everyone,now I think out an optimization scenario for my app using “PBO”,but before I implement it,I must understand below questions:

-How much size the “PBO” can I allocate?If I allocate more “PBO”,or the size of “PBO” is too huge,what effect will happen?My program will crash,or the transfer speed through AGP/PCI-E slow down markedly?

-Which factors decide the biggest memory size “PBO” can allocate?System memory size?Display memory size?or others?