From e7e0392e1d07de859dafdfc4dc6c2eb9d4e8375e Mon Sep 17 00:00:00 2001 From: Ed_ Date: Tue, 25 Aug 2026 09:52:38 -0400 Subject: [PATCH] 1868712285675671711 --- .../index.md | 32 -------------- ...gh-current-compilers-are-a-bloated-mess.md | 6 +-- .../index.md | 44 +++++++++++++++++++ scripts/twitter/README.md | 5 +-- 4 files changed, 49 insertions(+), 38 deletions(-) delete mode 100644 archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/index.md rename archive/threads/NOTimothyLottes/{2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler => 2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24}/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md (84%) create mode 100644 archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md diff --git a/archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/index.md b/archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/index.md deleted file mode 100644 index c100ad4..0000000 --- a/archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family." -type: archive -source: twitter -source_url: "https://x.com/NOTimothyLottes/status/1868716773937414589" -author: "NOTimothyLottes" -handle: NOTimothyLottes -post_id: "1868716773937414589" -date: 2024-12-16 -archived: 2026-08-23 -draft: true -tags: - - archive - - twitter - - NOTimothyLottes -description: "@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family." -in_reply_to: "" ---- - -## Source - -- URL: https://x.com/NOTimothyLottes/status/1868716773937414589 -- Author: NOTimothyLottes (@NOTimothyLottes) -- Posted: 2024-12-16 17:56:12 - -## Thread - -**1/** - -@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family. - -Branches: [[archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess]] diff --git a/archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md similarity index 84% rename from archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md rename to archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md index 0d6c00b..2e5f6aa 100644 --- a/archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md +++ b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md @@ -7,8 +7,8 @@ author: "Jebrim" handle: AgileJebrim post_id: "1868717227866046808" date: 2024-12-16 -archived: 2026-08-23 -draft: true +archived: 2026-08-25 +draft: false tags: - archive - twitter @@ -32,4 +32,4 @@ parent_post_id: "1868716773937414589" ## Related -- Spine: [[archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler]] +- Spine: [[archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24]] diff --git a/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md new file mode 100644 index 0000000..4ccd732 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md @@ -0,0 +1,44 @@ +--- +title: "@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/1868712285675671711" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "1868712285675671711" +date: 2024-12-16 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/1868712285675671711 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2024-12-16 17:38:22 + +## Thread + +**1/** + +@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL + +**2/** + +@NOTimothyLottes @GustavSterbrant If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else? + +**3/** + +@AgileJebrim @GustavSterbrant At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK + +**4/** + +@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family. + +Branches: [[archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess]] diff --git a/scripts/twitter/README.md b/scripts/twitter/README.md index 0e85239..e04ef49 100644 --- a/scripts/twitter/README.md +++ b/scripts/twitter/README.md @@ -24,18 +24,17 @@ python C:\projects\Threadwell\scripts\twitter\tw.py reslug --all --apply `paths.py` sets vault = two parents above this file, dumps = `../manual_slop/docs/twitter`, scratch = `../Threadwell-ai/scratch`. -`refresh` = refetch (cookies) + ingest + emit `--force` + media_merge. `--tip` treats `--id` as the tip and walks back to the OP regardless of handle. Repeatable `--branch ` captures only those additional explicit tip paths and merges them into the same `thread_data.json`; it does not discover replies automatically. Captures run sequentially with gallery-dl retries disabled and five-second extractor/request pacing. Each thread emits exactly one archive directory owned by the OP (the post with `reply_to_id == None`); cross-author responders do not get a directory. Does not flip `draft`. Does not commit. Frozen ids abort. +`refresh` = refetch (cookies) + ingest + emit `--force` + media_merge. `--tip` treats `--id` as the tip and walks back to the OP regardless of handle. Repeatable `--branch ` captures only those additional explicit tip paths and merges them into the same `thread_data.json`; it does not discover replies automatically. Captures run sequentially with gallery-dl retries disabled and five-second extractor/request pacing. Each thread emits exactly one archive directory owned by the OP (the post with `reply_to_id == None`); cross-author responders do not get a directory. New notes default to `draft: false` (publish by default). Does not commit. Frozen ids abort. `emit --preserve-existing` is the safe completion step after inspecting a fresh scratch capture. Fresh records win for ids the provider returned; posts present only in the existing emitted `thread_data.json` are retained after the command verifies both captures share a conversation root. This prevents an incomplete gallery-dl refresh from deleting archived replies. The merged scratch dataset keeps the requested `--id` as its stored spine tip before normal emission and media-manifest reconciliation. `add-branch` incrementally extends an already emitted thread. `--id` must be the original stored spine tip; repeatable `--from ` values are each captured once. The command locally retains each node's missing attachment path and entire visible descendant subtree, merges only previously absent posts into the existing `thread_data.json`, downloads media for the new posts, and re-emits with the original spine unchanged. It preserves existing origin/local/fallback/derived/OCR media records and adds provider-origin plus local-copy records for new branch media. A visible leaf is only the deepest reply returned by that capture; the command does not query descendants individually or claim provider-wide completeness. Gallery-dl may return only the ancestor chain when replies are behind nested show-more cursors; then the command adds nothing and known reply/stream-tip ids must be supplied explicitly. Fallback upload remains a separate explicit action after origin unavailability is confirmed. -Usual publish path after you like the note: +New emits publish by default. `tw.py publish --id ` is only used to flip a thread that was captured with `draft: true` (rare after this change). The usual review path is: 1. `tw.py graph --id …` — confirm tip vs root. 2. `tw.py refresh --id … --tip` if the dump stored a tip as root. 3. `tw.py audit-media --id …` — confirm origin URLs are selected. -4. `tw.py publish --id …` sets `draft: false`. You commit. Site wikilinks must be `[[archive/threads//]]`. Short `[[slug]]` 404s.