I'm currently trying to implement some form of triplanar multitexturing for my procedural planet renderer.
I'm storing all of my terrain diffuse textures in a dxt1 compressed texture array.
Somehow I was under the impression that it would be horribly inefficient to do conditional sampling on each texture array slice due to dynamic branching.
I couldn't really figure out a good way to calculate the 2 texture array indices I need to sample from ahead of time though, so I decided to use conditional sampling as a temporary solution until I figure out something more efficient.
And to my surprise it worked brilliantly, which made me realize that dynamic branching does not have the performance issues I thought it would have.
At least not on modern cards.
Here's what I'm currently doing:
float3 CDiffuse = 0.0;
[unroll]
for(int i = 0; i < 5; i++)
{
if(TIntensity > 0.0)
CDiffuse += TIntensity * GetTriplanarSample(BlendWeights, coord1, coord2, coord3, i, TADiffuse, TSampler);
}
TIntensity[] are the texture intensities. They are calculated within the same shader.
GetTriplanarSample() gets 3 texture samples and blends them together using triplanar texturing from array slice i.
There are always only 2 TIntensity values higher than 0.0 at any given time.
And to my surprise, this has the same performance as doing:
CDiffuse += 0.5 * GetTriplanarSample(BlendWeights, coord1, coord2, coord3, 0, TADiffuse, TSampler);
CDiffuse += 0.5 * GetTriplanarSample(BlendWeights, coord1, coord2, coord3, 1, TADiffuse, TSampler);
On the other hand if I remove the conditional branch:
float3 CDiffuse = 0.0;
[unroll]
for(int i = 0; i < 5; i++)
{
//if(TIntensity > 0.0)
CDiffuse += TIntensity * GetTriplanarSample(BlendWeights, coord1, coord2, coord3, i, TADiffuse, TSampler);
}
Sampling takes about 2ms longer on my gtx580 in this situation, clearly showing that the card is branching with no noticeable performance loss.
Is dynamic branching in shaders really this powerful nowadays, or is this a special case where it performs well?
The GPU probably doesn't do any branching here. It just clamps TIntensity so that negative values are clamped to zero (which can be done for free on ALU's), which results in equivalent operation. You could try and disassemble your shader to see what is actually happening to be sure it's actually branching.
Although yes, in general dynamic branching is pretty efficient on modern GPU's.
“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”
The actual cost of the condition/branch instructions is quite low -- as cheap as a few ALU operations. Even on old SM3 cards, branches would range between 2-12 ALU ops in cost, so as long as you were on average skipping more than 12 ALU ops with your branch, then they were 'fast'.
They only become really expensive when neighbouring pixels take opposite paths. e.g. pixel (10,42) is true, but pixel (10,43) is false -- the GPU processes pixels in batches (usually a 2*2px quad), and it different paths are taken inside a batch, then every pixel in that patch has to take both paths (and discard the unwanted one).
You should check the assembly, I think Bacterius is right about the compiler not actually using branch instructions. You can't use normal Sample instructions inside of a branch, so if you're using Sample then it's definitely not branching. Or at least, it's not executing the actual Sample inside the branch. Sometimes the compiler will move a Sample outside of a branch and emit a warning (always make sure that you output those when you compile your shaders).
As for dynamic branching perf it's definitely really good on modern hardware, as long as it's pretty coherent. Typically branching coherency is a warp or a wavefront, so either 32 or 64 threads.
I'm not really sure how to interpret this.
t2 is the texture array in question, so I guess this part is responsible for sampling:
lt r4.y, l(0.000000), r2.w
mul r5.y, v1.y, l(-2.000000)
mov r5.w, l(0)
sample r6.xyzw, r5.xywx, t2.xyzw, s0
mov r7.xz, r5.zzwz
mul r7.y, v1.z, l(-2.000000)
sample r8.xyzw, r7.xyzx, t2.xyzw, s0
mul r3.y, v1.y, l(-2.000000)
mov r3.zw, l(0,0,0,1.000000)
sample r9.xyzw, r3.xyzx, t2.xyzw, s0
if_nz r4.y
mul r4.yzw, r2.yyyy, r8.xxyz
mad r4.yzw, r6.xxyz, r2.xxxx, r4.yyzw
mad r4.yzw, r9.xxyz, r2.zzzz, r4.yyzw
mul r4.yzw, r2.wwww, r4.yyzw
else
mov r4.yzw, l(0,0,0,0)
endif
lt r2.w, l(0.000000), r4.x
mov r5.zw, l(0,0,1.000000,2.000000)
sample r6.xyzw, r5.xyzx, t2.xyzw, s0
mov r7.w, l(1.000000)
sample r8.xyzw, r7.xywx, t2.xyzw, s0
sample r9.xyzw, r3.xywx, t2.xyzw, s0
if_nz r2.w
mul r8.xyz, r2.yyyy, r8.xyzx
mad r6.xyz, r6.xyzx, r2.xxxx, r8.xyzx
mad r6.xyz, r9.xyzx, r2.zzzz, r6.xyzx
mad r4.yzw, r4.xxxx, r6.xxyz, r4.yyzw
endif
lt r2.w, l(0.000000), r0.x
sample r5.xyzw, r5.xywx, t2.xyzw, s0
mov r7.z, l(2.000000)
sample r6.xyzw, r7.xyzx, t2.xyzw, s0
mov r3.z, l(2.000000)
sample r3.xyzw, r3.xyzx, t2.xyzw, s0
if_nz r2.w
mul r6.xyz, r2.yyyy, r6.xyzx
mad r2.xyw, r5.xyxz, r2.xxxx, r6.xyxz
mad r2.xyz, r3.xyzx, r2.zzzz, r2.xywx
mad r4.yzw, r0.xxxx, r2.xxyz, r4.yyzw
endif
It indeed doesn't seem to branch out the sample instructions.
I know that I'm bottlenecking on texture sampling (bandwidth) though, which isn't a big surprise because I do way too much texture sampling.
When I add the if statements the performance increases massively, so I'm assuming the gpu is somehow able to skip the sample instructions if I add these conditions?
While it can't branch over Sample() calls it can do so over SampleGrad() calls as long as ddx and ddy are calculated outside of the if tests.
You might also find http://developer.amd.com/tools/shader/Pages/default.aspx useful - the dx assembly gets compiled again by the driver and that will show you the result for AMD cards.
While it can't branch over Sample() calls it can do so over SampleGrad() calls as long as ddx and ddy are calculated outside of the if tests.
You might also find http://developer.amd...es/default.aspx useful - the dx assembly gets compiled again by the driver and that will show you the result for AMD cards.
Not all hardware can physically implement such behavior, so the D3D compiler produces more generic assembly that can be used by all D3D-compatible drivers.
The hardware manufacturer knows exactly the capabilities of their cards, so they can further analyze and modify the logic like this on the driver to optimize it for specific chips.
The sampling restriction inside conditionals is in place because the hardware needs to be able to calculate the derivative of the texture coordinate in order to select the mip leves from which to sample, and conditionals that can affect said texture coordinate in any way make that derivative undefined. If you calculate the derivatives on your own, this ceases to be a problem. In addition, the HLSL compiler will actually try to move the sample instruction out of the conditionals, if there are no circular dependencies on the derivatives that prevent this.
Yeah, for some reason I thought that the D3D generated assembly would be final when I started this topic.
Obviously this makes no sense because every graphics card has different capabilities and optimizations.
While I now assume that modern Ati & Nvidia cards are perfectly capable of skipping sampling instructions in similar situations, I guess I'll go with the SampleGrad() route to be on the safe side.
Because if I do this for multiple texture arrays containing ~10 textures each, and some random card is lacking this capability, things will go horribly wrong.
Thanks for helping me better understand how these things work!
Cheers,
Hyu
