GPU programming is so cool! You need 600 lines of code to add 2 numbers. You don't have traditional stepping debugger, instead you have validation layers and renderdoc. GPUs don't have branch predictors and are heavily parallel, so you really don't want if conditions. It's basically like getting into programming all over again. My head hurts, but like in a good way. I'm learning!

Mar 26, 2026 · 9:09 PM UTC

78
63
2,712
156,466
Sort replies: Relevant Recent Liked
Replying to @valigo
If you want to do a quick dive, python + torch is a good start. CUDA, Metal, ROCm, .... all supported with proper CPU fallback
1
37
9,006
python we here suffer by writing all the vulkan boilerplate by hand and by using gpus that do not support cuda!
2
87
6,949
Replying to @valigo
And so, misinformation that has been false since 2007 lives on. If-statements in shaders have been pretty much fine since DX10. See: Crysis with raymarched clouds and other effects that require loads of branching.
2
9
6,532
ahh, so that's why even modern super computers can't run crysis
2
29
5,582
Replying to @valigo
600 lines sounds like a lot, even for a moderately complex shader. Are you also counting the client-side boilerplate for running the GPU program? Also, GPUs have branch (and other) predictors, but they work a bit differently because of immense pipelining.
1
4
5,534
> Are you also counting the client-side boilerplate for running the GPU program Yeah this is a bit of a knee-jerk about Vulkan being verbose af haha
26
4,294
Replying to @valigo
You making videos in this? Sounds super interesting.
1
1
2,716
Maybe at some point when I know more about it so I don't talk nonsense and embarrass myself haha
1
11
2,457
Replying to @valigo
You can step backwards in renderdoc. You can go from an output pixel back to a fragment shader which produced it and step to any point in the execution. Also if statements are fine, you just need to keep register pressure and warp divergence under control.
3
2
5,371
> keep register pressure and warp divergence under control

ALT Fig GIF

6
48
4,236
Replying to @valigo
Are you learning cuda? I’ve been thinking about to start this weekend to.
1
1,996
no cuda, only whatever is the open standard. In my case that would be Vulkan
4
1,847
Replying to @valigo
Getting good at GPU programming will make you a better coder on modern CPUs. A throughput-oriented mentality, while critical on GPUs, is also a way better way of coaxing better performance out of the wide, deeply-pipelined, SIMD-enabled monstrosities that are modern CPUs.
1
3
37
1,775
Replying to @valigo
If conditions are fine if they are transient enough for predication
1
7
993
Replying to @valigo
600 lines to add numbers but hey your latency is now parallelized pain
1
66
Replying to @valigo
the "my head hurts but in a good way" part is exactly what learning something new should feel like
1
184
Replying to @valigo
Real GPU programming is writing shaders, not the CPU-side GPU configuration crap that all the tutorials tell you about. Devs really shouldn’t need to worry about that if the programming environment had been created properly. That’s one of the problems that I’m working to resolve.
2
1
48
2,998
Replying to @valigo
“My head hurts but like in a good way” is the most accurate description of learning anything worth learning. The headache IS the brain building new hardware.
8
726
Replying to @valigo
i feel you gpu programming is a whole different beast i had to rewrite my uni algorithms to work with parallel processing its wild how much it differs from traditional programming
1
1
442
Replying to @valigo
I shipped a stepping debugger for CUDa (Nsight Eclipse Edition) over 10 years ago.
5
758
Replying to @valigo
GPU programming is just functional programming with fancy hardware. I will regret not learning Haskell when I first heard about it when I was 15. I could've become a wizard by now.
4
818
Replying to @valigo
It really is a lot of fun. I've been greatly enjoying my foray into GPU programming recently.
3
296
Replying to @valigo
and math hits you in the face from day 1, lovely 😂
2
669
Replying to @valigo
with today's GPU programming, you're more "controlling an external async device that isn't standardized" than writing actual logic. most of gpu programming is fighting the correct abstractions we have for unifying all of that complexity, whether it be opengl, vulkan, dx or metal
2
531
Replying to @valigo
So long as most of the warp lanes agrees, the GPU branching isn't an issue. I've been ignoring lack of GPU branch prediction and have not yet found much of an issue for my game so far.
1
3
1,024
Replying to @valigo
tbh, you can have a stepping debugger.
1
4
493