Sebastian Aaltonen

sebastianaaltonen.comNo Graphics API — Sebastian AaltonenGraphics APIs and shader languages have significantly increased in complexity over the past decade. It’s time to start discussing how to strip down the abstractions to simplify development, improve pe...

16 Dec 2025

My "No Graphics API" blog post is live! Please repost :) www.sebastianaaltonen.com/blog/no-grap... I spend 1.5 years doing this. Full rewrite last summer and another partial rewrite last month. As Hemingway said: "First draft of everything is always shit".

16 Dec 2025

16 Dec 2025

I ended up writing an API in the end of the blog post titled "No Graphics API". At least my API has only 150 lines of code. In comparison WebGPU is 2700 lines and Vulkan is over 20,000. But "5% API" isn't as catchy title as "No API" :)

19 Dec 2024

"Parkour City" was one of the first bigger games in HypeHype. It looked pretty bad two years ago. With our new renderer, this game today looks pretty good. I did a minor remix: Changed the visual style preset and tweaked the sun and fog settings.

19 Dec 2024

This game doesn't have any textures. This is true for most of the games on the platform currently. Texture support is a recent addition, and we are going to add lots of new texturing features in January / February.

14 Dec 2024

For most people, virtual texturing is a streaming tech. For me, it's always been a way for the GPU to access all texture data simultaneously -> max batching + no binding cost. VT is a surface cache for the visible pixel data set. Caches your material blending and decals -> big perf win.

blog.s-schoener.comUnity Burst and the kernel theory of video game performanceHey! You can find me on Mastodon, Bluesky, or Twitter! Burst of number four, Unity Drive, was proud to say that it was perfectly normal, thank you very much. It was the last compiler you’d expect to b...

14 Dec 2024

This is why we have virtual texturing in HypeHype. Our games are tiny (10MB), so we don't need to stream anything. However, we still implemented virtual texturing to improve our CPU and GPU performance. It also solves material variety and tiling issues (fast material blending and decaling).

Sebastian Aaltonen reposted

Bart Wronski 🇺🇦🇵🇸

@bartwr.bsky.social

13 Dec 2024

My hot take is that promotion of ECS and "kernelization" were one of the most harmful ideas in game programming. They apply only selectively, and were preached like a religion by angry individuals "if you don't do it, you are incompetent, silly or lazy, and your performance will suck!"

Sebastian Schöner @sschoener.bsky.social

Why do I have to wait so long for Burst to compile things? Or, "Unity Burst and the Kernel Theory of video game performance": blog.s-schoener.com/2024-12-12-b...

youtube.comGothicYouTube video by Danq

12 Dec 2024

Our tech artist did a test scene with our forthcoming virtual texturing system. This scene uses just three 256x256 PBR materials (3 textures each). Total memory consumption (ASTC4x4/BC7) = 0.56MB Total storage cost (2bpp AVIF) = 144KB www.youtube.com/watch?v=IjlE...

12 Dec 2024

This demo doesn't yet have a virtual texture decaling system. It will make it possible to add lots of texture variety with minimal storage cost. But it's possible to make pretty good-looking results even with just a couple of traditional tiling textures.

Sebastian Aaltonen reposted

Tomasz Stachowiak

@h3r2tic.bsky.social

In our next Tiny Glade update we'll bump the light limit from 32 to 32k while keeping the cost more or less the same. The small limit has been a cop out, as we didn't quite know how to render huge numbers of (screen-space) shadow-casting lights without severe performance degradation.

6 Dec 2024

3->4 shadow cascades performance (M3 Max): 3 cascades: Vertex = 0.20ms Pixel = 0.07ms 4 cascades: Vertex = 0.39ms (195%) Pixel = 0.11ms (157%) On M3 Max, a total cost of 0.5ms for good-looking shadows is a no-brainer. However, a 185% cost is too much for low- and mid-tier phones.

6 Dec 2024

The measurements were done in a large scene (formula track). A total of 2 million triangles were rendered with 4 cascades and 1.8 million with 3 cascades.

Sebastian Aaltonen reposted

Tomasz Stachowiak

@h3r2tic.bsky.social

youtube.comRendering Tiny Glades With Entirely Too Much Ray MarchingYouTube video by Graphics Programming Conference

Here's a recording of my Tiny Glade presentation from the Graphics Programming Conference 2024: www.youtube.com/watch?v=jusW... It's an any% speedrun of our GPU-driven rendering, shadows, global illumination, water, and DoF, involving a few weird tricks.

Today, I added storage buffer support to HypeHype RHI and all the backends: WebGPU, Metal, and Vulkan. I tested changing some shaders to SSBO instead of UBO. Works on all platforms! Metal was the easiest. Buffers are just GPU pointers in Metal. There's no UBO or SSBO. Zero changes...

View full thread

DX12 has a complete buffer zoo: constant buffers, structured buffers, raw buffers, append buffers, typed buffers, SRV, and UAV of each. Of course, there are also vertex buffers and index buffers. Sane APIs like Metal and CUDA just use a GPU pointer.

My "No Graphics API" blog post will include chapters discussing the "buffer zoo" and its history. Why did we end up with this mess instead of the clean future we can already start to see with Metal 2.0, CUDA, and similar modern APIs?

View full thread

Vulkan required the SSBO type to be in the descriptor set layout. And I added SSBO descriptors into descriptor pools. We have one persistent pool and two temp pools, one per active frame (2). The active temp descriptor pool is reset every frame, and now it also has SSBO descriptors.

This is yet another example where it's clear that Metal API and MSL are more modern compared to HLSL/GLSL and Vulkan/DX12. In Metal every buffer is just a 64-bit GPU pointer. There's no buffer zoo. Every buffer is just a buffer and bound the same way, including argument buffers.

WebGPU required an RHI change. WebGPU only allows read-only SSBO binding in vertex shaders (due to mobile GPUs splitting vertex shader to position+attribute shader, side-effects would break it). WebGPU requires a bind group layout to declare read-only binding, and it's validated against the shader.

Added fourth shadow cascade for high-end devices. This is how it looks at medium distance (cascade 2): Left = 3 cascades Right = 4 cascades (click to enlarge, left/right arrows to toggle)

View full thread

Crow of the first image (medium distance). Four shadow cascades (right) looks much nicer.

It seems that Bluesky doesn't support editing posts. This is stupid. It would be convenient if they allowed small typo fixes for 5 minutes and then locked the post.

Added fourth shadow cascade for high-end devices. This is how it looks at medium distance (cascade 2): Left = 3 cascades Right = 4 cascades (click to enlarge, left/right arrows to toggle)

@kostasanagnostou.bsky.social

Close-up (cascade 1): The shadow map atlas is 4096x4096 pixels on PC. Each cascade is a 2048x2048 region. We render them in a single pass, changing the viewport rect between cascades.

Sebastian Aaltonen reposted

Kostas Anagnostou

2 Dec 2024

Trying the tiny MLP in more locations (left) vs the spherical 10m visibility it is "learning" from (right). The one node hidden layer can only coarsely approximate the visibility signal and only in one broad direction. Also not all probes manage to converge in a reasonable time.

Kostas Anagnostou@kostasanagnostou.bsky.social

Comparing a small (1 node hidden layer) MLP (top) with an L2 Spherical Harmonics (bottom) encoding of raytraced visibility (left). The 6 floats MLP appears to capture occlusion better that the 9 floats SH.

3 Dec 2024

Today we managed to switch our Flutter web build to use WASM. It's at least 3x faster. Our game engine was already using WASM. When combined with my recent WebGPU gfx backend and Jolt physics with WASM SIMD, our new web build feels almost like the native build now :)

2 Dec 2024

“The first draft of anything is shit.” - Ernest Hemingway He was absolutely right. Every time I write a presentation I get that feeling. Takes a full rewrite + several polish passes to make anything feel good. Same is happening with my "No Graphics API" blog post...

2 Dec 2024

Fortunately I am already doing the rewrite and some chapters are starting to feel good.

Now that we shipped WebGPU and Android will be 100% Vulkan soon, we started designing compute shader pipeline. GPU-driven rendering, virtual shadow maps, compute stochastic lighting, etc. But this is not without issues on mobile. I worry about vertex work overlap...

This is how vertex work overlaps with pixel work currently. We setup barriers in Vulkan and Metal to only block pixel work. This is approx 20% perf gain on G57 when heavy vertex work overlaps previous frame. On Apple (left) 10%, but more if heavily GPU bound.

github.com16 Bit Scalar TypesThis repo hosts the source for the DirectX Shader Compiler which is based on LLVM/Clang. - microsoft/DirectXShaderCompiler

I have been writing a massive blog post titled "No Graphics API" for a few months. Question to the gfx programmers: If you are using texel buffers (Buffer<T> in HLSL), why do you use them over raw buffers? SM 6.2 added 16 bit support and buffer.Load<T>(offset)? github.com/microsoft/Di...

@kostasanagnostou.bsky.social

For Metal/Vulkan/GL users. I am talking about texel buffers. If you are using texel buffer, what's the reason for that? Are you aware that modern GPUs can load 8 bit and 16 bit values from SSBO directly (doesn't apply to older Android phones)?

Sebastian Aaltonen reposted

Kostas Anagnostou

medium.com“CPU-Limited” Games & BenchmarksEvery CPU launch season is inevitably followed by gamers complaining about contrived benchmarks and reviewers defending their methodology…

“CPU-Limited” Games & Benchmarks medium.com/@opinali/cpu...

Just pushed my WebGPU gfx backend to production. Took 21 days to develop in total: native Dawn Mac + Windows first, then Emscripten for web. Runs really smoothly on the browser and the page load is super fast. Zero issues on Mac, Windows or Chrome. Safari Tech Preview has some flickering tris.

The web version of HypeHype doesn't yet have threading. We will investigate that soon. Native versions (Mac, Windows, Android, iOS) are fully threaded of course. This is why there's a stall between game loading in web. Native feed is 100% smooth (preload next game in thread).

User-generated content (UGC) in a nutshell: Massive spam of physics objects and skinned characters. Runs at locked 60Hz well on modern phones. The problem is cheap 99€ Android phones with PowerVR GE8320 :(

Another one :)

It's great that users can express themselves by spamming content. Engines targeting UGC should optimize for big N use cases. Kitbashing is super common technique in UGC.

Does BluSky support 60Hz videos? Video was smooth when I downloaded it but playback feels laggy.

Have been tuning HypeHype's custom GTAO implementation for two days: Morton sampling pattern, bilateral blur uses slope-based weight (instead of constant Z), 2x2 depth downsample passes use median (instead of max). Still work to do, but starts to look pretty good. Game: "Block City" by Blue Mint

This is how fast the GTAO runs on Mali G57 MP2. This phone GPU is roughly 5x slower than iPhone 6s (9 year old flagship).

We are leaning on GTAO a lot, as there's no baked lighting. Games have to be <10MB each. There's simply no room to store any baked lighting data. And you can press a button to start remixing any game. Everything can be modified. Baked lighting doesn't really work for us.