Timeline for How to use multithreading in 3D software renderer to speed up fetching texture values
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 24, 2017 at 22:41 | comment | added | Benjamin Loisch | @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. | |
| Jul 22, 2017 at 10:12 | comment | added | PaulHK | 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. | |
| Jul 21, 2017 at 16:42 | comment | added | Benjamin Loisch | @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? | |
| Jul 21, 2017 at 3:55 | comment | added | PaulHK | 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 | |
| Jul 20, 2017 at 16:05 | comment | added | Benjamin Loisch | @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. | |
| Jul 20, 2017 at 8:49 | answer | added | Simon F | timeline score: 5 | |
| Jul 20, 2017 at 8:34 | answer | added | mdkdy | timeline score: 2 | |
| Jul 20, 2017 at 8:21 | comment | added | Dan Hulme | 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. | |
| Jul 20, 2017 at 3:58 | comment | added | aces | How are you currently accessing memory? Can you share code for that? | |
| Jul 19, 2017 at 19:54 | review | First posts | |||
| Jul 20, 2017 at 5:24 | |||||
| Jul 19, 2017 at 19:52 | history | asked | Benjamin Loisch | CC BY-SA 3.0 |