CPU-GPU balancing
Author
I have a few questions on performing parallel operations on the GPU and CPU.
One part of my application is very computationaly expensive, taking maybe 10-15 seconds. The results are then stored in a texture.
To avoid having to wait this entire time at startup I am considering doing the following:
* Start app. without "expensive" step.
* Render using simpler mode
* In background, while rendering, compute stuff (CPU)
* When stuff is computed, fill and set texture
* Continue render in advanced mode
Since I want to compute while rendering at the same time I guess I need to use multithreading. Or?
If my computations were reasonably fast I guess I could do them between frames (serially).
But since this is one huge op I guess this is out of the question?
So, is multithreading the only/right way to do this?
Are there any limitations/special considerations when doing D3D and multithreading?
Is there maybe some helper stuff in DirectX that can ease my pain?
Any links or pointers to articles in this topic?
Normally you would not need to think about multithreading. The calls to render things can return immediately, allowing the CPU to do it's work, and the GPU can execute the commands later. However, since you are doing such a long calculation, I'm afraid multithreading is the only way. You still have to tell the GPU what to do every frame, and you can't do that while you are locked up in an expensive loop.
If it's difficult/impossible to split your operation into smaller pieces that can be calculated each frame, then yeah, multithreading sounds like the way to go.
Judging from your situation, I don't think that the multithreading will cause too much complexity, and should work perfectly fine with DirectX, assuming you don't do anything downright stupid. Of course, if you're new to multithreading, I suppose that doing some stupid is very likely. I know it was with me. [smile]
You'll probably want to be looking at MSDN's Processes and Threads Reference. Mainly, I could see you starting a thread with CreateThread(). Then, once every frame, you would call WaitForSingleObject(), with a handle to the thread you created as the first parameter, and a timeout value INFINITE. If the return value is WAIT_TIMEOUT, then the thread hasn't completed yet. If the return value is WAIT_OBJECT_0, however, the thread is done, and you can use the texture that was created. (Don't try using the texture before this point, of course.) Don't forget to call CloseHandle() on the thread handle at that point.
Judging from your situation, I don't think that the multithreading will cause too much complexity, and should work perfectly fine with DirectX, assuming you don't do anything downright stupid. Of course, if you're new to multithreading, I suppose that doing some stupid is very likely. I know it was with me. [smile]
You'll probably want to be looking at MSDN's Processes and Threads Reference. Mainly, I could see you starting a thread with CreateThread(). Then, once every frame, you would call WaitForSingleObject(), with a handle to the thread you created as the first parameter, and a timeout value INFINITE. If the return value is WAIT_TIMEOUT, then the thread hasn't completed yet. If the return value is WAIT_OBJECT_0, however, the thread is done, and you can use the texture that was created. (Don't try using the texture before this point, of course.) Don't forget to call CloseHandle() on the thread handle at that point.
I don't recommand you multithreading for GPU/CPU balancing.
OpenGL & DirectX are allready doing the work for you.
When you are calling a DrawPrimitive, you are not going to draw the polygones now, but you are pushing your orders in a FIFO stack. The parralelism can be broken if an order need something which hasn't been yet computed. The GPU is then stalled.
Here a classic exemple :
- Present
- Update animation
- Draw primitives
- Present
...
When the animation are updated, the GPU is waiting.
Try this:
- Present
- DrawPrimitives
- Update animation
- Present
...
When the animation are updated, the GPU is drawing the primitive which are in the FIFO!!
A good parallelism is achevied this way.
You can check on the NVidia developper site, they have tools (NVPerfHUD) which can greatly help you to make a good parallelism.
OpenGL & DirectX are allready doing the work for you.
When you are calling a DrawPrimitive, you are not going to draw the polygones now, but you are pushing your orders in a FIFO stack. The parralelism can be broken if an order need something which hasn't been yet computed. The GPU is then stalled.
Here a classic exemple :
- Present
- Update animation
- Draw primitives
- Present
...
When the animation are updated, the GPU is waiting.
Try this:
- Present
- DrawPrimitives
- Update animation
- Present
...
When the animation are updated, the GPU is drawing the primitive which are in the FIFO!!
A good parallelism is achevied this way.
You can check on the NVidia developper site, they have tools (NVPerfHUD) which can greatly help you to make a good parallelism.
Author
Ronan: Is this useable in my case as well?
For the first frame, render gets called (added to GPU worklist stack).
Then the CPU begins chewing on my 15 second number crunch.
When completed, the next render is called (and added to GPU worklist).
How can the GPU be kept active during the 15sec crunch, when I can't feed it with new render calls (unless I multithread)?
Or have I misunderstood your post?
For the first frame, render gets called (added to GPU worklist stack).
Then the CPU begins chewing on my 15 second number crunch.
When completed, the next render is called (and added to GPU worklist).
How can the GPU be kept active during the 15sec crunch, when I can't feed it with new render calls (unless I multithread)?
Or have I misunderstood your post?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
