Jump to content
  • Advertisement
Sign in to follow this  
brucile

OpenGL efficiency of combining CPU and GPU by multiple threads

This topic is 4625 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want to know the efficiency of combining CPU and GPU by multiple threads. The idea is that, when CPU performs some computation(has nothing to do with thread), a thread will run a complex shader on GPU( this shader has many math calculation and texture access, it takes 0.008 seconds to finish on my computer:WinXP,Nvidia Quadro FX1000). Below is the pseudo-code for the thread ; Thread(){ initGlew(); initGlut(); initOpenGL(); while(1){ DownloadDataToGPU();// 48 bytes long data DrawQuad(); //a pixel shader with math compute and texture access. glFinish(); ReadBackData(); //using glReadPixel() } } I run many test instances, it seems that by using such kind of multiple thread, the CPU will slow down by 15%. Calling of glFinish() consumes most of the time. My question is, when calling glfinish(), GPU should begin to work and the thread should be blocked, so that control is given to CPU. In this way, calling of glFinish() shouldn’t cost too much time. Any hints for me ?

Share this post


Link to post
Share on other sites
Advertisement
First of all, you shouldnt need glFinish at all. When you do the readback gl will make sure that all needed operations are already performed.

Second, it really kills parallelism between CPU/GPU to use glFinish. glFinish means that the CPU should stall and wait for GPU to finish performing all your commands. Unless DownloadDataToGPU needs the result from ReadBackData right away I think you could get much improved performance by using PBOs instead of a plain glReadPixels and just remove the call to glFinish.

Quote:
From the PBO spec:

Asynchronous glReadPixels: If an application needs to read back a
number of images and process them with the CPU, the existing GL
interface makes it nearly impossible to pipeline this operation.
The driver will typically send the hardware a readback command
when glReadPixels is called, and then wait for all of the data to
be available before returning control to the application. Then,
the application can either process the data immediately or call
glReadPixels again; in neither case will the readback overlap with
the processing. If the application issues several readbacks
into several buffer objects, however, and then maps each one to
process its data, then the readbacks can proceed in parallel with
the data processing.

(see Example 3 at the bottom of the document too).

Share this post


Link to post
Share on other sites
Sorry, I have made more experiments, it seems that glReadPixel() is the bottleneck. it consumes 5/6 of overhead time introduced by thread. I should swtich to PBO.

Is there any other ways to speedup readback ?

Share this post


Link to post
Share on other sites
It is possible that some pixel formats will perform better than others, you would have to experiment to find out the best one for you.

Share this post


Link to post
Share on other sites
I read specification of PBO, it seems I have to combine PBO with Pbuffer or FBO. otherwise, if I render to frame buffer, the value will be clamped into 0,1.
is it correct ?

Share this post


Link to post
Share on other sites
That is true. If you need values outside 0,1 you either have to render to a floating point texture, or be clever and pack your float result into the normal RGB components. I have never done that myself, but unless you are targeting old hardware I would just go with a fp texture for simplicity.

I really recommend going with FBOs instead of pbuffers. A lot easier to work with and more efficient. Just make sure you have updated drivers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!