• ### Popular Now

• 13
• 18
• 19
• 27
• 9

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

## Recommended Posts

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 on other sites
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 on other sites
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 on other sites
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 on other sites
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 on other sites
Why not use parallel programming instead of concurrent programming?

##### Share on other sites
Quote:
 Original post by deksHi.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.