GPU production constraints are creating infrastructure bottlenecks. Multi-GPU programming, particularly vendor-agnostic implementations, has become essential. In their GPU Mode presentation, AMD Research engineers Muhammad Awad, Muhammad Osama, and Brandon Potter introduced Iris—a Python library that enables fine-grained multi-GPU programming in Triton. Similarly to my previous Gluon blogpost, this post captures my understanding and interpretation of their work, serving as both technical documentation and personal reference for this emerging multi-GPU programming paradigm. Technical Problem 🔗Current multi-GPU programming uses bulk synchronous models (BSP) through libraries like NCCL. This model enforces sequential phases:

My Journey from PyTorch to Gluon 🔗After spending the last month diving into PyTorch, learning Triton, understanding CUDA, and even peeking at PTX/SASS assembly, I’ve come to a surprising realization: I’ve yet to meet anyone who’s actually writing raw CUDA code in production anymore. Everyone I’ve talked to – from ML engineers at startups to researchers at big tech companies – seems to have converged on Triton as their go-to solution for custom GPU kernels. And honestly? The fused kernels performance they’re getting is impressive enough that I understand why.

Another day, another zero-day. This time it’s CVE-2025-21043, a critical vulnerability in Android’s DNG image parser that’s been actively exploited in the wild. What makes this one particularly interesting is how it leverages an obscure feature of the DNG format—opcode lists—to achieve remote code execution. Following our previous analysis of CVE-2025-43300 and the ELEGANTBOUNCER detection framework, let’s dive into how this vulnerability works and why it matters. The Discovery 🔗On September 2025, Samsung just pushed a critical security update. The advisory was sparse on details, but one line caught everyone’s attention: