:lol: I remember doing exactly the same thing when I started: "Huh, what's all this SV_GroupThreadWhatever do ???"

Yeah I know right! It was all like what in God's name! Last night I grabbed a render target SRV and put it through the compute shader then saved it as a JPEG. I also came to the realization why sometimes creating a render target of R32G32B32A32_FLOAT is heavy on memory performance. A render target of R8G8B8A_UNORM does just fine. One thing I do have to do is in my engine is to enumulate all the display modes and save it a configuration file then have the program pick which one is suitable. Dispatching 64, 21, 1 threads for the constant buffer just to fill up the render target I'm not sure is any good because in the shader only 32 is the max apparently. After reading on MSDN the max dispatchable threads are higher than 64 but I'm not sure how well that will do with performance. I'll have to use a high resolution timer to see the difference.

Not sure I follow. You probably confuse something here. The 32 "limit" (or 64 for AMD) is the so-called warp size (aka wave front), and to "max out" the GPU's performance a group size should be a multiple of this (i.e. the product x*y*z of [tt][numthreads(x,y,z)][/tt]).

Apart from that, don't bother too much just yet. I consider the switch to compute from normal shaders as at least as difficult to understand as the switch from regular programming to graphics shaders. Best start playing with available source (e.g. prefix sum).

Yeah the whole dispatch(x,y,z) and the whole numthreads[x,y,z] was tripping me up a bit! It is confusing to get a handle of because your dealling with each thread of x,y,z to fill up a texture. Where as the pixel shaders just deal with output the pixels to the render target or back buffer. The way of the shader language goes is different instead of returning float4 as in the pixel shader vs as bufferOut[dispatchThread.xy] = data[dispatchThread.xy]