EDIT: To answer you - they work all when loading from source, but right after only one of each 2x2x2 subgroup build 1st miplevel of the source - that's why the maskin is in that place.

Ah, finally get it.

There is a better approach:

Lets say we have a 8 pixel 1D texture in LDS, and t is the thread index of a 4 thread workgroup:

float4 reg = lds[t*2] + lds[t*2+1]; // 0+1, 2+3, 4+5, 6+7
write mipmap1(reg)
lds[t*2] = reg; // results in 0,2,4,5
ldsBarrier();
 
if (t<2)
{
reg = lds[t*4] + lds[t*4+2]; // 0+2, 4+6
write mipmap2(reg)
lds[t*4] = reg; // results in 0,4
}
 
ldsBarrier();
if (t==0)
{
reg = lds[t*4] + lds[t*4+2]; // 0+4
write mipmap3(reg)
}

You see initially all threads have work, but you need to load multiple texels per thread.

I did not realize this initially but i wondered why your LDS rquirements are so low.

Bad news is with 8 texels per thread your LDS usage would become too high, so there is no simple answer how to balance all this to get the best possible result.

Trial and profiling fun expected... :D

Edit: You could use float3, add a tiny value to colors so (0,0,0) can be used to determinate an empty voxel.

Half floats would be nice too, you could load the packed stuff directly to LDS and un/pack it from there as discussed here: https://www.gamedev.net/topic/688773-how-will-fp16-affect-games/

How do you plan to deal with the thin wall problem? Think of a thin wall where both front and backside fall into one voxel. You can't build a proper normal.

I've tried spherical harmonics for this purpose - 4 values did not really help and 9 was still not good enough (I tried to encode directional surface area instead normals, but the problem is similar).