A few months ago, if you’d asked me what a GPU actually does, I would’ve mumbled something about “graphics” and changed the subject. I’m an undergrad, self-taught in most of what I know about programming, and until recently, GPUs were just… background noise. Something gamers cared about. Something that showed up in specs sheets I didn’t understand.
The moment it stopped being background noise
It started the way a lot of rabbit holes start: I kept seeing people online talking about RTX this, RTX that, benchmarks, VRAM, tensor cores — and it all went completely over my head. I’d nod along in threads I didn’t understand, half-following conversations about why one card was “better” than another, quietly bothered that I had no idea what any of it meant.
At some point that turned into an actual itch. I don’t like not knowing things, especially when it feels like everyone else is fluent in something I can’t even parse. So I decided I had to figure out what a GPU actually was — not just as a gaming accessory, but as a piece of hardware people were clearly doing serious computational work with.
That’s when I started noticing something else: people weren’t just gaming on these things. I kept running into posts and videos of people running genuinely heavy workloads on GPUs — training models, running simulations, crunching numbers at speeds that made no sense to me coming from a CPU-only mental model. That was the real hook. Not the marketing, not the specs — the fact that people were using GPUs as general-purpose computing beasts, and I had zero idea how that was even possible.
Falling into CUDA (and discovering it’s not the only player)
Once I started digging, I learned that “using a GPU for computation” isn’t some universal, plug-and-play thing — it depends entirely on who made your hardware. NVIDIA has its own ecosystem called CUDA, and AMD has its own competing thing called ROCm. That distinction genuinely fascinated me. Two of the biggest hardware companies in the world, each with their own language and toolchain for talking to their own silicon.
A bit of digging confirmed what I’d suspected: CUDA is NVIDIA’s proprietary platform, built specifically for NVIDIA GPUs, and it’s been around since 2006 — which is a big part of why it has such a mature ecosystem of libraries, tools, and community support today. ROCm, on the other hand, is AMD’s open-source answer, built around HIP (Heterogeneous-Compute Interface for Portability), which is designed to closely resemble CUDA’s syntax so that code can be ported between the two with less pain. There’s even a translation layer called HIPIFY that converts CUDA code into HIP so it can run on AMD hardware.
What struck me most was that this isn’t just a technical footnote — it’s basically a walled-garden situation. CUDA’s maturity and dominance, especially in AI and deep learning workloads, is a big reason NVIDIA has had such a strong grip on the space. AMD is playing catch-up with an open-source strategy, hoping that openness eventually wins over raw maturity. As someone who’d never thought about hardware ecosystems as competing programming languages before, that was a genuinely new way of seeing the tech industry.
Where I’m at now
I’ll be honest — I’m still very early. Right now my “journey” is less about writing optimized kernels and more about building the mental model: understanding what a thread, block, and grid even mean in CUDA terms, why memory transfer between CPU (host) and GPU (device) is such a big deal, and why “just throw it on the GPU” is a lot more nuanced than it sounds from the outside.
But that initial confusion — the feeling of being completely lost in a conversation about RTX cards — has turned into something I actually look forward to learning more about. I went from not knowing what a GPU was for, to being genuinely curious about parallel computing as a discipline. That’s a bigger shift than I expected.
Why I’m writing this
I’m writing this partly for accountability, and partly because I know there are other self-taught devs out there who’ve felt that same “everyone else understands this but me” feeling. If that’s you — you don’t need a CS degree or a research lab to start. You just need the willingness to feel lost for a while before things click.
If you’re also early in your GPU programming journey, or you’ve been down this road already and have advice, tools, or resources that helped things click for you, I’d genuinely love to hear about it in the comments. This is very much a “learning in public” post, not an expert one.
More updates to come as I actually start writing CUDA kernels instead of just reading about them.