To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/VoxelRifts . The first 200 of you will get 20% off Brilliant’s annual premium subscription.
Regarding treating booleans like integers and optimising conditional statements this way, is it not true that in a lot of cases, the compiler can figure out the optimisation by itself and change your code as if you were doing it that? I know it is true in C, if not in glsl.
@@voxelrifts The reason I'm saying it is because in some instances the resulting machine code with the manual optimisation might actually be slower than the one where you let the compiler do it for you, because in the first case the compiler doesn't really know what you're attempting to do and refuses to do some other kinds of optimization as a result. Either way if statements on GPUs only really become an issue if the work being done in each case is wildly different (rather than just picking out a different value depending on the case), so yeah it should probably only be done for demonstration purposes.
@David_Box true… I wonder why there isn’t some diagnostic mode where you can see which sections of your code were recognized to be “available for optimization” by the compiler and which ones resulted in this fall through scenario you described… would be good for low level programming
It still depends however. I've seen shader code that was measurably faster with if-statement + the condition was per-pixel and not per-wavefront. Always profile! :)
Thanks for the awesome explanation! What if I only use an 'If' without using an else. Is a new branch still created? The code block that I want to put inside a condition is a texture sample. I don't want to do the texture sample when the texture is not needed. 1. I can use a static switch (#ifdef) but I read that it will create shader variants and it's not good for batching 2. I can either just have a dummy 4x4 pixels texture so that all the materials can have the same shader and be batched in the same draw call. 3. I can use an 'if' statement but without the 'else'. I was told that it won't add another branch. Something like float4 tex = (float4)0.0f; if (enableTex == 1.0f) { tex = {do the sample}; } Which option do you think will give the best performance?
I would personally go for 2, but make sure to profile it in either case. Method 3 will still branch out, but it's going to be fine if all your instances consistently use/not use the texture. Problems mainly start when the conditions are inconsistent per instance, per vertex or per pixel and such. There's an online book called "Render Hell 2.0" by Simon Schreibt that at some point describes roughly how the GPU treats branches. It may have been explained in the video, but I haven't finished watching yet
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/VoxelRifts . The first 200 of you will get 20% off Brilliant’s annual premium subscription.
I didn't know anything about GPUs but this video has such depth yet still explains concepts so well I think I understood about all of it! Awesome man!
1:35 I love how you’re struggling with your past self while editing 😂 ❤
nicely explained!! And congratulations on your first sponsor! :)
Thats a great introduction of how GPUs work
Very cool, thank you!
Congrats on your first sponsor! :)
Regarding treating booleans like integers and optimising conditional statements this way, is it not true that in a lot of cases, the compiler can figure out the optimisation by itself and change your code as if you were doing it that? I know it is true in C, if not in glsl.
In most, if not all cases, yes. But it's always good to know *how* it's done
@@voxelrifts The reason I'm saying it is because in some instances the resulting machine code with the manual optimisation might actually be slower than the one where you let the compiler do it for you, because in the first case the compiler doesn't really know what you're attempting to do and refuses to do some other kinds of optimization as a result.
Either way if statements on GPUs only really become an issue if the work being done in each case is wildly different (rather than just picking out a different value depending on the case), so yeah it should probably only be done for demonstration purposes.
@David_Box true… I wonder why there isn’t some diagnostic mode where you can see which sections of your code were recognized to be “available for optimization” by the compiler and which ones resulted in this fall through scenario you described… would be good for low level programming
@@Alpha_GameDev-wq5cc just read shader assembly.
sponsor 😎😎
It still depends however. I've seen shader code that was measurably faster with if-statement + the condition was per-pixel and not per-wavefront. Always profile! :)
Absolutely, always profile!
Thanks for the awesome explanation! What if I only use an 'If' without using an else. Is a new branch still created?
The code block that I want to put inside a condition is a texture sample. I don't want to do the texture sample when the texture is not needed.
1. I can use a static switch (#ifdef) but I read that it will create shader variants and it's not good for batching
2. I can either just have a dummy 4x4 pixels texture so that all the materials can have the same shader and be batched in the same draw call.
3. I can use an 'if' statement but without the 'else'. I was told that it won't add another branch. Something like
float4 tex = (float4)0.0f;
if (enableTex == 1.0f)
{
tex = {do the sample};
}
Which option do you think will give the best performance?
I would personally go for 2, but make sure to profile it in either case.
Method 3 will still branch out, but it's going to be fine if all your instances consistently use/not use the texture. Problems mainly start when the conditions are inconsistent per instance, per vertex or per pixel and such.
There's an online book called "Render Hell 2.0" by Simon Schreibt that at some point describes roughly how the GPU treats branches. It may have been explained in the video, but I haven't finished watching yet
does cuda have that too?
yes
I just realized you have a accent.
yeah i think it sounds stronger in this particular video. probably just imagining things though
Is a ternary operator that just sets a value as bad as the other if statements?
Still no one knows what happens when you branch off of uniforms huh? 😅