diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-EskilSteenberg-make-it-happen-what-shader-format-are-you.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-EskilSteenberg-make-it-happen-what-shader-format-are-you.md new file mode 100644 index 0000000..ceeb3bb --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-EskilSteenberg-make-it-happen-what-shader-format-are-you.md @@ -0,0 +1,71 @@ +--- +title: "@SebAaltonen Make it happen! What shader format are you thinking? Spir-V? I like that in OpenGL i can easily write a tool that generates shaders without the need to be dependent on a compiler library to use it, but i would assume that time has passed." +type: archive +source: twitter +source_url: "https://x.com/EskilSteenberg/status/2001077725734240398" +author: "Eskil Steenberg" +handle: EskilSteenberg +post_id: "2001077725734240398" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Make it happen! What shader format are you thinking? Spir-V? I like that in OpenGL i can easily write a tool that generates shaders without the need to be dependent on a compiler library to use it, but i would assume that time has passed." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/EskilSteenberg/status/2001077725734240398 +- Author: Eskil Steenberg (@EskilSteenberg) +- Posted: 2025-12-16 23:51:22 + +## Branch + +**1/** **@EskilSteenberg** ^2001077725734240398 + +**@SebAaltonen** + +Make it happen! What shader format are you thinking? Spir-V? I like that in OpenGL i can easily write a tool that generates shaders without the need to be dependent on a compiler library to use it, but i would assume that time has passed. + +**2/** **@JoaoBapt** ^2001551866682052865 + +**@EskilSteenberg** **@SebAaltonen** + +That could probably be implemented on top of amdgpu directly, or Mesa, not sure, but it would only work on Linux and AMD, since Nvidia has their own proprietary drivers. + +**3/** **@SebAaltonen** ^2001558855592157294 + +**@JoaoBapt** **@EskilSteenberg** + +The biggest issue on building it on top of Vulkan is that GLSL/HLSL don't have pointers. Vulkan BDA extension is using raw 64-bit integers and the BDA syntax in GLSL is messy. C/C++ based shading language similar to CUDA and MSL would be nice. Or a Rust based if you prefer that. + +**4/** **@SebAaltonen** ^2001559152737366107 + +**@JoaoBapt** **@EskilSteenberg** + +SPIRV supports pointers just fine. That's not the limitation. We just need a new shader language, or somebody needs to write MSL->SPIRV tooling. The other way exists already. + +**5/** **@EskilSteenberg** ^2001570355497046520 + +**@SebAaltonen** **@JoaoBapt** + +If C would have added vectors when SIMD became common in CPUs 25 years ago, C would be the dominant shading language. I still think thats the right way to go. Just use C and add an extension for vectors. + +**6/** **@SebAaltonen** ^2001574372524331051 + +CUDA, OpenCL and Metal MSL are all C/C++ based languages. They are still used. GLSL/HLSL are only relevant for graphics shaders. Nvidia is 90% AI company today. CUDA is more relevant than graphics for them. I think we should leverage the AI ecosystems more instead of writing ad-hoc graphics shader languages. GLSL/HLSL have practically no library ecosystem. + +**7/** **@EskilSteenberg** ^2001577597948563735 + +**@SebAaltonen** **@JoaoBapt** + +Id like it to be ISO C with an extension, rather than C-like to leverage existing C tooling. (And perhaps make shader language like vectors defacto standard in C) + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-Sebasti66855537-finally.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-Sebasti66855537-finally.md new file mode 100644 index 0000000..54de316 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-Sebasti66855537-finally.md @@ -0,0 +1,45 @@ +--- +title: "@SebAaltonen Finally!" +type: archive +source: twitter +source_url: "https://x.com/Sebasti66855537/status/2001043125112873165" +author: "Sebastian Castellanos" +handle: Sebasti66855537 +post_id: "2001043125112873165" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Finally!" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/Sebasti66855537/status/2001043125112873165 +- Author: Sebastian Castellanos (@Sebasti66855537) +- Posted: 2025-12-16 21:33:53 + +## Branch + +**1/** **@Sebasti66855537** ^2001043125112873165 + +**@SebAaltonen** + +Finally! + + + +**2/** **@SebAaltonen** ^2001046197805502694 + +**@Sebasti66855537** + +I deserved that :D + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-archo5dev-from-what-ive-been-able-to-find-from-public-info.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-archo5dev-from-what-ive-been-able-to-find-from-public-info.md new file mode 100644 index 0000000..82de667 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-archo5dev-from-what-ive-been-able-to-find-from-public-info.md @@ -0,0 +1,93 @@ +--- +title: "@SebAaltonen from what I've been able to find from public info, many APIs (e.g." +type: archive +source: twitter +source_url: "https://x.com/archo5dev/status/2001013865283510527" +author: "Arvīds Kokins" +handle: archo5dev +post_id: "2001013865283510527" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen from what I've been able to find from public info, many APIs (e.g." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/archo5dev/status/2001013865283510527 +- Author: Arvīds Kokins (@archo5dev) +- Posted: 2025-12-16 19:37:37 + +## Branch + +**1/** **@archo5dev** ^2001013865283510527 + +**@SebAaltonen** + +from what I've been able to find from public info, many APIs (e.g. the console APIs) still don't have PSOs (https://gist.github.com/archo5/53611ab2b8dcf6d784a9a032aa1b6664#not-how-gpus-do-things) + +I'd say PSOs should be destroyed completely, instead opting for separate narrow per-shader optimization (DCE) functions + +![](https://pbs.twimg.com/media/G8UF699W0AQFtr-?format=png&name=orig) + +**2/** **@SebAaltonen** ^2001020440274461071 + +**@archo5dev** + +You can't compile microcode for all the vendors and all their GPU models. That would bloat your shader compile times during development and shader binary size by 100x+. And vendors couldn't improve their shader codegen by patching the drivers. + +**3/** **@archo5dev** ^2001023348181217522 + +**@SebAaltonen** + +I'm not proposing compiling all vendor-specific machine code at dev time. + +Instead: 1) each shader/stage is compiled separately; 2) where optimizations are needed, each compilation step is given as much of the necessary specialized context as the application is able to provide. + +**4/** **@archo5dev** ^2001035724854903191 + +**@SebAaltonen** + +basically like in the image but e.g. in the case of a vertex shader, you could optionally pass the input layout from the next stage so DCE could remove all the code that's exclusive to unused inputs +so any 2 shaders compiled with the same cross-stage layout could be used together + +![](https://pbs.twimg.com/media/G8UZu94WkAQXQ6g?format=png&name=orig) + +**5/** **@archo5dev** ^2001036925424046575 + +**@SebAaltonen** + +this would also have the added benefit that if one wanted to fully optimize all shaders, there would only be as many shader compilations as there are unique input/output layouts per shader, typically less than every VS & PS combination (which is what a PSO inherently requires) + +**6/** **@SebAaltonen** ^2001366852652634249 + +Splitting VS and PS is a good idea. In the blog post I discuss about splitting depth-stencil state object and blend state object (as those are separate command packets on most GPUs). Splitting requires defining channel masks on both the PSO and blend state. Similarly you could define the VS<->PS interface and compile those shaders separately. + +**7/** **@SebAaltonen** ^2001377928404439503 + +**@archo5dev** + +You are right that PS<->VS interface optimization isn't a big deal. It helps in some corner cases only. Would be better to separate them too. Makes validation a bit worse as validation will happen at pixel/vertex shader bind time instead of pipeline create time. + +**8/** **@archo5dev** ^2001380683210723565 + +**@SebAaltonen** + +I suspect the biggest typical benefit from the interface optimization might be with depth-only passes - but they're also very easy to DCE by hand with a preprocessor. +Overall it's hard to imagine cases which would benefit from DCE and hard to optimize manually. + +**9/** **@archo5dev** ^2001381756524749307 + +**@SebAaltonen** + +I'm thinking that validation (debug-only) would probably have to be in the first draw call with the new VS/PS pair, comparing IDs from a cross-stage layout hash table: at shader compilation time, every layout could acquire an ID unique to that layout, later they're only compared. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-ecoezen-its-been-a-great-read-a-long-but-great-thanks-for.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-ecoezen-its-been-a-great-read-a-long-but-great-thanks-for.md new file mode 100644 index 0000000..39800c4 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-ecoezen-its-been-a-great-read-a-long-but-great-thanks-for.md @@ -0,0 +1,39 @@ +--- +title: "@SebAaltonen It's been a great read." +type: archive +source: twitter +source_url: "https://x.com/ecoezen/status/2001058765651468603" +author: "Can" +handle: ecoezen +post_id: "2001058765651468603" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen It's been a great read." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/ecoezen/status/2001058765651468603 +- Author: Can (@ecoezen) +- Posted: 2025-12-16 22:36:02 + +## Branch + +**1/** **@ecoezen** ^2001058765651468603 + +**@SebAaltonen** + +It's been a great read. a long but great. thanks for ruining my plans for the night lol + +I have hope for SYCL and heterogeneous programming ideas in general, so we may even achieve "No Graphics API" one day, not locked in vendors, as foretold by the prophecy... + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-fedyac-minor-nitpick-the-trick-of-packing-depth-and.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-fedyac-minor-nitpick-the-trick-of-packing-depth-and.md new file mode 100644 index 0000000..5e111fd --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-fedyac-minor-nitpick-the-trick-of-packing-depth-and.md @@ -0,0 +1,49 @@ +--- +title: "@SebAaltonen Minor nitpick: The trick of packing depth and color into a 64-bit integer and using an atomicMin to emulate the depth test had already been used in 2014 by @pixeljetstream one year before Dreams and a long time before Nanite 😉" +type: archive +source: twitter +source_url: "https://x.com/fedyac/status/2001074930469703725" +author: "Fedy ABI-CHAHLA" +handle: fedyac +post_id: "2001074930469703725" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Minor nitpick: The trick of packing depth and color into a 64-bit integer and using an atomicMin to emulate the depth test had already been used in 2014 by @pixeljetstream one year before Dreams and a long time before Nanite 😉" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/fedyac/status/2001074930469703725 +- Author: Fedy ABI-CHAHLA (@fedyac) +- Posted: 2025-12-16 23:40:16 + +## Branch + +**1/** **@fedyac** ^2001074930469703725 + +**@SebAaltonen** + +Minor nitpick: The trick of packing depth and color into a 64-bit integer and using an atomicMin to emulate the depth test had already been used in 2014 by @pixeljetstream one year before Dreams and a long time before Nanite 😉 + +![](https://pbs.twimg.com/media/G8U_CvqXYAIy7s2?format=jpg&name=orig) + +**2/** **@SebAaltonen** ^2001198438206103958 + +Media Molecule Dreams presentation was at SIGGRAPH 2015. They spent years on the tech, so I would assume they used the uint64 atomic trick before 2014. I presented Ubisoft GPU-driven renderer publicly also at SIGGRAPH 2015, but had internal UDC (Ubisoft Developer Conference) presentations at 2013 and 2014. Tech like this has usually at least 2 year lead time before surfacing publicly. @mmalex also told me that they had independently came up with the same two-phase occlusion culling algorithm that I presented at SIGGRAPH 2015. Maybe Alex wants to comment on this. + +**3/** **@fedyac** ^2001204502775361603 + +**@SebAaltonen** **@pixeljetstream** + +Indeed, in this kind of situation it’s always difficult to know who is really behind the trick. It’s so simple yet so clever and in the end it hardly matters who came up with it. In fact, I just wanted to take the opportunity to highlight the great work of @pixeljetstream + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-goddtriffin-congrats-on-getting-this-out-in-the-world-i-can.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-goddtriffin-congrats-on-getting-this-out-in-the-world-i-can.md new file mode 100644 index 0000000..192fca2 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-goddtriffin-congrats-on-getting-this-out-in-the-world-i-can.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen Congrats on getting this out in the world! I can only imagine the relief to finally have all of these thoughts out of your head and consumable for others" +type: archive +source: twitter +source_url: "https://x.com/goddtriffin/status/2001047381065011337" +author: "Todd Griffin" +handle: goddtriffin +post_id: "2001047381065011337" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Congrats on getting this out in the world! I can only imagine the relief to finally have all of these thoughts out of your head and consumable for others" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/goddtriffin/status/2001047381065011337 +- Author: Todd Griffin (@goddtriffin) +- Posted: 2025-12-16 21:50:47 + +## Branch + +**1/** **@goddtriffin** ^2001047381065011337 + +**@SebAaltonen** + +Congrats on getting this out in the world! I can only imagine the relief to finally have all of these thoughts out of your head and consumable for others + +**2/** **@SebAaltonen** ^2001280832074371335 + +**@goddtriffin** + +I already thought about writing this when I was working at Unity, but then I joined HypeHype to rewrite all their render backends (Vulkan, Metal, WebGPU) and I have accumulated more pain inside me that had to be released. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-m_schuetz-a-shoutout-to-nv-shader-buffer-load-which-already.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-m_schuetz-a-shoutout-to-nv-shader-buffer-load-which-already.md new file mode 100644 index 0000000..1ec3004 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-m_schuetz-a-shoutout-to-nv-shader-buffer-load-which-already.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen A shoutout to NV_shader_buffer_load which already enabled buffer device address with c-pointer syntax in GLSL and OpenGL in, I think, 2010." +type: archive +source: twitter +source_url: "https://x.com/m_schuetz/status/2001011006219411840" +author: "Markus Schütz" +handle: m_schuetz +post_id: "2001011006219411840" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen A shoutout to NV_shader_buffer_load which already enabled buffer device address with c-pointer syntax in GLSL and OpenGL in, I think, 2010." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/m_schuetz/status/2001011006219411840 +- Author: Markus Schütz (@m_schuetz) +- Posted: 2025-12-16 19:26:15 + +## Branch + +**1/** **@m_schuetz** ^2001011006219411840 + +**@SebAaltonen** + +A shoutout to NV_shader_buffer_load which already enabled buffer device address with c-pointer syntax in GLSL and OpenGL in, I think, 2010. It's a fantastic extension hidden behind a spec description that obfuscates the quality of life for its users. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-BlurBusters-very-nice-how-big-do-you-think-the-webgl-header.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-BlurBusters-very-nice-how-big-do-you-think-the-webgl-header.md new file mode 100644 index 0000000..d776f24 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-BlurBusters-very-nice-how-big-do-you-think-the-webgl-header.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen Very nice! How big do you think the WebGL header would be? Just for completeness' sake, e.g." +type: archive +source: twitter +source_url: "https://x.com/BlurBusters/status/2001185096464757001" +author: "Blur Busters" +handle: BlurBusters +post_id: "2001185096464757001" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Very nice! How big do you think the WebGL header would be? Just for completeness' sake, e.g." +in_reply_to: "" +parent_post_id: "2001003366764437801" +--- + +## Source + +- URL: https://x.com/BlurBusters/status/2001185096464757001 +- Author: Blur Busters (@BlurBusters) +- Posted: 2025-12-17 06:58:01 + +## Branch + +**1/** **@BlurBusters** ^2001185096464757001 + +**@SebAaltonen** + +Very nice! How big do you think the WebGL header would be? Just for completeness' sake, e.g. engineering for legacy browser use (e.g. average FireTV stick) + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-one-thought-that-came-to-my-mind-would-it-be.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-one-thought-that-came-to-my-mind-would-it-be.md new file mode 100644 index 0000000..67b4b5a --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-one-thought-that-came-to-my-mind-would-it-be.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen One thought that came to my mind, would it be preferable to have something akin to virtual alloc vs malloc for gpus? Its not a huge difference, but it does open up some opportunities (easy arenas, sparse buffers, extra mapped ring buffers, etc)?" +type: archive +source: twitter +source_url: "https://x.com/ISzlachtycz/status/2001218056467484857" +author: "Ihor_Szlachtycz 🇺🇦" +handle: ISzlachtycz +post_id: "2001218056467484857" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen One thought that came to my mind, would it be preferable to have something akin to virtual alloc vs malloc for gpus? Its not a huge difference, but it does open up some opportunities (easy arenas, sparse buffers, extra mapped ring buffers, etc)?" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/ISzlachtycz/status/2001218056467484857 +- Author: Ihor_Szlachtycz 🇺🇦 (@ISzlachtycz) +- Posted: 2025-12-17 09:09:00 + +## Branch + +**1/** **@ISzlachtycz** ^2001218056467484857 + +**@SebAaltonen** + +One thought that came to my mind, would it be preferable to have something akin to virtual alloc vs malloc for gpus? Its not a huge difference, but it does open up some opportunities (easy arenas, sparse buffers, extra mapped ring buffers, etc)? + +**2/** **@SebAaltonen** ^2007110514221134175 + +**@ISzlachtycz** + +Yes. I had thoughts about virtual malloc, but removed in cleanup. GPU vendors have different page sizes and tiled textures have different layouts. Lots of complexity there. Would need deeper dive on that topic and I just didn't have time to do write about that. Scope bloat... + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-this-was-a-great-post-i-agree-with-almost.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-this-was-a-great-post-i-agree-with-almost.md new file mode 100644 index 0000000..12cb5c2 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-this-was-a-great-post-i-agree-with-almost.md @@ -0,0 +1,115 @@ +--- +title: "@SebAaltonen This was a great post! I agree with almost everything you wrote." +type: archive +source: twitter +source_url: "https://x.com/ISzlachtycz/status/2001201742650716164" +author: "Ihor_Szlachtycz 🇺🇦" +handle: ISzlachtycz +post_id: "2001201742650716164" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen This was a great post! I agree with almost everything you wrote." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/ISzlachtycz/status/2001201742650716164 +- Author: Ihor_Szlachtycz 🇺🇦 (@ISzlachtycz) +- Posted: 2025-12-17 08:04:10 + +## Branch + +**1/** **@ISzlachtycz** ^2001201742650716164 + +**@SebAaltonen** + +This was a great post! I agree with almost everything you wrote. One thing that really frustrates me about the industry is how everyone has to write their own basic debugging features, most of which suck. 1/n + +**2/** **@ISzlachtycz** ^2001202055973597425 + +**@SebAaltonen** + +As a starter, DX13 needs shader printfs. Ideally, you could choose a target memory address to write to, or use an exposed default backing buffer created by the driver that persists even after device reset. 2/n + +**3/** **@ISzlachtycz** ^2001202284735221949 + +**@SebAaltonen** + +I believe that in DX12 you can allocate pages such that writing to a GPU buffer automatically writes to a file on disk. This is essential for any real logging framework. Breadcrumbs in my mind arent enough 3/n + +**4/** **@ISzlachtycz** ^2001202381699027019 + +**@SebAaltonen** + +It would also be nice to finally have some level of debugger support, even if it requires having a second gpu to avoid TDR issues. This ties in with forward progress guarantees, but ill start with debugging. For me, there are 3 classes of gpu problems we want to debug: 4/n + +**5/** **@ISzlachtycz** ^2001202495004061968 + +**@SebAaltonen** + +1) Single thread debugging: we mainly care about debugging the logic of a single thread thats not interacting in a direct way with other threads. This i think covers 80% of debugging needs. 5/n + +**6/** **@ISzlachtycz** ^2001202670372004027 + +**@SebAaltonen** + +2) thread group level sync problems: this is for problems were your shader writes to lds or does some wave ops. In this case, you need to simulate or run a whole thread group and you want to provide the user with its state to understand how its syncing/executing. 6/n + +**7/** **@ISzlachtycz** ^2001202978527531260 + +**@SebAaltonen** + +3) Gpu wide sync problems: this is for problems where youre using global atomics to sync across all or many thread groups. In this case, you need your entire workload frozen, in order to debug correctly. This can cause nasty TDR/freezing issues but is not very common a problem7/n + +**8/** **@ISzlachtycz** ^2001203120706081231 + +**@SebAaltonen** + +For 1 and 2, you can pin those workloads onto the gpu, and as long as you have WGP/CU level forward progress guarantees, this wont hang your system and other processes can keep executing and finishing work. 8/n + +**9/** **@ISzlachtycz** ^2001203192948826407 + +**@SebAaltonen** + +For 3, you would need something like on CPUs where waves/warps can be saved to memory, and restored later when you step or F5. I dont think anyone supports that now, so youd probably need a second gpu for that kind of workload. 9/n + +**10/** **@ISzlachtycz** ^2001203696642740295 + +**@SebAaltonen** + +Right now, writing a spin lock is undefined behavior in hlsl. With forward progress, thats not a problem, and you can even add a intrinsic to sleep the wave in a lock, to let other waves do work. 10/n + +**11/** **@ISzlachtycz** ^2001203767539081561 + +**@SebAaltonen** + +With proper debugger support, you can traps for asserts that arent weird hacks but just part of the api and detected correctly by debuggers. 11/n + +**12/** **@ISzlachtycz** ^2001203919821680757 + +**@SebAaltonen** + +For 3), if we have proper logging in the apis by default (or atleast supported on a lang level), that can already give you traces to debug if youre on a single gpu setup, which at least gives you some feedback. 12/n + +**13/** **@ISzlachtycz** ^2001204089200210407 + +**@SebAaltonen** + +Its just crucial these buffers exist after the gpu TDRs in whatever way, so you dont lose all the data. End of rant 13/13. Again, great post, was a pleasent read :) + +**14/** **@SebAaltonen** ^2001210417339654420 + +**@ISzlachtycz** + +Yeah, debugging should indeed be improved. Hopefully somebody else has the time and energy to write a blog post about that topic. The shader framework also needs a big discussion. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoNax_97-read-it-in-one-gom-i-even-understood-some-of-it.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoNax_97-read-it-in-one-gom-i-even-understood-some-of-it.md new file mode 100644 index 0000000..37ca518 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoNax_97-read-it-in-one-gom-i-even-understood-some-of-it.md @@ -0,0 +1,39 @@ +--- +title: "@SebAaltonen Read it in one gom I even understood some of it! " +type: archive +source: twitter +source_url: "https://x.com/JoNax_97/status/2001088604622164148" +author: "Joaco Munix" +handle: JoNax_97 +post_id: "2001088604622164148" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Read it in one gom I even understood some of it! " +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/JoNax_97/status/2001088604622164148 +- Author: Joaco Munix (@JoNax_97) +- Posted: 2025-12-17 00:34:36 + +## Branch + +**1/** **@JoNax_97** ^2001088604622164148 + +**@SebAaltonen** + +Read it in one gom I even understood some of it! + +Quick question: for us mere engine users, is there advantage that we could get from a new API like this? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoaoBapt-as-the-heap-management-in-metal-is-automatic.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoaoBapt-as-the-heap-management-in-metal-is-automatic.md new file mode 100644 index 0000000..626d602 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoaoBapt-as-the-heap-management-in-metal-is-automatic.md @@ -0,0 +1,82 @@ +--- +title: "@SebAaltonen “As the heap management in Metal is automatic, users can’t allocate texture descriptors in contiguous ranges.”" +type: archive +source: twitter +source_url: "https://x.com/JoaoBapt/status/2001189382359781675" +author: "João Baptista 🇧🇷" +handle: JoaoBapt +post_id: "2001189382359781675" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen “As the heap management in Metal is automatic, users can’t allocate texture descriptors in contiguous ranges.”" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/JoaoBapt/status/2001189382359781675 +- Author: João Baptista 🇧🇷 (@JoaoBapt) +- Posted: 2025-12-17 07:15:03 + +## Branch + +**1/** **@JoaoBapt** ^2001189382359781675 + +**@SebAaltonen** + +“As the heap management in Metal is automatic, users can’t allocate texture descriptors in contiguous ranges.” + +Check out texture view pools, they allow for *some* manual manipulation of the texture heap: https://developer.apple.com/documentation/metal/mtltextureviewpool?language=objc + +**2/** **@SebAaltonen** ^2001247130011492521 + +**@JoaoBapt** + +I'll check. Seems to be a brand new iOS26/MacOS26 feature. + +The main idea of DX12 SM6.6 heap is that it's global. User never needs to bind it. All shaders see all textures all the time and shaders can calculate indices in the way that's most optimal. + +**3/** **@SebAaltonen** ^2001256866203230585 + +**@JoaoBapt** + +The new iOS26/MacOS26 TextureViewPool seems promising indeed. Can you create a single big pool for all your textures, similar to a SM6.6 descriptor heap? Is it performance optimal way to access all textures? + +**4/** **@SebAaltonen** ^2001258734165619189 + +If I understood it correctly, your driver internally allocates N contiguous descriptors for each TextureViewPool in your driver's internal descriptor heap. I can ask the gpuResourceID of the first texture in the pool to know the pool's base offset in the driver managed descriptor heap? + +MSL now allows adding integer offset to texture2d like it was a pointer? + +Basically implementing DX12 SM6.6 style heap would be possible if I allocate a one massive Metal 4 TextureViewPool and ask the gpuResourceID of the first slot. I route this baseTextureID to the shader using some side channel and add it to the texture heap index. This should work? + +**5/** **@SebAaltonen** ^2001262834152612344 + +**@JoaoBapt** + +Can't find any information of adding a integer index on a base texture2d in the shader. It's definitely doable in CPU side, but seems that it's not available in the shader? Shader indexing is the crucial piece for implementing SM6.6-style global descriptor heap. + +**6/** **@SebAaltonen** ^2001343034387239257 + +**@JoaoBapt** + +As expected, that's not supported. Oh well. Almost there. CPU can do heap indexing in Metal 4.0 with this, but GPU can't. Hopefully support added soon! + +**7/** **@TellowKrinkle** ^2002419484129382779 + +**@SebAaltonen** **@JoaoBapt** + +Depends on how much you like abusing UB +This generates the expected ISA when compiled, and given that the in-memory layout is set in stone (from the CPU side), it doesn't seem too likely to break... + +![](https://pbs.twimg.com/media/G8oFYbjWEAAUOeN?format=jpg&name=orig) + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-PeteroUPC-i-notice-one-missing-topic-here-the-issue-of.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-PeteroUPC-i-notice-one-missing-topic-here-the-issue-of.md new file mode 100644 index 0000000..456eb94 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-PeteroUPC-i-notice-one-missing-topic-here-the-issue-of.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen I notice one missing topic here: the issue of frame presentation (e.g., \"v-sync\", screen tearing, double and triple buffering, frame pacing, etc.) In this sense, for example, Vulkan just specified VK_EXT_present_timing earlier this month." +type: archive +source: twitter +source_url: "https://x.com/PeteroUPC/status/2001201415251710096" +author: "Peter O." +handle: PeteroUPC +post_id: "2001201415251710096" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen I notice one missing topic here: the issue of frame presentation (e.g., \"v-sync\", screen tearing, double and triple buffering, frame pacing, etc.) In this sense, for example, Vulkan just specified VK_EXT_present_timing earlier this month." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/PeteroUPC/status/2001201415251710096 +- Author: Peter O. (@PeteroUPC) +- Posted: 2025-12-17 08:02:52 + +## Branch + +**1/** **@PeteroUPC** ^2001201415251710096 + +**@SebAaltonen** + +I notice one missing topic here: the issue of frame presentation (e.g., "v-sync", screen tearing, double and triple buffering, frame pacing, etc.) In this sense, for example, Vulkan just specified VK_EXT_present_timing earlier this month. + +**2/** **@SebAaltonen** ^2001224870907044215 + +**@PeteroUPC** + +There are people who have more knowledge about v-sync and monitor hardware than I do, so I let those people write their blog posts and SIGGRAPH talks about that particular topic. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ap_in_indy-very-disappointing-to-see-some-of-the-shallow.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ap_in_indy-very-disappointing-to-see-some-of-the-shallow.md new file mode 100644 index 0000000..da6cacb --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ap_in_indy-very-disappointing-to-see-some-of-the-shallow.md @@ -0,0 +1,55 @@ +--- +title: "@SebAaltonen Very disappointing to see some of the shallow discourse so far! It is a very thorough blog article but many of the comments are irrelevant and headline oriented" +type: archive +source: twitter +source_url: "https://x.com/ap_in_indy/status/2001174838203875629" +author: "Alex" +handle: ap_in_indy +post_id: "2001174838203875629" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Very disappointing to see some of the shallow discourse so far! It is a very thorough blog article but many of the comments are irrelevant and headline oriented" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/ap_in_indy/status/2001174838203875629 +- Author: Alex (@ap_in_indy) +- Posted: 2025-12-17 06:17:16 + +## Branch + +**1/** **@ap_in_indy** ^2001174838203875629 + +**@SebAaltonen** + +Very disappointing to see some of the shallow discourse so far! It is a very thorough blog article but many of the comments are irrelevant and headline oriented + +**2/** **@SebAaltonen** ^2001197395250397221 + +**@ap_in_indy** + +What comments? + +**3/** **@ap_in_indy** ^2001752159616995557 + +**@SebAaltonen** + +HackerNews. Such ridiculously shallow feedback from some of the top rated comments. And it's clear that most people aren't actually reading the blog post, just the headline + +**4/** **@SebAaltonen** ^2001753558627053747 + +**@ap_in_indy** + +Most of those feedbacks reveal that these people don't really understand GPU architecture that deeply. People have opinions of course, but if those opinions are not grounded on actual hardware knowledge, then they are not highly valuable. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-bobthebobthebo3-a-minimal-api-like-this-feels-like-itd-be-fun-to.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-bobthebobthebo3-a-minimal-api-like-this-feels-like-itd-be-fun-to.md new file mode 100644 index 0000000..80cded3 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-bobthebobthebo3-a-minimal-api-like-this-feels-like-itd-be-fun-to.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen a minimal api like this feels like it'd be fun to use in smaller projects, what's the current closest thing to something like this that's usable now?" +type: archive +source: twitter +source_url: "https://x.com/bobthebobthebo3/status/2001339545330291152" +author: "bobthebob" +handle: bobthebobthebo3 +post_id: "2001339545330291152" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen a minimal api like this feels like it'd be fun to use in smaller projects, what's the current closest thing to something like this that's usable now?" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/bobthebobthebo3/status/2001339545330291152 +- Author: bobthebob (@bobthebobthebo3) +- Posted: 2025-12-17 17:11:45 + +## Branch + +**1/** **@bobthebobthebo3** ^2001339545330291152 + +**@SebAaltonen** + +a minimal api like this feels like it'd be fun to use in smaller projects, what's the current closest thing to something like this that's usable now? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-shihabskhan-hi-great-article-for-someone-who-knows-gpu-from.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-shihabskhan-hi-great-article-for-someone-who-knows-gpu-from.md new file mode 100644 index 0000000..e6d6da3 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-shihabskhan-hi-great-article-for-someone-who-knows-gpu-from.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen Hi, great article! For someone who knows gpu from hpc/simulation/academic work, what graphics API would you suggest as a starting point?" +type: archive +source: twitter +source_url: "https://x.com/shihabskhan/status/2001224997587587493" +author: "Shihab S Khan" +handle: shihabskhan +post_id: "2001224997587587493" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Hi, great article! For someone who knows gpu from hpc/simulation/academic work, what graphics API would you suggest as a starting point?" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/shihabskhan/status/2001224997587587493 +- Author: Shihab S Khan (@shihabskhan) +- Posted: 2025-12-17 09:36:35 + +## Branch + +**1/** **@shihabskhan** ^2001224997587587493 + +**@SebAaltonen** + +Hi, great article! For someone who knows gpu from hpc/simulation/academic work, what graphics API would you suggest as a starting point? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-svadrb-thank-you-awesome-post-if-one-were-to-implement.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-svadrb-thank-you-awesome-post-if-one-were-to-implement.md new file mode 100644 index 0000000..2fbe106 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-svadrb-thank-you-awesome-post-if-one-were-to-implement.md @@ -0,0 +1,57 @@ +--- +title: "@SebAaltonen Thank you! Awesome post." +type: archive +source: twitter +source_url: "https://x.com/svadrb/status/2001197309011394894" +author: "svadrb" +handle: svadrb +post_id: "2001197309011394894" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Thank you! Awesome post." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/svadrb/status/2001197309011394894 +- Author: svadrb (@svadrb) +- Posted: 2025-12-17 07:46:33 + +## Branch + +**1/** **@svadrb** ^2001197309011394894 + +**@SebAaltonen** + +Thank you! Awesome post. + +If one were to implement this API on top of existing API/driver, is it doable or is something missing? + +**2/** **@SebAaltonen** ^2001201043548364996 + +**@svadrb** + +You could implement it on top of Vulkan, if you had a custom shading language. Unfortunately there's no MSL (Metal Shading Language) to SPIRV tools yet. That's today possible with Vulkan BDA extension. But we'd need to add a the texture descriptor heap on top of it somehow. + +**3/** **@SebAaltonen** ^2001201352047796713 + +**@svadrb** + +Metal's biggest limitation for implementing this API would be the lack of user visible texture descriptor heap. Everything else is there. And DirectX 12s biggest limitation is lack of 64-bit GPU pointers in HLSL. DirectX 12 handles 64-bit GPU pointers in the CPU side in some APIs + +**4/** **@SebAaltonen** ^2001202721785790591 + +And if you want best possible performance for the root struct, you'd have to write some reflection to convert the root struct to API specific root struct build calls, and at draw time you need to setup the data that the shader expects. This is the biggest PITA. + +Or you can simply ignore that and pass one pointer as the root struct and don't get root prefetch optimizations. This is trivial, but the code runs slightly slower on the GPU. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-unconed-re-we-should-keep-using-index-buffers-and-indexed.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-unconed-re-we-should-keep-using-index-buffers-and-indexed.md new file mode 100644 index 0000000..61cfc0b --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-unconed-re-we-should-keep-using-index-buffers-and-indexed.md @@ -0,0 +1,41 @@ +--- +title: "Re: we should keep using index buffers and indexed vertices" +type: archive +source: twitter +source_url: "https://x.com/unconed/status/2001358742877503601" +author: "unconed 🛸💫🌞" +handle: unconed +post_id: "2001358742877503601" +date: 2025-12-17 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "Re: we should keep using index buffers and indexed vertices" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/unconed/status/2001358742877503601 +- Author: unconed 🛸💫🌞 (@unconed) +- Posted: 2025-12-17 18:28:02 + +## Branch + +**1/** **@unconed** ^2001358742877503601 + +Re: we should keep using index buffers and indexed vertices + +Having every single vertex attribute be indexed means you need duplicate vertices to handle cases where you have attribute seams (e.g. flipped tangents). This requires data-dependent splitting and reprocessing, which may not be feasable at runtime. + +I would much prefer a model that supports mixing "welded" and "unwelded" data instead. Do you think such a model can work? Or is it not feasible to cache partial vertices? + +I wonder because both driver devs and engine devs seem to be converging on the same sorts of shader preprocessing steps anyway (dead code elimination, attribute grouping, etc). If the vertex/fragment pipeline is a facade, couldn't we model this as a more directly in user-space instead? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-Quuux-less-api-is-not-a-good-thing-per-se-clean-and.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-Quuux-less-api-is-not-a-good-thing-per-se-clean-and.md new file mode 100644 index 0000000..67eb054 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-Quuux-less-api-is-not-a-good-thing-per-se-clean-and.md @@ -0,0 +1,42 @@ +--- +title: "@SebAaltonen \"less API\" is not a good thing per se." +type: archive +source: twitter +source_url: "https://x.com/Quuux/status/2001751269233332482" +author: "foo" +handle: Quuux +post_id: "2001751269233332482" +date: 2025-12-18 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen \"less API\" is not a good thing per se." +in_reply_to: "" +parent_post_id: "2001003366764437801" +--- + +## Source + +- URL: https://x.com/Quuux/status/2001751269233332482 +- Author: foo (@Quuux) +- Posted: 2025-12-18 20:27:47 + +## Branch + +**1/** **@Quuux** ^2001751269233332482 + +**@SebAaltonen** + +"less API" is not a good thing per se. + +"clean and predictable" is what makes an API good. +No nooks & crannies, and avoiding to plant the seeds for feature creep. + +An good API could be large, if it is of regular structure. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-RehtseStudio-did-you-update-your-article-there-was-a-section.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-RehtseStudio-did-you-update-your-article-there-was-a-section.md new file mode 100644 index 0000000..6bd70c3 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-RehtseStudio-did-you-update-your-article-there-was-a-section.md @@ -0,0 +1,45 @@ +--- +title: "@SebAaltonen Did you update your article? There was a section where you mentioned your history and who you are, and now it's not there." +type: archive +source: twitter +source_url: "https://x.com/RehtseStudio/status/2001625576361333056" +author: "Esther" +handle: RehtseStudio +post_id: "2001625576361333056" +date: 2025-12-18 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Did you update your article? There was a section where you mentioned your history and who you are, and now it's not there." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/RehtseStudio/status/2001625576361333056 +- Author: Esther (@RehtseStudio) +- Posted: 2025-12-18 12:08:20 + +## Branch + +**1/** **@RehtseStudio** ^2001625576361333056 + +**@SebAaltonen** + +Did you update your article? There was a section where you mentioned your history and who you are, and now it's not there. + +This line you had: "I shipped my first 3d accelerated game in 1999". I knew I was going to learn a bit of history in this article. + +**2/** **@SebAaltonen** ^2001669878458024250 + +**@RehtseStudio** + +It's in "About" now. Click on the link at beginning of the page. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-pmathia0-hey-great-post-does-slang-adress-pointer-issues.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-pmathia0-hey-great-post-does-slang-adress-pointer-issues.md new file mode 100644 index 0000000..235cee2 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-pmathia0-hey-great-post-does-slang-adress-pointer-issues.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen Hey, great post." +type: archive +source: twitter +source_url: "https://x.com/pmathia0/status/2001592361315635536" +author: "Peter Mathia ✈ 🇪🇺🛰️🚀" +handle: pmathia0 +post_id: "2001592361315635536" +date: 2025-12-18 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Hey, great post." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/pmathia0/status/2001592361315635536 +- Author: Peter Mathia ✈ 🇪🇺🛰️🚀 (@pmathia0) +- Posted: 2025-12-18 09:56:21 + +## Branch + +**1/** **@pmathia0** ^2001592361315635536 + +**@SebAaltonen** + +Hey, great post. Does Slang adress pointer issues described in BDA paragraph? You only mention GLSL/HLSL + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-unconed-about-this-part-the-removal-of-data-bindings.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-unconed-about-this-part-the-removal-of-data-bindings.md new file mode 100644 index 0000000..8aa913a --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-unconed-about-this-part-the-removal-of-data-bindings.md @@ -0,0 +1,57 @@ +--- +title: "About this part:" +type: archive +source: twitter +source_url: "https://x.com/unconed/status/2001622483024196083" +author: "unconed 🛸💫🌞" +handle: unconed +post_id: "2001622483024196083" +date: 2025-12-18 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "About this part:" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/unconed/status/2001622483024196083 +- Author: unconed 🛸💫🌞 (@unconed) +- Posted: 2025-12-18 11:56:02 + +## Branch + +**1/** **@unconed** ^2001622483024196083 + +About this part: + +>The removal of data bindings makes vertex and pixel shaders simpler to use. All of the complex data bindings APIs are replaced by a 64-bit GPU pointer. Users are able to write flexible vertex fetch code to avoid creating a PSO permutation per vertex layout. + +If there is no PSO permutation, then the `varying` attributes have to be identical, no? If so, what would be the use case for writing flexible vertex fetch code, if the data to be fetched is still all the same? + +**2/** **@SebAaltonen** ^2001670094389186605 + +**@unconed** + +Depends on what you want to achieve. You can load pixel data often in pixel shader directly. Don't need to pass it through the vertex shader. + +**3/** **@unconed** ^2001674041078301046 + +That seems somewhat contradictory as you said "writing flexible vertex fetch code". I can see a use-case for e.g. procedural vertex gen here, but flexible fetching seems to imply flexible attributes in practice. + +What you propose here would instead mean having a few general purpose attributes like UV and material ID, with perhaps an extra "wildcard" vec of u32 and f32 to make it 'extensible'. That seems like the opposite of what you are arguing for in the post, which is use-specific structs and union-type polymorphism. + +**4/** **@SebAaltonen** ^2001682534887764338 + +Many modern renderers use V-buffer or similar. Texturing and lighting is fully deferred. Nanite for example does it like this. + +If you need different varyings then you need a different PSO, because the hardware needs to reserve different amount of space for the varyings. The allocation happens before your shader runs, so you can't configure it inside your shader. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-20-MatRopert-really-interesting-stuff-i-would-however-not-be.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-20-MatRopert-really-interesting-stuff-i-would-however-not-be.md new file mode 100644 index 0000000..0a07703 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-20-MatRopert-really-interesting-stuff-i-would-however-not-be.md @@ -0,0 +1,66 @@ +--- +title: "@SebAaltonen Really interesting stuff!" +type: archive +source: twitter +source_url: "https://x.com/MatRopert/status/2002379265610788960" +author: "Mathieu Ropert" +handle: MatRopert +post_id: "2002379265610788960" +date: 2025-12-20 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Really interesting stuff!" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/MatRopert/status/2002379265610788960 +- Author: Mathieu Ropert (@MatRopert) +- Posted: 2025-12-20 14:03:13 + +## Branch + +**1/** **@MatRopert** ^2002379265610788960 + +**@SebAaltonen** + +Really interesting stuff! +I would however not be putting the minspec to RTX 20x series unless nVidia publishes an official patch. +The only current way to get support is through 3rd party vBIOS update which I expect only a fraction of the owners would be willing (and able) to do. + +**2/** **@SebAaltonen** ^2002414529678872891 + +**@MatRopert** + +Yes, but it's extremely unlikely that we get drivers for this API for any GPU. Thus I am only considering hardware coverage. + +**3/** **@MatRopert** ^2002434294275551689 + +**@SebAaltonen** + +Oh sure. I meant the ReBAR requirements for this. +Maybe I felt targeted cause I still run a 2080 and patching BIOS feels scary 😅 +Would simplify my current Vulkan work though if I didn't have a limit on how much device memory can be mapped directly. + +**4/** **@SimonMoos** ^2002712264802197735 + +**@MatRopert** **@SebAaltonen** + +I did the exact vBIOS upgrade, and can attest it didn’t go well on the first attempt and it was scary 😅 (works now though!) + +**5/** **@MatRopert** ^2002723630560714932 + +**@SimonMoos** **@SebAaltonen** + +Yeah I've been sitting on an patched bios image for 24h wondering how I feel about this. +What was your surprise? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-SoftEngineer-hey-sebastian-big-fan-of-your-work-amazing.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-SoftEngineer-hey-sebastian-big-fan-of-your-work-amazing.md new file mode 100644 index 0000000..1875ae7 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-SoftEngineer-hey-sebastian-big-fan-of-your-work-amazing.md @@ -0,0 +1,41 @@ +--- +title: "Hey Sebastian, big fan of your work." +type: archive +source: twitter +source_url: "https://x.com/SoftEngineer/status/2004988848171089959" +author: "Alex Goldring" +handle: SoftEngineer +post_id: "2004988848171089959" +date: 2025-12-27 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "Hey Sebastian, big fan of your work." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/SoftEngineer/status/2004988848171089959 +- Author: Alex Goldring (@SoftEngineer) +- Posted: 2025-12-27 18:52:46 + +## Branch + +**1/** **@SoftEngineer** ^2004988848171089959 + +Hey Sebastian, big fan of your work. + +Amazing article. I remember thinking much the same thoughts over the past couple of years, that graphics is heading towards general computing and AI is accelerating that process. Haven't spoken much on the topic with anyone + +It was really fascinating to read your thoughts on the subject, thought I never went as far as you have in terms of thinking it through at such a level of detail. + +Reminds me of how a general processor was born. Congratulations, and thank you. I think I'll be using this as a reference for years to come. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-kennyalive0-great-work-this-kind-of-knowledge-is-not-exposed.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-kennyalive0-great-work-this-kind-of-knowledge-is-not-exposed.md new file mode 100644 index 0000000..04b2ae4 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-kennyalive0-great-work-this-kind-of-knowledge-is-not-exposed.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen Great work! This kind of knowledge is not exposed by the existing APIs." +type: archive +source: twitter +source_url: "https://x.com/kennyalive0/status/2004863843693179070" +author: "Artem Kharytoniuk" +handle: kennyalive0 +post_id: "2004863843693179070" +date: 2025-12-27 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Great work! This kind of knowledge is not exposed by the existing APIs." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/kennyalive0/status/2004863843693179070 +- Author: Artem Kharytoniuk (@kennyalive0) +- Posted: 2025-12-27 10:36:03 + +## Branch + +**1/** **@kennyalive0** ^2004863843693179070 + +**@SebAaltonen** + +Great work! This kind of knowledge is not exposed by the existing APIs. It is often part of the discussions that led to specific designs but the API users have to guess (often incorrectly) about the underlying reasons. Thanks a lot! + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-28-steffenbauch-i-think-this-part-sounds-self-contradictory-cuda.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-28-steffenbauch-i-think-this-part-sounds-self-contradictory-cuda.md new file mode 100644 index 0000000..63f229e --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-28-steffenbauch-i-think-this-part-sounds-self-contradictory-cuda.md @@ -0,0 +1,41 @@ +--- +title: "@SebAaltonen I think this part sounds self-contradictory:" +type: archive +source: twitter +source_url: "https://x.com/steffenbauch/status/2005257271370977283" +author: "Steffen Bauch" +handle: steffenbauch +post_id: "2005257271370977283" +date: 2025-12-28 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen I think this part sounds self-contradictory:" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/steffenbauch/status/2005257271370977283 +- Author: Steffen Bauch (@steffenbauch) +- Posted: 2025-12-28 12:39:24 + +## Branch + +**1/** **@steffenbauch** ^2005257271370977283 + +**@SebAaltonen** + +I think this part sounds self-contradictory: + +> CUDA has a simple design for GPU memory allocation: The GPU malloc API takes the size as input and returns a mapped CPU pointer. The GPU free API frees the memory. CUDA doesn’t support CPU mapped GPU memory. + +Is there a typo? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-BlackPhotons-whatd-be-really-cool-is-to-have-a-translation.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-BlackPhotons-whatd-be-really-cool-is-to-have-a-translation.md new file mode 100644 index 0000000..4ff63d5 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-BlackPhotons-whatd-be-really-cool-is-to-have-a-translation.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen What'd be really cool is to have a translation layer to Vulkan so the API could be picked up and used today - it looks a lot less painful to start a new project in than pure Vulkan" +type: archive +source: twitter +source_url: "https://x.com/BlackPhotons/status/2005940976615878711" +author: "Joseph Keane" +handle: BlackPhotons +post_id: "2005940976615878711" +date: 2025-12-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen What'd be really cool is to have a translation layer to Vulkan so the API could be picked up and used today - it looks a lot less painful to start a new project in than pure Vulkan" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/BlackPhotons/status/2005940976615878711 +- Author: Joseph Keane (@BlackPhotons) +- Posted: 2025-12-30 09:56:12 + +## Branch + +**1/** **@BlackPhotons** ^2005940976615878711 + +**@SebAaltonen** + +What'd be really cool is to have a translation layer to Vulkan so the API could be picked up and used today - it looks a lot less painful to start a new project in than pure Vulkan + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-PeteroUPC-i-notice-that-your-proposed-minimal-api-makes-use.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-PeteroUPC-i-notice-that-your-proposed-minimal-api-makes-use.md new file mode 100644 index 0000000..e1d7553 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-PeteroUPC-i-notice-that-your-proposed-minimal-api-makes-use.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen I notice that your proposed minimal API makes use of PCIe ReBAR." +type: archive +source: twitter +source_url: "https://x.com/PeteroUPC/status/2006059740502114629" +author: "Peter O." +handle: PeteroUPC +post_id: "2006059740502114629" +date: 2025-12-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen I notice that your proposed minimal API makes use of PCIe ReBAR." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/PeteroUPC/status/2006059740502114629 +- Author: Peter O. (@PeteroUPC) +- Posted: 2025-12-30 17:48:07 + +## Branch + +**1/** **@PeteroUPC** ^2006059740502114629 + +**@SebAaltonen** + +I notice that your proposed minimal API makes use of PCIe ReBAR. However, the following article points out that PCIe ReBAR may be nontrivial for consumers to enable: https://asawicki.info/articles/state_of_gpu_hardware_2025.php + +**2/** **@SebAaltonen** ^2007109849692393837 + +**@PeteroUPC** + +These are all software issues. The whole premise of writing a new clean graphics API with new drivers is fixing the software. This includes fixing PCIe ReBAR software issues of course. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-02-05-xyzabcrgb-why-does-every-hard-core-programming-blog-book.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-02-05-xyzabcrgb-why-does-every-hard-core-programming-blog-book.md new file mode 100644 index 0000000..dbcc49f --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-02-05-xyzabcrgb-why-does-every-hard-core-programming-blog-book.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen why does every hard core programming blog/book have some coldish scenery as a banner/cover? like, no exceptions" +type: archive +source: twitter +source_url: "https://x.com/xyzabcrgb/status/2019504345792831937" +author: "internet" +handle: xyzabcrgb +post_id: "2019504345792831937" +date: 2026-02-05 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen why does every hard core programming blog/book have some coldish scenery as a banner/cover? like, no exceptions" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/xyzabcrgb/status/2019504345792831937 +- Author: internet (@xyzabcrgb) +- Posted: 2026-02-05 20:12:11 + +## Branch + +**1/** **@xyzabcrgb** ^2019504345792831937 + +**@SebAaltonen** + +why does every hard core programming blog/book have some coldish scenery as a banner/cover? like, no exceptions + +**2/** **@SebAaltonen** ^2019506285679636981 + +**@xyzabcrgb** + +That's just the blog default image. I was too lazy to change it :D + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-22-willmorong-great-article-i-remember-reading-it-a-while-back.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-22-willmorong-great-article-i-remember-reading-it-a-while-back.md new file mode 100644 index 0000000..27af1bf --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-22-willmorong-great-article-i-remember-reading-it-a-while-back.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen Great article, I remember reading it a while back when it was frontpaged on HN." +type: archive +source: twitter +source_url: "https://x.com/willmorong/status/2057639105543233976" +author: "willmorong" +handle: willmorong +post_id: "2057639105543233976" +date: 2026-05-22 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Great article, I remember reading it a while back when it was frontpaged on HN." +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/willmorong/status/2057639105543233976 +- Author: willmorong (@willmorong) +- Posted: 2026-05-22 01:46:06 + +## Branch + +**1/** **@willmorong** ^2057639105543233976 + +**@SebAaltonen** + +Great article, I remember reading it a while back when it was frontpaged on HN. Wondering how feasible it would be to write a vulkan wrapper/translation layer on top of current radv drivers for developers to work with as a “proof of concept”. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-26-oisyn-found-a-small-typo-in-directx-11-the-structured.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-26-oisyn-found-a-small-typo-in-directx-11-the-structured.md new file mode 100644 index 0000000..889d20e --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-26-oisyn-found-a-small-typo-in-directx-11-the-structured.md @@ -0,0 +1,41 @@ +--- +title: "@SebAaltonen Found a small typo 🙂" +type: archive +source: twitter +source_url: "https://x.com/oisyn/status/2059176930432241981" +author: "Sylvester Hesp" +handle: oisyn +post_id: "2059176930432241981" +date: 2026-05-26 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Found a small typo 🙂" +in_reply_to: "" +parent_post_id: "2001000839574643138" +--- + +## Source + +- URL: https://x.com/oisyn/status/2059176930432241981 +- Author: Sylvester Hesp (@oisyn) +- Posted: 2026-05-26 07:36:52 + +## Branch + +**1/** **@oisyn** ^2059176930432241981 + +**@SebAaltonen** + +Found a small typo 🙂 + +"In DirectX 11 the structured buffers were the only buffer type allowing an user defined struct type" + +an -> a + +## Related + +- Spine: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] diff --git a/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/index.md b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/index.md new file mode 100644 index 0000000..d16aec5 --- /dev/null +++ b/archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/index.md @@ -0,0 +1,44 @@ +--- +title: "My \"No Graphics API\" blog post is live! Please repost :)" +type: archive +source: twitter +source_url: "https://x.com/SebAaltonen/status/2001000839574643138" +author: "Sebastian Aaltonen" +handle: SebAaltonen +post_id: "2001000839574643138" +date: 2025-12-16 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "My \"No Graphics API\" blog post is live! Please repost :)" +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/SebAaltonen/status/2001000839574643138 +- Author: Sebastian Aaltonen (@SebAaltonen) +- Posted: 2025-12-16 18:45:51 + +## Thread + +**1/** **@SebAaltonen** ^2001000839574643138 + +My "No Graphics API" blog post is live! Please repost :) + +https://www.sebastianaaltonen.com/blog/no-graphics-api + +Branches: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-m_schuetz-a-shoutout-to-nv-shader-buffer-load-which-already]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-archo5dev-from-what-ive-been-able-to-find-from-public-info]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-Sebasti66855537-finally]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-goddtriffin-congrats-on-getting-this-out-in-the-world-i-can]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-ecoezen-its-been-a-great-read-a-long-but-great-thanks-for]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-fedyac-minor-nitpick-the-trick-of-packing-depth-and]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-16-EskilSteenberg-make-it-happen-what-shader-format-are-you]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoNax_97-read-it-in-one-gom-i-even-understood-some-of-it]], , , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ap_in_indy-very-disappointing-to-see-some-of-the-shallow]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-JoaoBapt-as-the-heap-management-in-metal-is-automatic]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-svadrb-thank-you-awesome-post-if-one-were-to-implement]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-PeteroUPC-i-notice-one-missing-topic-here-the-issue-of]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-this-was-a-great-post-i-agree-with-almost]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-ISzlachtycz-one-thought-that-came-to-my-mind-would-it-be]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-shihabskhan-hi-great-article-for-someone-who-knows-gpu-from]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-bobthebobthebo3-a-minimal-api-like-this-feels-like-itd-be-fun-to]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-unconed-re-we-should-keep-using-index-buffers-and-indexed]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-pmathia0-hey-great-post-does-slang-adress-pointer-issues]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-unconed-about-this-part-the-removal-of-data-bindings]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-RehtseStudio-did-you-update-your-article-there-was-a-section]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-20-MatRopert-really-interesting-stuff-i-would-however-not-be]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-kennyalive0-great-work-this-kind-of-knowledge-is-not-exposed]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-27-SoftEngineer-hey-sebastian-big-fan-of-your-work-amazing]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-28-steffenbauch-i-think-this-part-sounds-self-contradictory-cuda]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-BlackPhotons-whatd-be-really-cool-is-to-have-a-translation]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-30-PeteroUPC-i-notice-that-your-proposed-minimal-api-makes-use]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-02-05-xyzabcrgb-why-does-every-hard-core-programming-blog-book]], , [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-22-willmorong-great-article-i-remember-reading-it-a-while-back]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2026-05-26-oisyn-found-a-small-typo-in-directx-11-the-structured]] + +**2/** **@SebAaltonen** ^2001001376332308669 + +Took me 1.5 years to write this. I rewrote it completely during last summer, and did a big refactoring last month. As Hemingway would have put it: "First draft of everything is shit". Hopefully the final result isn't :) + +**3/** **@SebAaltonen** ^2001003366764437801 + +Albeit the name of the blog post is "No Graphics API", I ended up writing a new graphics API in the end. At least it's only 150 lines. WebGPU header is 2700 lines and Vulkan is 20,000 lines, so at least there's significantly less API in my API. + +Branches: [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-17-BlurBusters-very-nice-how-big-do-you-think-the-webgl-header]], [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost/2025-12-18-Quuux-less-api-is-not-a-good-thing-per-se-clean-and]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Dispatch_Graph-very-nice-im-surprised-you-didnt-talk-about.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Dispatch_Graph-very-nice-im-surprised-you-didnt-talk-about.md new file mode 100644 index 0000000..1277817 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Dispatch_Graph-very-nice-im-surprised-you-didnt-talk-about.md @@ -0,0 +1,59 @@ +--- +title: "@SebAaltonen Very nice." +type: archive +source: twitter +source_url: "https://x.com/Dispatch_Graph/status/2086066890128888053" +author: "Amélie Heinrich" +handle: Dispatch_Graph +post_id: "2086066890128888053" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Very nice." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/Dispatch_Graph/status/2086066890128888053 +- Author: Amélie Heinrich (@Dispatch_Graph) +- Posted: 2026-08-08 12:27:58 + +## Branch + +**1/** **@Dispatch_Graph** ^2086066890128888053 + +**@SebAaltonen** + +Very nice. I'm surprised you didn't talk about raytracing at all in your post/talk though! I think there's quite a few issues with the RT APIs as we speak... + +Like Vulkan/Metal not exposing AS memory, so you can't store BLASes on disk, no indirect TLAS build... + +**2/** **@Dispatch_Graph** ^2086067095993774585 + +**@SebAaltonen** + +One thing I'd love to see in a new shading language and API is the concept of shader function pointers -- they respect a certain signature (return type, parameters), and instead of SBT madness, you can assign a BLAS instance a pointer to a GPU function + +**3/** **@Dispatch_Graph** ^2086069530854387959 + +**@SebAaltonen** + +Something like this would be awesome. Would solve the whole material classification fiasco you need to go through with V-Buffer, it would eliminate the need for SBTs/Uber-shader approaches for RT reflections/ReSTIR etc. Shader graph/custom materials could work for raster AND RT + +![](https://pbs.twimg.com/media/HPM1GzdWwAA-lWl?format=jpg&name=orig) + +**4/** **@GaySpaceAngel** ^2086511860896112987 + +**@Dispatch_Graph** **@SebAaltonen** + +Something very similar to this API shape exists with Shader Subroutine Linkage (GL)/Dynamic Shader Linkage (D3D11). Unfortunately I think the function pointer has to be uniform so it’s an almost worthless feature in practice. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Jurgus007-what-do-you-think-are-the-chances-any-chances-at.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Jurgus007-what-do-you-think-are-the-chances-any-chances-at.md new file mode 100644 index 0000000..9dbe056 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Jurgus007-what-do-you-think-are-the-chances-any-chances-at.md @@ -0,0 +1,59 @@ +--- +title: "@SebAaltonen What do you think are the chances—any chances at all—that, say, the Vulkan 2.0 API would look the way you're suggesting?" +type: archive +source: twitter +source_url: "https://x.com/Jurgus007/status/2086212585884438702" +author: "Łukasz I" +handle: Jurgus007 +post_id: "2086212585884438702" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen What do you think are the chances—any chances at all—that, say, the Vulkan 2.0 API would look the way you're suggesting?" +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/Jurgus007/status/2086212585884438702 +- Author: Łukasz I (@Jurgus007) +- Posted: 2026-08-08 22:06:55 + +## Branch + +**1/** **@Jurgus007** ^2086212585884438702 + +**@SebAaltonen** + +What do you think are the chances—any chances at all—that, say, the Vulkan 2.0 API would look the way you're suggesting? + +**2/** **@SebAaltonen** ^2086372792463724961 + +Remove descriptor sets and descriptor pools. Make descriptor heap extension the basis for descriptors. BDA needs to be standard and GLSL BDA syntax and type safety needs work (64-bit pointers instead of integers). Also unified image layouts for barriers as default, and I really hope that resource lists in barriers could be removed. For backwards compatibility reasons they would likely keep buffer descriptors. There's still some real use cases for them. Texel buffers have type conversion and many GPUs are lacking 32-bit per-lane index for 64-bit pointer raw memory loads. You need 64-bit pointer per lane (which bloats register use slightly). Providing root data with the new push data extension is fine, but having a 64-bit pointer instead as root data would be nicer. Not a deal breaker. + +**3/** **@Jurgus007** ^2086410941202084255 + +**@SebAaltonen** + +Having watched your video again, two things are still worrying me. 1) To create a GPU pipeline, you need to specify a vertex/mesh + pixel shader combo. So we’re still faced with the ‘combination problem’ of these two graphics stages. + +**4/** **@Jurgus007** ^2086411284040348143 + +**@SebAaltonen** + +2) Sampling textures of various types, formats, etc. is ‘hidden’ within the texture descriptor, and that’s fine. shader code always looks the same, yet you can sample different types of textures. As far as I understand, this is no longer the case with the Vertex Buffer and IA. + +**5/** **@Jurgus007** ^2086411457516695853 + +**@SebAaltonen** + +Now you have to “decode” the data format in the primitive vertices yourself. This means you have to write this part of the code yourself and take responsibility for it. The consequence is that vertex shaders must be combined solely for the purpose of decoding vertex attributes. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-bygregorr-what-assumption-from-existing-apis-proved-hardest.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-bygregorr-what-assumption-from-existing-apis-proved-hardest.md new file mode 100644 index 0000000..c75ae90 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-bygregorr-what-assumption-from-existing-apis-proved-hardest.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen What assumption from existing APIs proved hardest to drop in the clean slate design?" +type: archive +source: twitter +source_url: "https://x.com/bygregorr/status/2086087772524200063" +author: "Gregor" +handle: bygregorr +post_id: "2086087772524200063" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen What assumption from existing APIs proved hardest to drop in the clean slate design?" +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/bygregorr/status/2086087772524200063 +- Author: Gregor (@bygregorr) +- Posted: 2026-08-08 13:50:57 + +## Branch + +**1/** **@bygregorr** ^2086087772524200063 + +**@SebAaltonen** + +What assumption from existing APIs proved hardest to drop in the clean slate design? + +**2/** **@SebAaltonen** ^2086208233018917263 + +**@bygregorr** + +The clean slate design isn't feature complete. It was an inspirational goal. Once you start adding all the nitty-gritty features, it would get more complicated. Especially if you want to add support for vendor extensions. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-endeva_gg-nice-i-liked-the-history-lesson-at-the-beginning.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-endeva_gg-nice-i-liked-the-history-lesson-at-the-beginning.md new file mode 100644 index 0000000..cee6a73 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-endeva_gg-nice-i-liked-the-history-lesson-at-the-beginning.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen Nice! I liked the history lesson at the beginning." +type: archive +source: twitter +source_url: "https://x.com/endeva_gg/status/2086209660026278312" +author: "Sammie 🇵🇸" +handle: endeva_gg +post_id: "2086209660026278312" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Nice! I liked the history lesson at the beginning." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/endeva_gg/status/2086209660026278312 +- Author: Sammie 🇵🇸 (@endeva_gg) +- Posted: 2026-08-08 21:55:17 + +## Branch + +**1/** **@endeva_gg** ^2086209660026278312 + +**@SebAaltonen** + +Nice! I liked the history lesson at the beginning. I wonder how mobile IHVs would take to this but it's long overdue + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-guillaumepiolat-so-it-was-you-doing-stargazer-in-2008.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-guillaumepiolat-so-it-was-you-doing-stargazer-in-2008.md new file mode 100644 index 0000000..36558d6 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-guillaumepiolat-so-it-was-you-doing-stargazer-in-2008.md @@ -0,0 +1,37 @@ +--- +title: "@SebAaltonen So..." +type: archive +source: twitter +source_url: "https://x.com/guillaumepiolat/status/2086044349935055158" +author: "Guillaume Piolat" +handle: guillaumepiolat +post_id: "2086044349935055158" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen So..." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/guillaumepiolat/status/2086044349935055158 +- Author: Guillaume Piolat (@guillaumepiolat) +- Posted: 2026-08-08 10:58:24 + +## Branch + +**1/** **@guillaumepiolat** ^2086044349935055158 + +**@SebAaltonen** + +So... it was you doing Stargazer in 2008? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-thedeepflux-ok-but-the-2x-extension-points-toward-the-part.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-thedeepflux-ok-but-the-2x-extension-points-toward-the-part.md new file mode 100644 index 0000000..b68cea4 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-thedeepflux-ok-but-the-2x-extension-points-toward-the-part.md @@ -0,0 +1,61 @@ +--- +title: "@SebAaltonen ok but the 2x extension points toward the part nobody talks about: tooling." +type: archive +source: twitter +source_url: "https://x.com/thedeepflux/status/2086176821968777630" +author: "Deepak" +handle: thedeepflux +post_id: "2086176821968777630" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen ok but the 2x extension points toward the part nobody talks about: tooling." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/thedeepflux/status/2086176821968777630 +- Author: Deepak (@thedeepflux) +- Posted: 2026-08-08 19:44:48 + +## Branch + +**1/** **@thedeepflux** ^2086176821968777630 + +**@SebAaltonen** + +ok but the 2x extension points toward the part nobody talks about: tooling. Vulkan, DirectX 12, and Metal can all be painful at the API layer, but mature debuggers and profilers absorb a lot of that pain. A new design needs an equally strong inspection story. + +**2/** **@SebAaltonen** ^2086207792398966992 + +**@thedeepflux** + +There's a tooling chapter in the 50-page blog post. Didn't want to spend 10 minutes on tooling in my very limited SIGGRAPH slot. + +**3/** **@thedeepflux** ^2086209680154784090 + +**@SebAaltonen** + +Tooling is not documentation around a graphics API. It defines which mental model developers actually use when debugging. The 50-page chapter matters because a clean API with weak capture and profiling support still produces the same 2 a.m. GPU bugs. + +**4/** **@Hohounk** ^2089347139470041469 + +**@thedeepflux** **@SebAaltonen** + +From what I gleaned from a quick read of the blog post, the tooling would have to be added and someone somewhere would have to do it but it would be doable. + +**5/** **@Hohounk** ^2089347446614757820 + +**@thedeepflux** **@SebAaltonen** + +Tooling is important and will take time to mature. Same with any other graphics technology, it'll take a whole bunch of years before something like this ends up mainstream. Just remember how long it took for vulkan to become widely used. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-adelbucetta-the-honest-answer-is-that-most-people-in-the.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-adelbucetta-the-honest-answer-is-that-most-people-in-the.md new file mode 100644 index 0000000..e5bfa80 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-adelbucetta-the-honest-answer-is-that-most-people-in-the.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen the honest answer is that most people in the industry don't actually care about reducing api complexity, they care about making their own code work faster and get out a demo before their investors lose patience again" +type: archive +source: twitter +source_url: "https://x.com/adelbucetta/status/2086260619637121415" +author: "Adel Bucetta" +handle: adelbucetta +post_id: "2086260619637121415" +date: 2026-08-09 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen the honest answer is that most people in the industry don't actually care about reducing api complexity, they care about making their own code work faster and get out a demo before their investors lose patience again" +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/adelbucetta/status/2086260619637121415 +- Author: Adel Bucetta (@adelbucetta) +- Posted: 2026-08-09 01:17:47 + +## Branch + +**1/** **@adelbucetta** ^2086260619637121415 + +**@SebAaltonen** + +the honest answer is that most people in the industry don't actually care about reducing api complexity, they care about making their own code work faster and get out a demo before their investors lose patience again + +**2/** **@SebAaltonen** ^2086496633462706528 + +**@adelbucetta** + +Complexity makes it more difficult to make your code run faster. Also it drives people to adapt third party engines, which have massive codebases. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-metalim-hardly-can-hear-anything-please-use-mic-next-time.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-metalim-hardly-can-hear-anything-please-use-mic-next-time.md new file mode 100644 index 0000000..6f92811 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-metalim-hardly-can-hear-anything-please-use-mic-next-time.md @@ -0,0 +1,43 @@ +--- +title: "@SebAaltonen hardly can hear anything." +type: archive +source: twitter +source_url: "https://x.com/metalim/status/2086377553854423291" +author: "Maksim Litvinov" +handle: metalim +post_id: "2086377553854423291" +date: 2026-08-09 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen hardly can hear anything." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/metalim/status/2086377553854423291 +- Author: Maksim Litvinov (@metalim) +- Posted: 2026-08-09 09:02:26 + +## Branch + +**1/** **@metalim** ^2086377553854423291 + +**@SebAaltonen** + +hardly can hear anything. Please use mic next time. Stable Volume setting helps a bit, but sound quality is still "muffled" + +**2/** **@SebAaltonen** ^2086384129617121642 + +**@metalim** + +Usually the Mac microphone has been good. And OBS mic volume was at maximum. Next time I use my headphones. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-12-MrMPFR-excellent-info-if-only-my-understand-was-better.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-12-MrMPFR-excellent-info-if-only-my-understand-was-better.md new file mode 100644 index 0000000..5d7f199 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-12-MrMPFR-excellent-info-if-only-my-understand-was-better.md @@ -0,0 +1,42 @@ +--- +title: "@SebAaltonen Excellent info." +type: archive +source: twitter +source_url: "https://x.com/MrMPFR/status/2087649451682803758" +author: "MrMPFR" +handle: MrMPFR +post_id: "2087649451682803758" +date: 2026-08-12 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen Excellent info." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/MrMPFR/status/2087649451682803758 +- Author: MrMPFR (@MrMPFR) +- Posted: 2026-08-12 21:16:30 + +## Branch + +**1/** **@MrMPFR** ^2087649451682803758 + +**@SebAaltonen** + +Excellent info. If only my understand was better. + +Can't figure out if your proposed API has autonomous GPU memory allocation and recursive GPU work creation/indirect drawing on steroids. + +Does it have anything resembling these work graph like qualities? +If so what HW support? + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-13-GiovanniCarli18-i-just-wanted-to-comment-on-this-since-it-popped.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-13-GiovanniCarli18-i-just-wanted-to-comment-on-this-since-it-popped.md new file mode 100644 index 0000000..90d39a4 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-13-GiovanniCarli18-i-just-wanted-to-comment-on-this-since-it-popped.md @@ -0,0 +1,41 @@ +--- +title: "@SebAaltonen I just wanted to comment on this since it popped up on my YouTube feed, and I've watched the whole talk." +type: archive +source: twitter +source_url: "https://x.com/GiovanniCarli18/status/2087857210835529731" +author: "Giovanni Carlino" +handle: GiovanniCarli18 +post_id: "2087857210835529731" +date: 2026-08-13 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "@SebAaltonen I just wanted to comment on this since it popped up on my YouTube feed, and I've watched the whole talk." +in_reply_to: "" +parent_post_id: "2086035003360583907" +--- + +## Source + +- URL: https://x.com/GiovanniCarli18/status/2087857210835529731 +- Author: Giovanni Carlino (@GiovanniCarli18) +- Posted: 2026-08-13 11:02:04 + +## Branch + +**1/** **@GiovanniCarli18** ^2087857210835529731 + +**@SebAaltonen** + +I just wanted to comment on this since it popped up on my YouTube feed, and I've watched the whole talk. + +It is extremely in-depth and easy to follow through at the same time, incredible job Sebastian. + +We desperately need a better and simpler way of communicating with the GPU. + +## Related + +- Spine: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]] diff --git a/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/index.md b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/index.md new file mode 100644 index 0000000..f03c9d2 --- /dev/null +++ b/archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/index.md @@ -0,0 +1,41 @@ +--- +title: "Extended (2x) version of my SIGGRAPH 2026 talk:" +type: archive +source: twitter +source_url: "https://x.com/SebAaltonen/status/2086035003360583907" +author: "Sebastian Aaltonen" +handle: SebAaltonen +post_id: "2086035003360583907" +date: 2026-08-08 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - SebAaltonen +description: "Extended (2x) version of my SIGGRAPH 2026 talk:" +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/SebAaltonen/status/2086035003360583907 +- Author: Sebastian Aaltonen (@SebAaltonen) +- Posted: 2026-08-08 10:21:16 + +## Thread + +**1/** **@SebAaltonen** ^2086035003360583907 + +Extended (2x) version of my SIGGRAPH 2026 talk: +https://www.youtube.com/watch?v=aQv9pUl9PBM + +Reducing Graphics API Complexity: A Clean Slate Design for Modern GPUs + +Branches: [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-guillaumepiolat-so-it-was-you-doing-stargazer-in-2008]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Dispatch_Graph-very-nice-im-surprised-you-didnt-talk-about]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-bygregorr-what-assumption-from-existing-apis-proved-hardest]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-thedeepflux-ok-but-the-2x-extension-points-toward-the-part]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-endeva_gg-nice-i-liked-the-history-lesson-at-the-beginning]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-08-Jurgus007-what-do-you-think-are-the-chances-any-chances-at]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-adelbucetta-the-honest-answer-is-that-most-people-in-the]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-09-metalim-hardly-can-hear-anything-please-use-mic-next-time]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-12-MrMPFR-excellent-info-if-only-my-understand-was-better]], [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk/2026-08-13-GiovanniCarli18-i-just-wanted-to-comment-on-this-since-it-popped]] + +**2/** **@SebAaltonen** ^2086037223904801046 + +Based on my blog post from last Christmas. This new presentation also discusses brand new Vulkan extensions released since, and discusses the issues of the bloated shader framework (a topic I want to discuss more in my next blog post). + +https://www.sebastianaaltonen.com/blog/no-graphics-api diff --git a/archive/threads/SebAaltonen/index.md b/archive/threads/SebAaltonen/index.md index 1342de6..adc74cd 100644 --- a/archive/threads/SebAaltonen/index.md +++ b/archive/threads/SebAaltonen/index.md @@ -14,3 +14,5 @@ tags: - [[archive/threads/SebAaltonen/2024-12-18-fixed-all-our-vulkan-bugs]] - [[archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several]] - [[archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look]] +- [[archive/threads/SebAaltonen/2025-12-16-my-no-graphics-api-blog-post-is-live-please-repost]] +- [[archive/threads/SebAaltonen/2026-08-08-extended-2x-version-of-my-siggraph-2026-talk]]