Sign in to follow this  
supagu

multithreading software renderer

Recommended Posts

supagu    148
i have a software renderer that i want to multithread. I've asked this question on gamedev before but people suggested diving the frame buffer up. I gave up once i heard this, but now i'm interested at looking at this again. my initial idea was to simply split the geometry in to parts and let a thread hand the vertex transform and rasterisation of each part. This seemed to work fine although i saw no performance gain in a dual core cpu. so im wondering how the dividing the frame buffer up works, isnt more work involved in calculating what sectors of the frame buffer the triangles fall in? do you clip the triangles to each portion of the frame buffer?

Share this post


Link to post
Share on other sites
Antheus    2409
Your buffer is (w,h) rectangle. For purposes of rendering your scene data, and everything else is read-only.

With n threads, you render bands, each h'=h/n high. So with 2 threads, one thread renders 0..h', and other renders h'+1..h.
+------------------+ 0
| Thread 1 |
+- - - - - - - - - + h'
| Thread 2 |
+------------------+ h

This can typically be accomplished with minimal code modification, since the renderer remains virtually unchanged, single-threaded, it just renders smaller area.

Share this post


Link to post
Share on other sites
DirectXFreak    166
I'm also writing a software renderer that originally intended it to be single threaded. However, this intrigues me. So, would the main thread clip the triangles each surface and send those polygons to each rasterization thread?

Share this post


Link to post
Share on other sites
Basiror    241
you don t split the triangles that cross the boundary, you can design you rasterization algorithms in a way that you only rasterize the parts of a triangle that are part of your half of the framebuffer

this can be done easily when inserting the edges into the edge table

Share this post


Link to post
Share on other sites
deks    209
Hi.

It looks like the best way to multi-thread a software renderer is to use the edge function instead of the traditional scanline algorithm. See the paper "A parallel algorithm for Polygon Rasterization" from Juan Pineda (1988). The implementation is well explained in this post. Then, each block can be assigned to a different thread for rendering them simultaneously.

JF

Share this post


Link to post
Share on other sites
Basiror    241
Quote:
Original post by deks
Hi.

It looks like the best way to multi-thread a software renderer is to use the edge function instead of the traditional scanline algorithm. See the paper "A parallel algorithm for Polygon Rasterization" from Juan Pineda (1988). The implementation is well explained in this post. Then, each block can be assigned to a different thread for rendering them simultaneously.

JF


I don t see how this algorithm shall be faster than a scanline algorithm with and Edge table and an active edge table where you only touch the fragments that shall be rendered using the bresenham algorithm, implemented to use integer arithmetic only.

Using the bresenham algorithm you only check one condition per pixel, the loop termination condition.

And you can easily make the scanline algorithm parallel if you split up the screen into dynamic sections, e.g.: balance the threads in a way that areas with high overdraw are split into smaller portions than areas with less overdraw.



Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this