Share this page!

Enter URL or ID to Unroll

You can paste full URL like: https://x.com/threadreaderapp/status/1644127596119195649
or just the ID like: 1644127596119195649

How to get URL link on X (Twitter) App

  1. On the Twitter thread, click on or icon on the bottom
  2. Click again on or Share Via icon
  3. Click on Copy Link to Tweet
  4. Paste it above and click "Unroll Thread"!
  5. More info at Twitter Help
Sebastian Aaltonen Profile picture
Sebastian Aaltonen
@SebAaltonen
Building a new renderer at HypeHype. Former principal engineer at Unity and Ubisoft. Opinions are my own.
Mar 26 • 4 tweets • 1 min read
Alpha clip timings (6K res):

G-buffer:
Discard in main shader: 2.67ms
Two shader variants: 1.86ms (70%)
Binned (discard last): 1.44ms (54%)

Shadows:
2 variants: 0.17ms, 0.10ms, 0.29ms, 0.22ms
Binned: 0.10ms, 0.07ms, 0.27ms, 0.07ms (65%)

Thread... Image Discard in a shader seems innocent, but that makes the GPU driver do crazy shit. Even if you branch out the discard, the driver must be prepared for it, because it doesn't know the runtime state.

Discard can:
- Disable Z-compression / early-Z / Hi-Z
- Fuck up TBDR culling
Mar 20 • 7 tweets • 2 min read
Our new code base uses my Hyper RHI directly in user land code. It's pretty clean. Struct/span based APIs with good defaults. No heap allocs (initializer lists live in stack for the function call duration).

This is how the G-buffer pass looks currently: Image gpu_temp_allocator (and dynamicBindings.allocate) bump allocate persistently mapped GPU memory. CPU pointer directly to GPU VRAM (PCIE-Rebar or UMA). Uniform are directly written to VRAM. No copies at all. Draw stream has only bind group handles and PSO handles (32-bit).
Mar 1 • 5 tweets • 3 min read
It's tempting to give the LLM a MASSIVE system prompt with all the information it needs to perform all the potential task API calls. This way you don't need to think about it and you ensure there's no extra roundtrips for the LLM to find the information/APIs it needs. The problem is that this bloats the token count significantly.

LLM calls (to server) are stateless, you need to send the system prompt (and history) again for every tool call, so that the LLM knows what it was doing and why. If the system prompt is thousands of lines, those lines are resent for every tool call.

Let's discuss the alternatives for a massive system prompt... I already discussed flexible/batchable tool interfaces in this post: x.com/SebAaltonen/st…

There's basically no limit to tool flexiblity. You can go as far as offering tool APIs to run python or terminal commands in the system. Search tools are common. Instead of the LLM going through your project, it can find the info faster. Flexibility and batchability are of course crucial for cutting down the number of roundtrips and the extra data that needs to be transmitted between the system and the LLM. Similar idea as SQL-queries. Do the heavy work locally, minimize external communication.
Nov 2, 2025 • 14 tweets • 3 min read
Wouldn't this be a lovely hosted server for a hobby proto MMO project? 48 core Threadripper, 256GB RAM, 4TB SSD. 1Gbit/s unlimited.

Should be able to handle 10,000 players just fine. That's a start. 1Gbit/s = 100MB/s. 10KB/s send+receive for each player. = great! Image I was talking about 100,000 players before, but that's an aspirational goal for a real MMO game with paid customers. 10,000 players is a fine start point for prototyping. Will be difficult to even get that many players even if it's a free web game (no download).
Nov 1, 2025 • 9 tweets • 2 min read
It's depressing that software engineering mostly wastes the hardware advantages to make programming "easier" and "cheaper" = sloppy code. Every 2 decades we get 1000x faster hardware (Moore).

I'd like to see real improvements, like 1000x more players MP:
If people still wrote code as optimally as me, Carmack and others did in the late 90s, we could achieve things that people today think are not even possible. Those things are not impossible to achieve if we really want. And that's why I think I need to do this hobby project too.
Nov 1, 2025 • 8 tweets • 2 min read
I've been thinking about a 100,000 player MMO recently (1 server, 1 world) with fully distributed physics (a bit like parallel GPGPU physics). Needs a very good predictive data compressor. Ideas can be borrowed from video compressors. 4K = 8 million pixels. I have only 100k... 100k players sending their state to server is not a problem. That's O(n). The big problem is updating every other player state to every player. That's O(n^2). And at 100k players that's 100k*100k = 10G. Server can't obviously send 10G player state infos at acceptable rate.
Oct 23, 2025 • 5 tweets • 1 min read
AI generated C is a real deal. C coders wrote fast & simple code. No high freq heap allocs, no abstractions slowing the compiler down. Lots of good C example code around. Ai workflows need a language with fast iteration time. Why waste compile time and perf on modern languages? If you generate C++ with AI, it will use smart pointers and short lived temp std::vectors and std::strings like all slow C++ code bases do. Lots of tiny heap allocs. Idiomatic Rust is slightly better, but idiomatic Rust is still a lot more heap allocs than C. It's so easy.
Oct 18, 2025 • 17 tweets • 4 min read
Let's discuss why I think 4x4x4 tree is better than 2x2x2 (oct) tree for voxel storage.

It all boils down to link overhead and memory access patterns. L1$ hit rate is the most important thing for GPU performance nowadays.

Thread... 2x2x2 = uint8. That's one byte. Link = uint32 = 4 bytes. Total = 5 bytes.

4x4x4 = uint64. That's 8 bytes. Total (with link) = 12 bytes.

4x4x4 tree is half as deep as 2x2x2 tree. You get up/down twice as fast.
Oct 18, 2025 • 4 tweets • 1 min read
People often think voxels take a lot of storage. Let's compare a smooth terrain. Height map vs voxels.

Height map: 16bit 8192x8192 = 128MB

Voxels: 4x4x4 brick = uin64 = 8 bytes. We need 2048x2048 bricks to cover the 8k^2 terrain surface = 32MB. SVO/DAG upper levels add <10% The above estimate is optimistic. If we have a rough terrain, we end up having two bricks on top of each other in most places. Thus we have 64MB worth of leaf bricks. SVO/DAG upper levels don't increase much (as we use shared child pointers). Total is <70MB. Still a win.
Oct 11, 2025 • 10 tweets • 3 min read
"It's much faster, performance and to load things"

Zuck's reasoning started with performance. Performance matters. Google maps won because of performance, Nokia lost because of Symbian OS not being designed for real-time systems (touchscreen needs it). Unity has to wake up. Performance was also the main reason Unity's Weta Digital acquisition failed. You can't just buy a movie company and believe that real time game engine + movies = real time movies. A massive amount of optimization and architecture refactoring work is required to make it happen.
Sep 30, 2025 • 13 tweets • 3 min read
When you design data structures, always think in cache lines (64B or 128B). You don't want to have tiny nodes scattered around the memory. Often it's better to have wider nodes (preferably 1 cache line each) and shallower structures. Less pointer/offset indirections. When implementing spatial data structures, you also need to think about spatial locality. If you have early outs, then consider embedding early out conditions as a bitfield to the spatial data structure directly, instead of fetching objects before the early out.
Sep 28, 2025 • 17 tweets • 4 min read
What do you guys do when you get a sudden urge to build a 100,000 player MMO with fully destructible world? You do the math that it could run on a single 128 core Threadripper server (everybody in the same world) with your crazy netcode ideas and super well optimized C code... Before Claybook we had a multiplayer prototype with 1GB SDF world state modified with commands (deterministic static world state, undeterministic dynamic object state). Tiny network traffic. Could easily scale this idea to 1TB world (2TB RAM on that Threadripper)...
Sep 26, 2025 • 6 tweets • 1 min read
Finland was a key tech player 20 years ago: We invented SSH and IRC protocols. Nokia was EUs most expensive company, selling more phones yearly than Apple and Samsung sell today combined. We invented the OS that runs most internet servers today. Nokia failed and Linux is free... Finland has some new successes: Wolt being the biggest EU food delivery service, Oura being the first health ring and Silo AI being one of EUs biggest AI companies. Wolt got sold to Doordash ($3.5B), Silo AI got sold to AMD ($665M). Oura is still a $11B Finnish company.
Sep 19, 2025 • 20 tweets • 4 min read
I have realized that there's not that many people out there who understand the big picture of modern GPU hardware and all the APIs: Vulkan 1.4 with latest extensions, DX12 SM 6.6, Metal 4, OpenCL and CUDA. What is the hardware capable of? What should a modern API look like? My "No Graphics API" blog post will discuss all of this. My conclusion is that Metal 4.0 is actually closest to the goal. It has flaws too. DX12 SM 6.6 doesn't have those particular flaws, but has a lot of other flaws. Vulkan has all the flaws combined, with useful extensions :)
May 30, 2025 • 4 tweets • 1 min read
The past decades have been a wonderful time for gamers+devs. The biggest chips, using the latest nodes and trillions worth of R&D, were all targeted at gaming. Now, those chips are needed by professionals (AI). We'll never see a big die GPU at a reasonable price point anymore :( The fun lasted for a very long time, but it's over in both CPU and GPU side. The biggest CPU and GPU dies are no longer designed for gamers. Top end Threadripper costs over 10k$ today. Top end Nvidia B200 costs over 30k$. Few generations ago top tier HW was targeting gamers :(
May 18, 2025 • 9 tweets • 2 min read
Unit tests have lots of advantages, but cons are ignored:
- Code must be split to testable parts. Often requiring more interfaces, which add code bloat and complexity.
- Each call site is a dependency. Test case = +1 dependency. Added inertia to refactor and throw away code.
... - Bloated unit test suites taking several hours to execute. Slows down devs and causes merge conflicts as pushes are delayed.
- Unstable tests randomly failing pushes.
- Unit test maintenance and optimization needed to keep tests manageable. Otherwise developer velocity hurts.
May 7, 2025 • 5 tweets • 2 min read
When you split a function to N different small functions, the reader also suffers multiple "instruction cache" misses (similar to CPU when executing it). They need to jump around the code base to continue reading. Big linear functions are fine. Code should read like a book. Messy big functions with lots of indentation (loops, branches) should be avoided. Extracting is a good practice here. But often functions like this are a code smell. Why do you need those branches? Why is the function doing too many unrelated things? Maybe too generic? Refactor?
Mar 2, 2025 • 27 tweets • 5 min read
Lately there's been a lot of discussion about modern visuals and their trade-offs. @digitalfoundry 's video is a good overview of this debate. Thread about my thoughts...

@digitalfoundry I recently finished FF7 Remake and have 50 hours of playtime in FF7 Rebirth too. It's interesting to compare these two games as they use the same character models, but the first is PS4 game remastered to PS5 and has much more limited environment. While sequel is big open world.
Jan 23, 2025 • 10 tweets • 2 min read
WebGPU CPU->GPU update paths are designed to be super hard to use. Map is async and you should not wait for it. Thus you can't map->write->render in the same frame.

wgpuQueueWriteBuffer runs in CPU timeline. You need to wait for callback to know buffer is not in use.

Thread... Waiting for callback is not recommended in web and there's no API for asking how many frames you have in flight. So you have to dynamically create new staging buffers (in a ring) based on callbacks to use wgpuQueueWriteBuffer safely. Otherwise it will trash data used by GPU.
Jan 22, 2025 • 10 tweets • 3 min read
Refactored our CommandBuffer interface to support compute. Final result:

A compute pass contains N dispatches, just like a render pass contains N draws (split into areas = viewports).

Renderpass object is static (due to Vulkan 1.0). Compute has dynamic write resource list. Image This is how you would use the API to dispatch a compute pass with a single compute shader writing to two SSBOs. Image
Dec 17, 2024 • 6 tweets • 2 min read
I would really love to write a blog post about this whole debate. This is a too complex topic to discuss on Twitter.

Ubisoft was among the first to develop GPU-driven rendering and temporal upscaling. AC: Unity, Rainbow Six Siege, For Honor, etc. Our SIGGRAPH 2015 talk, etc... Originally, TAA was seen as an improvement over screen space post-process AA techniques as it provided subpixel information. It wasn't just a fancy blur algo. Today, people render so much noise. Noise increases neighborhood bbox/variance. Which increases ghosting.