How to use multithreading in 3D software renderer to speed up fetching texture values

Question

The biggest bottleneck of my code is fetching texture RGB values from memory.

My code looks something like this:

game loop{
    for every mesh{
        perform clipping;
        for every 3 verticies in mesh {
            draw triangle {
                interpolate texture coordinates;
                fetch texture RGB and place value in backbuffer;
            }
        }
    }
}

Fetching the texture RGB value from memory takes up so much time!!

I am not familiar with multithreading but I'm assuming there is some way to apply it here. Let me know what suggestions you have and how I should go about doing this!

How are you currently accessing memory? Can you share code for that? — aces, Jul 20 '17 at 03:58
This topic is big enough that books have been written on it. To get a good answer, you need to [edit] your question and make it more specific. But your software rasterizer will always be orders of magnitude slower than using OpenGL or DirectX. — Dan Hulme, Jul 20 '17 at 08:21
@aces The backbuffer I write to is the buffer of the screen. It is represented as 3 chars for RGB in sequential order. I call it "ibuffer". The texture RGB values are stored in an integer array where each integer is the chars RGBA.
[code] ibuffer = mesh->texture->intbuffer[(int)textureX + mesh->texture->width (int)textureY]; [\code]

The integer I copy from the texture to the backbuffer overwrites the R value of the next pixel in the back buffer. I do this so as to not use bitwise operations used to extract the RGB values from texture memory and store in backbuffer. — Benjamin Loisch, Jul 20 '17 at 16:05
A minor optimisation would be to use powers of 2 for your texture size, so you can compute the offset using a logical shift. E.g. if you have a 256 pix wide texture you can compute the texel offset with "U + V << 8". Also pad your RGB structure to 4 bytes instead of 3 so the compiler can apply a similar optimisation to the array indirection. You can also apply texture wrapping trivially if power of 2 size e.g. (U & 255) + (V & 255) << 8 — PaulHK, Jul 21 '17 at 03:55
@PaulHK I will try that Paul. Compared to my original statement, I found if I access the same texel for all interpolated pixels (*ibuffer = mesh->texture->intbuffer[10000]), the program framerate increases by 3 to 4 times. Do you have any idea why? — Benjamin Loisch, Jul 21 '17 at 16:42
Using a constant index makes the address calculation a lot simpler, the compiler will calculate 1 pointer outside of your loops as opposed to recalculating it each pixel because it is using a none-constant index. Also accessing the same memory location will ensure it's in the CPU cache so you will get massive performance boost from that. — PaulHK, Jul 22 '17 at 10:12
@PaulHK In my innermost for loop I am iterating over the pixels in the triangle and fetching the appropriate texels in a 1D array and storing in the back buffer: for all pixels in triangle *ibuffer = mesh.texture.intbuffer[texcoord];
If my texture is allocated on the heap, and the texture is being accessed vertically... I do not understand how the cache is filling up with unecessary values. I suppose if I tiled my texture, the cache would guess the next values and store them in registers and since it's tiled, those values would more likely be the correct ones to use. — Benjamin Loisch, Jul 24 '17 at 22:41

Simon F · Answer 1 · 2017-07-21T08:45:34.500

It could be that you have to overcome a different bottleneck first.

Have you ever read Jim Blinn's "The Truth About Texture Mapping"? (I had a quick search to see if I could find a non-paywalled version but you may have better luck than me. Alternatively you might find a dead tree version of "Jim Blinn's Corner" in a library). Though this article is old and describes paging of texture data, it is still very relevant today.

Essentially, if your textures are large (i.e. too large to fit in the cache), in scan order, and they have been rotated when displayed on the polygons, you are very likely to be thrashing your cache and, as memory is an order or two of magnitude slower than the CPU, this will hurt performance.

To avoid the cache thrashing, textures are often stored in twiddled-order (that's what we called it in the early 90s but, more correctly, it'll be some variant of Morton order) or in a block order, which is what Blinn describes. This then makes texel/memory accesses far more coherent and the cache more effective.

Mip mapping is also a good strategy to improve cache coherence in texture mapping. — Stefan Werner, Jul 20 '17 at 13:26
@Stefan Indeed. Texture aliasing is painful in multiple ways :-).
There's a bit more on the subject here: https://computergraphics.stackexchange.com/questions/357/is-using-many-texture-maps-bad-for-caching/419#419 — Simon F, Jul 21 '17 at 08:42

score 2 · Answer 2 · answered Jul 20 '17 at 08:34

This is rather general programming question but parallelizing for loop (most common usage) in c++ is easy with openMP library. Basic example for parallelizing outer loop:

#pragma omp parallel for schedule(static, 1) num_threads(omp_get_num_procs())
for (int i = 0; i < size1; ++i)
{
    for (int j = 0; j < size2; ++j)
    {
        buffer[i*size1 + j] = ...
    }
}

But because of thread race situation below (incrementing array index) which would work in single thread wouldn't work in parallel:

int it = 0;
#pragma omp parallel for schedule(static, 1) num_threads(omp_get_num_procs())
for (int i = 0; i < size1; ++i)
{
    for (int j = 0; j < size2; ++j)
    {
        buffer[it++] = ...
    }
}

Also thing to consider is using SIMD instructions (Single Instruction Multiple Data) which optimize multiple operations to single CPU instruction:

#pragma omp parallel for simd schedule(static,10) 
for (i=0; i<N; i++) 
{ 
    a[i] = b[i] * c[i]; 
}

Some further info:

http://bisqwit.iki.fi/story/howto/openmp/

https://www.youtube.com/watch?v=Pc8DfEyAxzg

How to use multithreading in 3D software renderer to speed up fetching texture values

2 Answers2