The thing to understand about the GPU is that it’s essentially a massively multi-core machine. Like 2048 cores (on the latest GTX 980), or 1024 cores on a more modest NVidia card. Each one of those cores can execute a fairly complex instruction set, although not quite as complex as a modern CPU.
These cores must all share memory, which comes in different forms, ranging from “Global” to “thread group”. Without getting into all of those details (not particularly important at this moment), the point is that even at the most granular level of memory, it is shared by ~48 cores. Thus, your code must be written in a parallel manner, which is foreign to most developers used to writing code on the CPU. Check out some tutorials on “Prefix Scan” or “Parallel Prefix Sum” to give you a sense. But essentially this boils down to re-writing your algorithms so that chunks can be worked on simultaneously. The simple example in a serial context: for(int i=0, i<100, i++){ sum += data[i]; } This will clearly sum up an array. But it uses a single thread. To do this in parallel (and assuming you have at least 50 threads):
first iteration:
for each thread i, where i >= 0 and i < 50
output1[i] = data[i*2] + data[i*2+1]
second iteration:
for each thread i, where i >= 0 and i < 25:
output2[i] = output1[i*2] + output1[i*2+1]
third iteration:
for each thread i, where i >= 0 and i < 13:
output3[i] = output2[i*2] + output2[i*2+1]
et cetera, until after 7 iterations you’re left with a single piece of data, which is your answer. (Note you don’t actually need 7 output buffers… you can use simple ‘double buffering’ and just flip back and forth between them).
Actually, for something this simple, it would likely be much more efficient to do so using fewer iterations (and thus less threads overall, but more operations per thread) because there is a lot of overhead involved with setting up each iteration. Visually, here’s a good example of doing a sum with more operations per thread:
The 64 teal dots in this case represent your original data. Say each of them represent a single floating point number from -1 to +1. Lets put them in an array called data[]. Sum them as such:
first iteration:
spawn 16 threads, each labeled 'i', where i >= 0 and i < 16 <---- these are the red dots
output1[i] = data[i*4] + data[i*4+1] + data[i*4+2] + data[i*4+3]
second iteration:
spawn 4 threads, each labeled 'i', where i >= 0 and i < 13 <---- these are the blue dots
output2[i] = output1[i*4] + output1[i*4+1] + output1[i*4+2] + output1[i*4+3]
third iteration:
spawn 1 thread <---- this is the topmost black dot
sum = output2[0] + output2[1] + output2[2] + output2[3]
Looks familiar, doesn’t it! Luckily for us graphics cards are very well suited to performing computations on large arrays (or n-dimensional matrices) of data, and are logically well-suited to spatial subdivisions like the quadtree above. Again, the key concept here is thread-independence. If your task can be broken into many subtasks which each run parallel and no not depend upon the (in-progress) results of each other, then chances are it can be well-adapted to the GPU.
Interruption to regularly scheduled programming: My wife is begging to play “Lovers in a Dangerous Spacetime” (hell yes my wife likes to play games… I’m the luckiest man on Earth). I’m going to finish this post here and pick it up tomorrow (day off! woo!). Sorry 
But here’s what’s in the queue:
First I’ll discuss two aspects of GPGPU planet generation: terrain heightmap generation, and vertex normal generation. Heightmap generation is very straightforward, particularly because each vertex is independent from one another, and only needs one piece of information as input: position. Vertex normal generation is slightly more complex, however, because each vertex must read from multiple locations (i.e. its surrounding vertices). It’s not so bad, though, because this is a read-only operation, and thus the normal for every vertex can be calculated in a single pass.
Next I’ll start getting into what this looks like in Unity, with some code examples. I’ll probably not have fixed my main Unity project by that point, but do have a simpler terrain generation project which will be well-suited to the task (It’s basically a single behemoth monobehaviour, but I’ll break it down).
Till next time.
, but I need loooooots of shader howto with a required strong learning curve shock. Is that really how you devide the tasks?
so it’s not in a compilable state at the moment. That shouldn’t matter - the core code that drives Unity is unchanged, but the organization of it is going to be wrong, so if you see random custom classes referenced in some places but not others, don’t think much of it.
. Well could’ve been anything, so today I started again building up on my working implementation, changing and checking everything step by step.
. Very nice. Looking at it, it should be straightforward to append this approach to the six quadtrees for creating a sphere, as in the end it seems it is all about changing the parameters in the constantsbuffer per quadtreenode, the rest is done in the computer shader.