Private
Public Access
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.
This commit is contained in:
@@ -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.
|
||||
@@ -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"
|
||||
}
|
||||
Reference in New Issue
Block a user