From 58af0e7bb1c18acdc7a98a01566a5a41a77d51db Mon Sep 17 00:00:00 2001 From: Ed_ Date: Sun, 26 Jul 2026 21:43:21 -0400 Subject: [PATCH] docs(twitter): add 1951638140600381942 corpus (NOTimothyLottes SPIR-V-from-data + 'cart file') 7-post multi-person thread (NOTimothyLottes / @onatt0 / @EskilSteenberg / @olson_dan). On-the-fly SPIR-V generation instead of GLSL: cart file = 'code+data' restartable package, macro-assembly-style language where defines are played back interleaved for ILP/loop-unroll, SPIR-V out direct (no GLSL step). Inspired by C64 SID tracker pattern + instrument. CPU does the SPIR-V generation from data the GPU can read/write. --- docs/twitter/1951638140600381942/thread.md | 43 +++++++ .../1951638140600381942/thread_data.json | 118 ++++++++++++++++++ 2 files changed, 161 insertions(+) create mode 100644 docs/twitter/1951638140600381942/thread.md create mode 100644 docs/twitter/1951638140600381942/thread_data.json diff --git a/docs/twitter/1951638140600381942/thread.md b/docs/twitter/1951638140600381942/thread.md new file mode 100644 index 00000000..76c9ddb9 --- /dev/null +++ b/docs/twitter/1951638140600381942/thread.md @@ -0,0 +1,43 @@ +--- +title: "@onatt0 @EskilSteenberg @olson_dan So far the plan is to have the data read/writ" +author: "NOTimothyLottes" +handle: "@NOTimothyLottes" +post_url: "https://x.com/NOTimothyLottes/status/1951638140600381942" +post_id: "1951638140600381942" +timestamp: "2025-08-02 13:36:07" +post_count: 7 +reply_count: 1 +repost_count: 0 +like_count: 0 +view_count: 83 +--- + +# @NOTimothyLottes — @onatt0 @EskilSteenberg @olson_dan So far the plan is to have the data read/writ + +## Post 1 (2025-07-31 15:03:55) + +Been on the fence on writing shader interfaces in GLSL vs something else that translates to SPIR-V. Most GLSL mixed with defines can just direct port to other platforms. However these days I have hundreds of lines of macros to transform GLSL closer to assembly. + +## Post 2 (2025-08-01 04:53:21) — reply to Post 1 + +@NOTimothyLottes What's the top "something else"? I've been out of the space for a while. + +## Post 3 (2025-08-01 14:56:14) — reply to Post 2 + +@olson_dan Wanting to build something that effectively loads/stores a 'cart' file which contains all the 'code+data' of the game in a restartable package. The code cannot be GLSL because I'm not going to link in a huge compiler. Leaves something that generates SPIR-V on the fly. New lang + +## Post 4 (2025-08-01 17:15:45) — reply to Post 3 + +@NOTimothyLottes @olson_dan For a long time i have contemplated writing a small GLSL->SPIR-V compiler. I think you could get away with something very simple, if you are conservative with your language use. + +## Post 5 (2025-08-01 17:51:33) — reply to Post 4 + +@EskilSteenberg @olson_dan Have a crazy idea for GPU shader dev inspired by a C64 SID tracker where you have a 'pattern' for the 'instrument' which shows SID fx changing over time, along with the standard multi-channel pattern nestily using the instrument ... + +## Post 6 (2025-08-01 17:53:55) — reply to Post 5 + +@EskilSteenberg @olson_dan ... Effectively a macro assembly language style thing where defines can be played back interleaved for things like ILP or loop unrolling etc. But programmer controlling interleaving, and register offsets, etc. Then ultimately output to SPIR-V direct (no GLSL step). + +## Post 7 (2025-08-02 13:36:07) + +@onatt0 @EskilSteenberg @olson_dan So far the plan is to have the data read/write from the GPU, but still use the CPU to do the SPIR-V generation from said data. diff --git a/docs/twitter/1951638140600381942/thread_data.json b/docs/twitter/1951638140600381942/thread_data.json new file mode 100644 index 00000000..d763eaec --- /dev/null +++ b/docs/twitter/1951638140600381942/thread_data.json @@ -0,0 +1,118 @@ +{ + "root_post_id": "1951638140600381942", + "posts": [ + { + "post_id": "1950935464149483683", + "author": "NOTimothyLottes", + "handle": "NOTimothyLottes", + "text": "Been on the fence on writing shader interfaces in GLSL vs something else that translates to SPIR-V. Most GLSL mixed with defines can just direct port to other platforms. However these days I have hundreds of lines of macros to transform GLSL closer to assembly.", + "timestamp": "2025-07-31 15:03:55", + "media_urls": [], + "reply_to_id": null, + "quote_of_id": null, + "metrics": { + "reply_count": 3, + "repost_count": 0, + "like_count": 19, + "view_count": 2857 + } + }, + { + "post_id": "1951144195843928435", + "author": "Dan Olson", + "handle": "olson_dan", + "text": "@NOTimothyLottes What's the top \"something else\"? I've been out of the space for a while.", + "timestamp": "2025-08-01 04:53:21", + "media_urls": [], + "reply_to_id": "1950935464149483683", + "quote_of_id": null, + "metrics": { + "reply_count": 1, + "repost_count": 0, + "like_count": 0, + "view_count": 289 + } + }, + { + "post_id": "1951295915274240375", + "author": "NOTimothyLottes", + "handle": "NOTimothyLottes", + "text": "@olson_dan Wanting to build something that effectively loads/stores a 'cart' file which contains all the 'code+data' of the game in a restartable package. The code cannot be GLSL because I'm not going to link in a huge compiler. Leaves something that generates SPIR-V on the fly. New lang", + "timestamp": "2025-08-01 14:56:14", + "media_urls": [], + "reply_to_id": "1951144195843928435", + "quote_of_id": null, + "metrics": { + "reply_count": 1, + "repost_count": 0, + "like_count": 4, + "view_count": 288 + } + }, + { + "post_id": "1951331025986134342", + "author": "Eskil Steenberg", + "handle": "EskilSteenberg", + "text": "@NOTimothyLottes @olson_dan For a long time i have contemplated writing a small GLSL->SPIR-V compiler. I think you could get away with something very simple, if you are conservative with your language use.", + "timestamp": "2025-08-01 17:15:45", + "media_urls": [], + "reply_to_id": "1951295915274240375", + "quote_of_id": null, + "metrics": { + "reply_count": 1, + "repost_count": 0, + "like_count": 2, + "view_count": 199 + } + }, + { + "post_id": "1951340035996815801", + "author": "NOTimothyLottes", + "handle": "NOTimothyLottes", + "text": "@EskilSteenberg @olson_dan Have a crazy idea for GPU shader dev inspired by a C64 SID tracker where you have a 'pattern' for the 'instrument' which shows SID fx changing over time, along with the standard multi-channel pattern nestily using the instrument ...", + "timestamp": "2025-08-01 17:51:33", + "media_urls": [], + "reply_to_id": "1951331025986134342", + "quote_of_id": null, + "metrics": { + "reply_count": 1, + "repost_count": 0, + "like_count": 3, + "view_count": 267 + } + }, + { + "post_id": "1951340632183583076", + "author": "NOTimothyLottes", + "handle": "NOTimothyLottes", + "text": "@EskilSteenberg @olson_dan ... Effectively a macro assembly language style thing where defines can be played back interleaved for things like ILP or loop unrolling etc. But programmer controlling interleaving, and register offsets, etc. Then ultimately output to SPIR-V direct (no GLSL step).", + "timestamp": "2025-08-01 17:53:55", + "media_urls": [], + "reply_to_id": "1951340035996815801", + "quote_of_id": null, + "metrics": { + "reply_count": 1, + "repost_count": 0, + "like_count": 3, + "view_count": 281 + } + }, + { + "post_id": "1951638140600381942", + "author": "NOTimothyLottes", + "handle": "NOTimothyLottes", + "text": "@onatt0 @EskilSteenberg @olson_dan So far the plan is to have the data read/write from the GPU, but still use the CPU to do the SPIR-V generation from said data.", + "timestamp": "2025-08-02 13:36:07", + "media_urls": [], + "reply_to_id": "1951591243328135279", + "quote_of_id": null, + "metrics": { + "reply_count": 1, + "repost_count": 0, + "like_count": 0, + "view_count": 83 + } + } + ], + "source_url": "https://x.com/NOTimothyLottes/status/1951638140600381942" +} \ No newline at end of file