corysama

The 12” TV that I played SNES on had convenient brightness/tint/sharpness dials. Depending on my mood I’d turn sharpness all the way up for hard pixels or all the way down for a free Gaussian sampling filter ;)

Not a surprise. Now the fun works starts: Deriving semantics from psuedo-assembly.

When I started what you did was nothing but set up DMA streams to set registers. DMA sets registers, hardware reacts by rasterizing triangles.

In the GeForce3 era, the registers got complicated enough they resembled tiny "pixel shaders", but under the hood it was still a small struct held in registers. Vertex shaders were 1 to 128 asm instructions executed strictly linearly.

In the G80 era we got "general purpose shaders." But, they still depend heavily on the fix function pipeline for their dispatch/scheduling and I/O.

These days, everything is basically a dressed-up compute shader. The shared-memory SRAM is front-and-center in your attention. Dispatch and scheduling are manual and complicated. GPUs are transitioning into tensor evaluators.

So, maybe today we can start considering talking about planning committee meetings about stability. But, what I've observed is that this has been a request for a few decades now. And, in hindsight it would not have worked out in the past. Moving forward, maybe it would work out OK today for a while. But, I don't see the rate of change in GPUs slowing down any time soon. Wouldn't be surprised if we're racing towards some Cerebras + Tensor Cores + FPGA near future.

You might also be interested in "Open-sourced jev architecture last year with model,paper and dataset"

https://news.ycombinator.com/item?id=49736660

https://www.reddit.com/r/LocalLLaMA/comments/1wjieap/made_th...

Papers: https://arxiv.org/abs/2503.23303 https://arxiv.org/abs/2510.01237

Model: https://huggingface.co/DeepMostInnovations/sales-conversion-...

Dataset: https://huggingface.co/datasets/DeepMostInnovations/saas-sal...

I've been programming GPUs since the PlayStation1. The way they work under the hood has changed fundamentally maybe 4 times in that span.

I can't compare it to changes I've seen in CPU architecture since then. Maybe like: Compare the NES with its 6502 and per-cartridge mappers vs. a IBM 386 PC. Now repeat that shift 2 or 3 more times.

But, now you can play through the second half in VR https://www.youtube.com/watch?v=wXho2LdD1qo

A flood of VR mods for popular games have been coming out lately.

That's not necessary. If a service has access to the raw audio of a show, it can fingerprint each second of that audio in a way that can be matched in a tiny amount of computation even for a recording in a noisy environment.

That can't recognize what you say. But, it can ID where you are in a specific show out of zillions of hours of shows.

I know a guy who made a Shazam-like phone app that can listen to a few seconds of noisy audio and make a fingerprint that can be used to quickly ID those specific few seconds out of a pre-fingerprinted archive of an enormous amount of audio (zillions of hours of TV). Making the fingerprint requires a tiny amount of very smart code (in C with no dependencies). But, the fingerprint is not useful for understanding audio that's not in the archive.

Roughly how old was your nephew when he started using MakeCode?

Logo was my introduction to programming. Working on a 1 MHz Commodore64, my masterpiece was a fireworks show that was animated by the fact that the individual drawing commands were so slow you could watch them play out.

So, draw a curve from the ground to the sky. Draw some explosion shape. Change pen color to the sky color. Draw the curve and the explosion again to erase them. Change pen color and start the next firework.

BTW: https://github.com/ScryptHunter/ComfyUI-YuE2

You just need to work your way down to a deeper layer in the https://en.wikipedia.org/wiki/Matrioshka_brain Not the deepest layer. Humans would fry instantly there. But, the warm glow of the third layer down upon the fourth is quite pleasant.

> Who is like, "damn I wish I had a tablet that I could fold up and still barely fit in my pocket"?

Me. I get why people like small phones. But, I've have the iPhone Jumbo Huge edition for a long time now. I use my phone as a pocket tablet 10X more than as a phone.

Looking at the Duo specs https://www.apple.com/iphone-duo/specs/ vs my current 12 Max Pro specs https://support.apple.com/en-us/111874 it looks like the differences I care about are

1) 1878 pixels over 4.64" vs. 1284 over 3.07" 2) Default camera mode is 48 MP vs 12. Other modes are surprisingly similar. 3) A much faster CPU

I'm sure there are 1,000 more small differences. But, my 12 Jumbo Huge from late 2020 still runs great. If I were to upgrade, I'd get the Duo. We'll see how much longer I keep waiting, I guess.

My understanding of Hugging Face is limited to "File Host with Model Cards". Can someone with more understanding explain what the $12 billion value comes from?

I distinctly remember as a child watching Garfield the cartoon cat walking on the sofa. I remember explaining to my mother how cool that was that I could actually see him as real as anything.

I don't know when that ability faded. I think it was early because didn't really notice until people started talking about it recently. I can paint and draw. I can think about how things look. But, I don't see them. If I'm on the edge between awake and asleep I can force visualization as a lightweight lucid dreaming.

When I code, I think about data structures and algorithms using a mental proprioception. Putting things in space, moving them around. But, I have to remember where they are. Like playing the shell game with your eyes closed.

So, I know https://cactuscompute.com/needle is designed only to enable tool calling on tiny devices. But, I wonder if anyone has used it as a CPU-side mediator between a tool and a GPU-side local LLM making semi-natural-language tool requests...

It's an expression. "You're legs broke?" here means "What's stopping you from going to the library and reading a book?"

I forget the name of the document. But, the US military has a declaration that boils down to "When something goes wrong, blame cannot be shrugged off onto a machine. Somewhere in the chain of responsibility a human will be held accountable." Maybe the operator, the commanding officer, the vendor, maybe even all the way back to a software engineer. But, everyone can't hide behind the machine.

I know there have been papers and research projects about GS without COLMAP and GS from videos. But, I don't have links handy.

Best I can do is link you to https://x.com/RadianceFields and https://radiancefields.com/ They have all the news about GS every day.

On a CPU, hyperthreads are mostly replicated register banks. This allows the CPU to hold the context for 2 threads simultaneously. And, lets parts of a CPU make progress on one thread while the other thread is stalled. CPUs also has a kinda large microcode register bank that helps work around dependencies in asm instructions that reuse named registers.

On the GPU however, the hyperthreads are just a round-robin execution queue to take advantage of instruction pipelining. The register bank of a single GPU core is huge and can be flexibly divided across a variable number of thread contexts when a kernel is launched. Many thread contexts can be held in registers simultaneously in a single GPU core. That makes stalling on memory latency much less of a problem. The hardware can focus on delivering raw bandwidth with high latency and get great overall performance. This throughput-instead-of-latency trade-off extends to many other aspects of GPU design.

When you dig through the CUDA developer docs instead of the promotional materials, you can develop a view of Nvidia GPUs as having 8-128 processing cores, each with 4 hyperthreads, running 32-lane SIMD for almost everything. Where a lane is 32 bits wide.

The promotional material likes to label the individual lanes as “cores” because it sounds more impressive. And, it’s not entirely incorrect.

Even the dev docs use the marketing terminology. The description I gave above needs a bit of piecing together.

I can imagine abusing this to implement undo-redo for a game editor. Take snapshots. Record actions. Implement undo as: role back to a snapshot and re-run actions from the snapshot to the desired state.

That would be https://martinfowler.com/articles/mechanical-sympathy-princi...

Yep. It's my thesis that early GL APIs feel beginner-friendly because they are so hand-holdy, one-step-at-a-time. But, they end up more complicated when you get serious and they instill bad practices.

Instead, the "modern" APIs allow you to leverage your pre-existing knowledge of "allocate arrays of structs and start indexing them." That's not trivial. But, it is already familiar. And, it ends up a lot better in the end compared to "Invoke whole lot of functions to manipulate a hidden state machine."

You can find a little info on Modern OpenGL at https://github.com/fendevel/Guide-to-Modern-OpenGL-Functions, https://juandiegomontoya.github.io/modern_opengl.html, https://ktstephano.github.io/, https://patrick-is.cool/posts/2025/on-vaos/

I still think that OpenGL is a better place to start learning 3D because there is so much less bookkeeping to do regarding memory and concurrency vs. Vulkan. I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...

If you are going to use Vulkan, check out https://howtovulkan.com/ Vulkan started with a lot of compromises to make mobile hardware happy at the expense of making everything overly complicated on desktop. Over the past decade, desktop devs have managed to get a lot of features added to make Vulkan on desktop more sane. How To Vulkan covers that newer approach. This recent video "It's Not About the API" https://www.youtube.com/watch?v=7bSzp-QildA shows how simple it can be if you let it.

And, if you are on a Mac, folks who use Metal like it a lot. Don't worry about lock-in. Once you learn the basics, knowledge is easily transferable to DX12 and Vulkan. You should plan to write 3 or 4 renderers to throw away anyway :P

Writing a Gameboy emulator is a great cure for that ;)

For the joy of building, I'd say LLMs are still great for questions, rapid-prototyping and code reviews. And, beyond that: Who cares what others do? Build what brings you joy.

As @petecordell put it: "Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love."

I'm the opposite. Between work and family, I don't get a lot of time to hole up in a cave with an IDE for fun. Prior to LLMs, it was a struggle to get much of anything done. So, I rarely tried. But, now I can get ideas fleshed out and even get code down in the small breaks I get to myself. Now I'm making progress where I wasn't before.

Sometimes I'm not interested in the inner workings of a technology, I just want a one-off tool. Ex: No interest in web tech. But, vibe-coded a tool to scrape and cross-reference a couple of online reports. Now I have the info I need for other projects.

Sometimes I know exactly what I want and it's quicker to hand-hold the AI through making it for me. Ex: Put together yet another SIMD math lib recently. SIMD intrisics are an obnoxious API. But, a non-SIMD implementation is easy to verify and many SIMD implementations are easy to validate vs. the non-SIMD reference. It's just a huge amount of obtuse code.

Sometimes I don't know exactly what I want and it's great to have a always-online partner to bounce questions off of, do rapid-prototyping for me, do code reviews for me. AIs aren't perfect. But, being instant, patient and often right makes them a huge improvement over online forums.

Lua was specifically designed to be a configuration language https://www.lua.org/history.html

Lots of people start out with a non-programmable config format. But, as their situation becomes more complicated, they end up shoehorning in programmable-ish features until they realize they are running straight into https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule and decide to do it properly.

Classic SSAO is very similar to performing an "unsharp mask" based on the depth buffer. This has been proposed "a simple and efficient method to enhance the perceptual quality of images that contain depth information" in the paper "Image Enhancement by Unsharp Masking the Depth Buffer" which came out a year after SSAO was published by Crytek.

https://www.uni-konstanz.de/mmsp/pubsys/publishedFiles/LuCoD...