corysama

I have been working for a while on a tutorial based on 4.6. When I get close to a first release, I’ll have to ask you for a review :)

My take is that older versions of GL feel nicer to teach to beginner programmers because they have so many specific functions to do each specific thing. You can have a lot of verbose, step-by-step instruction. But, much of what you have to convey is understanding of a convoluted interface to a hidden state machine. And, the one-step-at-a-time nature of the old interfaces build bad habits that don’t scale when you get serious.

With 4.6 we can get Direct State Access, Programmable Vertex Pulling and MultidrawIndirect. With that we can move the complexity from “lots of functions to manipulate a state machine” to a few functions that strongly resemble using malloc and memcpy to work with arrays of structs. That’s not trivial. But, it should be extremely familiar. It’s visible, flexible, scalable, and it sets you up to move on to Vulkan after you’ve learned the essentials of 3D rendering.

Several Amiga/DOS era games used a similar system for image compression.

Motivation doesn't replace working for 60 hours. It causes working for 60 hours.

I’m a cheerleader for the Khanmigo AI tutor effort. But, apparently so far they are discovering that the hard part is getting the kids motivated to actually ask the AI any questions.

3Blue1Brown does an amazing job of making math interesting to learn in itself. As opposed to the hundreds of millions of kids told “You just have to learn it or you’ll be dumb. Keep up or you’ll fall behind forever. Go!”

The vid calls out explicitly that math education is a primarily a motivation problem and I agree. One way or another, we need a lot more focus on that.

Someone could write an OpenGL layer directly on Metal. There have been a few incomplete starts at that.

Meanwhile, writing an OpenGL-on-Vulkan layer has been a plan for deprecating/simplifying driver support for OpenGL for quite a while now. Might as well focus efforts on that.

Being light in every sense of the word is a primary feature of the language.

Lua is great for high-level control of a program written in C/C++. When setting that up, I’ve often appreciated that I could removed features like file I/O from the Lua standard library and the rest keeps on trucking.

Lua is terrible for writing programs by itself. People keep trying to make it happen. But, for anything non-trivial, it’s a fool’s errand.

Seems like a good time to mention that LunarG’s Vulkan-on-Metal wrapper reached Vulkan 1.4 conformance recently.

https://www.lunarg.com/the-state-of-vulkan-on-apple-oct-2026...

Now we need Mesa’s OpenGL-on-Vulkan to be production-ready when running on KosmicKrisp

https://docs.mesa3d.org/drivers/zink.html

Shoutout to https://www.jagregory.com/abrash-black-book/

The tech specifics covered have been out of use for decades. But, it's still a very fun read about thinking through the process of optimization.

Supposedly, SlopShape https://arxiv.org/abs/2609.15369 can ID not just human vs bot but which bot via structural patterns in the writing.

Next we need a "Verbose useless content" detector and we'll be set up to GAN the whole internet into https://xkcd.com/810/ "Mission Accomplished".

Now go remake the Sim City SNES version on the GBA. Astra can apparently make GBA games out of the box. https://www.spritefusion.com/blog/making-a-game-boy-advance-...

Power efficiency.

Long ago I worked on a project where the whole team was so productive I gave myself cubital tunnel from typing so fast for so long. I'd feel needle jabs in my forearms randomly. Like while standing around. Doctor recommended surgery.

Avoiding surgery involved months of finger stretches, forearm massage, 2 keyboards and 2 mice at different elevations, typing with my hands hanging slack like a zombie. It worked. But, even typing this out 20 years later I can still feel the RSI hiding in the shadows. Since then I've avoided RSI by spending 10x more time thinking about code than typing it.

All that is setup for: There have been many times recently where I've thought "I know exactly what I want this code to look like. But, damn. That's going to be a lot of keypresses..." The effort is nothing. Risking nerve damage is the concern.

In those cases I have been thrilled be able to tell AI exactly what to make, how to refactor it, how to clean it up, clean it up more, yet more, still not done. All in less than 10% of the keypresses that would have been required to type it by hand.

I write a lot of C++. A long time ago, I learned the basics of writing assembly. Even though I haven't written much assembly, it still helped me a lot over the years. I understand how it works. I can read the assembly output of my compiler and judge how well my C++ translates to machine actions. I can debug individual assembly instructions when stuff isn't going as planned or the C++ is not available.

I write a lot of high-performance code. To do that, I had to learn the details of how devices (drives/NICs/GPUs) work, how buses (PCI) works, how RAM, CPU caches, instruction pipelining work. Now I know how to structure data flow to work well with the machine instead of against it.

I write a lot of APIs. In doing that, I had to learn the hard way about how different API trade-offs drive client decisions. How to foresee problems in the future stemming from interfaces I'm writing now. How to argue with clients to get them what they need in the long term and not just want they want for the next milestone.

At all of these levels, I had to learn how each level works by doing it. By trying it lots of different ways. And, by optimizing it all the way down from "More productive client discussions" to "More performant assembly instructions" :P

Now whenever I do vibe-code, it's because I know exactly what I want and I can get AI to type it faster and with less RSI (carpal tunnel). Or, I know I want to prototype a few options rapidly before committing to implementing one design for realz. In neither of these cases am I telling the AI "Make it performant and easy to use." Because I know how I want to structure the code to make it performant. And, I know how to set up the API to make it easy to use. So, I'm telling the AI how to structure the data flow and how to set up the API. Because, if I didn't, I'd just be generating a big ball of noisy mud that's neat to gawk at, but has no long-term value.

So, what should you learn? You need to learn how the stuff you are interested in actually works under the hood by experimenting with it manually. Not just "Hey chat, make it work somehow..." You need to focus on architecture and systems thinking because otherwise you won't know how to prevent AI from holding your hand deep into a maze neither of you can escape from. And, you should be spending the majority of your tokens on step-by-step refactoring, never one-shotting. One-shotting is for AI tech demos. Not for learning or production.

Greybeard coder here. There are two separate problems you get to solve. 1) If AI writes your code, you didn't learn anything about the code. 2) If you don't use AI, you won't learn how to use AI. You need to learn how stuff works and how to code well. And, you can't do that passively. If you didn't type it with your own fingers, you didn't learn it. And, that includes learning "How to use AI?"

You want to learn web dev? Start typing HTML and JS. You want to learn how to use AI? Start typing specs and prompts. You'll need to learn both. But, you can't learn web dev by typing specs and prompts.

You can learn using AI as a research assistant, a tutor, a reviewer, a critic. You can use it to bang out quick tools, prototypes, deal with the hassles that are not your focus at the moment. But, whatever you are trying to learn, you need to do the actual implementation manually. There is no such thing as passive learning.

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...