🔒 Locked 🎮 Unity

multithreading software renderer

Started by supagu Aug 12, 2008 at 5:30 AM 5 replies 1.2k views

Original Post

Aug 12, 2008 at 5:30 AM

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?

Antheus

216

Antheus

Aug 12, 2008 at 10:03 AM

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.

DirectXFreak

Aug 12, 2008 at 1:01 PM

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?

Basiror

140

Basiror

Aug 12, 2008 at 2:20 PM

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

deks

Aug 12, 2008 at 2:26 PM

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

stonemetal

Aug 12, 2008 at 2:42 PM

Why not use parallel programming instead of concurrent programming?

Basiror

140

Basiror

Aug 13, 2008 at 3:06 AM

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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.