Jump to content
  • Advertisement
Sign in to follow this  
lipsryme

Multithreading optimization for simple cpu render application

This topic is 2124 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

Hey guys basically what I've got is a rather simple application that creates a window and renders some geometry using the CPU.

Now I was wondering if I were to use multithreading for this purpose...which way would I best apply this to my application as I don't have anything like game logic or physics going on. It's just the main window app + cpu rendering. So I was thinking to split the rendering into a separate thread and then join them again at the end of the program...? Keep in mind I don't have a lot of experience in multithreading. Only done some producer/consumer type of thing before that's why I'm asking how to go about a window and a renderer (cpu that is). Main focus is performance.

 

Any help would be appreciated.

Edited by lipsryme

Share this post


Link to post
Share on other sites
Advertisement

The best way would be the same way as any other multi-threaded renderer.

 

The main thread fills a custom-made dispatch queue full of rendering commands, thread-safely swaps it, and then awakens the rendering thread with a signal.

Because of this, the rendering thread will not have been keeping a lock on the queue and the thread-safe swap will be with no overhead.

 

The rendering thread will then process each command in the queue and translate them to Direct3D or OpenGL API calls in order.  It is working on a swapped copy so the main thread is free to send more commands to the other render queue.

You could even triple-buffer the command queue if necessary to avoid stalls.

 

When the render thread is done it unlocks the swapped queue, which allows the main thread to send a new set of commands and to fill the previous buffer with new commands.  In a double-buffered system the only possible wait time is when the main thread wants to add commands to a queue that the render thread is using.  You can get around this by using more queues.  Triple-buffering, quad-buffering, sextuplet-buffering, etc.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

For multithreaded software rendering you want to split the screen up into pieces, and assign those pieces to threads. Any input data that is shared across multiple threads needs to be read-only, or be protected by a critical section (which is slow).

 

The simplest option is to split the image into scanlines, and use a thread pool to handle the allocation of those scan lines to threads. Writing your own thread pool isn't easy, so I'd suggest obtaining one from somewhere (TBB or PPL for example).

Share this post


Link to post
Share on other sites

Well I think the biggest part is the shading math involved. Shading every pixel of the geometry that is drawn.

And no there's no rasterization it's being drawn in screen space. Depth sorting yes. No frustum culling.

 

Tasks that fall under "render geometry": Loop through each object in an array -> calculate screen space position -> shade pixel and store it in the frame buffer

Edited by lipsryme

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!