sebbbi

Top moves:
2: i11 high, +1 block, +9 hit, 10 dmg, followup (NC): (1) mid, -2 block, +3 hit, NC = 22 dmg
f2: i10 high, -12 block, +5 hit, 17 dmg, CH followups: ff1 = 40 dmg, ff3 = 48 dmg, f3+4 = 42 dmg
f1: i14 mid, -6 block, +5 hit, 15 dmg, followup (NC): (1) high, -7 block, NC = 40 dmg
df1: i14 mid, -4 block, +3 hit, 12 dmg, followups (CH NC): (2,1) delayable high,high, launch, (1) mid, -12 block. CH NC = 55 dmg
db1: i12 low, -12 block, +2 hit, 13 dmg
df2: i15 mid, -14 block (safe tip range), launch
f1+2: i15 mid, -19 block (pushback), wall bounce
db,d,df1: i24 low, high crush, -37 block, 30 dmg
FC db1: i12 low, high crush, -8 block, +6 hit, 15 dmg

sebbbi

i10 jab / punish:
1,2,2: mid NC, -10 block, +8 CFT hit
1,2,4: low, -13 block, +3 hit. CH: ff3 followup = 34 dmg

+8 CFT mixup: 
1: mid i20, -9 block, hit KD, CH ff1+2 followup = 59 dmg
4: low i19, -26 block, ff3 followup = 26 dmg

ff2 i14 long range mid:
block: -2 pushback -> backdash

sebbbi

All current buffer types in shading languages are slightly different ways to present homogeneous arrays (single struct or type repeating N times in memory).

DirectX has raw buffers (RWByteAddressBuffer) but that is limited to 32 bit integer types and the implementation doesn't require natural alignment for wide loads resulting in suboptimal codegen on Nvidia GPUs.

Complex use cases, such as tree traversal in spatial data structures (physics, ray-tracing, etc) require data structure that is non-homogeneous. You want different node payloads and tight memory layout.

Ability to mix 8/16/32 bit data types and 1d/2d/4d vectors to faciliate GPU wide loads (max bandwidth) in same data structure is crucial for complex use cases like this. 

On the other hand we want better more readable/maintainable code syntax than DirectX raw buffers without manual bit packing/extracting and reinterpret casting. Goal should be to allow modern GPUs to use sub-register addressing (SDWA on AMD hardware). Saving both ALU and register

sebbbi

Spherical cap cone analytic solution is a 1d problem, since the cone cap sphere slides along the ray. The intersection point to empty space sphere is always on the ray.

S : radius of cone cap sphere at t=1
r(d) : cone cap sphere radius at distance d

r(d) = d*S

p = distance of current SDF sample
SDF(p) = sdf function result at location p
x = distance after conservative step

sebbbi

// NOTE: Must bind 8x single mip RWTexture views, because HLSL doesn't have .mips member for RWTexture2D. (SRVs only have .mips member)
// NOTE: globallycoherent attribute is needed. Without it writes aren't guaranteed to be seen by other groups
globallycoherent RWTexture2D<float> MipTextures[8];
RWTexture2D<uint> Counters[8];
groupshared uint CounterReturnLDS;

[numthreads(16, 16, 1)]
void GenerateMipPyramid(uint3 Tid : SV_DispatchThreadID, uint3 Group : SV_GroupId, uint Gix : SV_GroupIndex)
{
	[unroll]

sebbbi

In shader programming, you often run into a problem where you want to iterate an array in memory over all pixels in a compute shader
group (tile). Tiled deferred lighting is the most common case. 8x8 tile loops over a light list culled for that tile. 

Simplified HLSL code looks like this:

Buffer<float4> lightDatas;
Texture2D<uint2> lightStartCounts;
RWTexture2D<float4> output;

[numthreads(8, 8, 1)]