Although Robert F. Kennedy gets the credit for popularizing it, George Bernard Shaw said: “Some men see things as they are and say, ‘Why?’ I dream of things that never were and say, ‘Why not?'” Well, [Hadz] didn’t wonder why there weren’t many GPU debuggers. Instead, [Hadz] decided to create one.
It wasn’t the first; he found some blog posts by [Marcell Kiss] that helped, and that led to a series of experiments you’ll enjoy reading about. Plus, don’t miss the video below that shows off a live demo.
It seems that if you don’t have an AMD GPU, this may not be directly useful. But it is still a fascinating peek under the covers of a modern graphics card. Ever wonder how to interact with a video card without using something like Vulkan? This post will tell you how.
Writing a debugger is usually a tricky business anyway. Working with the strange GPU architecture makes it even stranger. Traps let you gain control, but implementing features like breakpoints and single-stepping isn’t simple.
We’ve used things like CUDA and OpenCL, but we haven’t been this far down in the weeds. At least, not yet. CUDA, of course, is specific to NVIDIA cards, isn’t it?
We make no claims to be an expert on anything, but we do know that rule number one of working with big, expensive, mission-critical equipment is: Don’t break the big, expensive, mission-critical equipment. Unfortunately, though, that’s just what happened to the Deep Space Network’s 70-meter dish antenna at Goldstone, California. NASA announced the outage this week, but the accident that damaged the dish occurred much earlier, in mid-September. DSS-14, as the antenna is known, is a vital part of the Deep Space Network, which uses huge antennas at three sites (Goldstone, Madrid, and Canberra) to stay in touch with satellites and probes from the Moon to the edge of the solar system. The three sites are located roughly 120 degrees apart on the globe, which gives the network full coverage of the sky regardless of the local time.
In today’s “News from the Dystopia” segment, we have a story about fighting retail theft with drones. It centers on Flock Safety, a company that provides surveillance technologies, including UAVs, license plate readers, and gunshot location systems, to law enforcement agencies. Their flagship Aerodome product is a rooftop-mounted dock for a UAV that gets dispatched to a call for service and acts as an eye-in-the-sky until units can arrive on scene. Neat idea and all, and while we can see the utility of such a system in a first responder situation, the company is starting to market a similar system to retailers and other private sector industries as a way to contain costs. The retail use case, which the story stresses has not been deployed yet, would be to launch a drone upon a store’s Asset Protection team noticing someone shoplifting. Flock would then remotely pilot the drone, following the alleged thief back to their lair or hideout and coordinating with law enforcement, who then sweep in to make an arrest.
We can understand why shaderacademy.com chose that name over “the shady school,” but whatever they call it, if you are looking to brush up on graphics programming with GPUs, it might be just what you are looking for.
The website offers challenges that task you to draw various 2D and 3D graphics using code in your browser. Of course, this presupposes you have WebGPU enabled in your browser which means no Firefox or Safari. It looks like you can do some exercises without WebGPU, but the cool ones will need you to use a Chrome-style browser.
You can search by level of difficulty, so maybe start with “Intro” and try doing “the fragment shader.” You’ll notice they already provide some code for you along with a bit of explanation. It also shows you a picture of what you should draw and what you really drew. You get a percentage based on the matching. There’s also a visual diff that can show you what’s different about your picture from the reference picture.
We admit that one is pretty simple. Consider moving on to “Easy” with options like “two images blend,” for example. There are problems at every level of difficulty. Although there is a part for compute shaders, none seem to be available yet. Too bad, because that’s what we find most interesting. If you prefer a different approach, there are other tutorials out there.
‘Hearing voices’ doesn’t have to be worrisome, for instance when software-defined radio (SDR) happens to be your hobby. It can take quite some of your time and attention to pull voices from the ether and decode them. Therefore, [theckid] came up with a nifty solution: RadioTranscriptor. It’s a homebrew Python script that captures SDR audio and transcribes it using OpenAI’s Whisper model, running on your GPU if available. It’s lean and geeky, and helps you hear ‘the voice in the noise’ without actively listening to it yourself.
This tool goes beyond the basic listening and recording. RadioTranscriptor combines SDR, voice activity detection (VAD), and deep learning. It resamples 48kHz audio to 16kHz in real time. It keeps a rolling buffer, and only transcribes actual voice detected from the air. It continuously writes to a daily log, so you can comb through yesterday’s signal hauntings while new findings are being logged. It offers GPU support with CUDA, with fallback to CPU.
It sure has its quirks, too: ghost logs, duplicate words – but it’s dead useful and hackable to your liking. Want to change the model, tweak the threshold, add speaker detection: the code is here to fork and extend. And why not go the extra mile, and turn it into art?
When your GPU fan goes rogue with an unholy screech, you either shell out for a new one or you go full hacker mode. Well, [ashafq] did the latter. The result is a delightfully nerdy fan controller powered by an ATTiny85 and governed by a DS18B20 temperature sensor. We all know a silent workstation is golden, and there’s no fun in throwing money at an off-the-shelf solution. [ashafq]’s custom build transforms a whiny Radeon RX 550 into a cool, quiet operator. Best of all: it’s built from bits likely already in your junk drawer.
To challenge himself a bit, [ashafq] rolled his own temperature-triggered PWM logic using 1-wire protocol on an ATtiny85, all without libraries or bloated firmware. The fan’s speed only ramps up when the GPU gets toasty, just like it should. It’s efficient and clever, and that makes it a fine hack. The entire system runs off a scavenged 12V fan. He could have used a 3D printer, but decided to stick onto the card with double-sided tape. McGyver would approve.
The results don’t lie: idle temps at 40 °C, load peaking at 60 °C. Quieter than stock, smarter than stock, and way cheaper too. The double-sided tape may not last, but that leaves room for improvement. In case you want to start on it yourself, read the full write-up and feel inspired to build your own. Hackaday.io is ready for the documentation of your take on it.
Before the release of Piper TTS in 2023, existing free-to-use TTS systems such as espeak and Festival sounded robotic and flat. Piper delivered much more natural-sounding output, without requiring massive resources to run. To change the voice style, the Piper AI model can be either retrained from scratch or fine-tuned with less effort. In the latter case, the problem to be solved first was how to generate the necessary volume of training phrases to run the fine-tuning of Piper’s AI model. This was solved using a heavyweight AI model, ChatterBox, which is capable of so-called zero-shot training. Check out the Chatterbox demo here.
As the loss function gets smaller, the model’s accuracy gets better
Training began with a corpus of test phrases in text format to ensure decent coverage of everyday English. [Cal] used ChatterBox to clone audio from a single test phrase generated by a ‘mystery TTS system’ and created 1,300 test phrases from this new voice. This audio set served as training data to fine-tune the Piper AI model on the lashed-up GPU rig.
To verify accuracy, [Cal] used OpenAI’s Whisper software to transcribe the audio back to text, in order to compare with the original text corpus. To overcome issues with punctuation and differences between US and UK English, the text was converted into phonemes using espeak-ng, resulting in a 98% phrase matching accuracy.
After down-sampling the training set using SoX, it was ready for the Piper TTS training system. Despite all the preparation, running the software felt anticlimactic. A few inconsistencies in the dataset necessitated the removal of some data points. After five days of training parked outside in the shade due to concerns about heat, TensorBoard indicated that the model’s loss function was converging. That’s AI-speak for: the model was tuned and ready for action! We think it sounds pretty slick.
