diff --git a/archive/threads/NOTimothyLottes/2026-11-07-not-a-joke-im-re-trying-development-through/index.md b/archive/threads/NOTimothyLottes/2026-11-07-not-a-joke-im-re-trying-development-through/index.md new file mode 100644 index 0000000..8a302b8 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-11-07-not-a-joke-im-re-trying-development-through/index.md @@ -0,0 +1,78 @@ +--- +title: "Not a joke: I'm re-trying development through direct 32-bit hex editing of a binary, with a layer of annotation which consists of 9 character comment per 32-bits, and a 1-bit tag if a 32-bit value is an opcode." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2119112267648094671" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2119112267648094671" +date: 2026-11-07 +archived: 2026-11-14 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Not a joke: I'm re-trying development through direct 32-bit hex editing of a binary, with a layer of annotation which consists of 9 character comment per 32-bits, and a 1-bit tag if a 32-bit value is an opcode." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2119112267648094671 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-11-07 16:58:30 + +## Thread + +**1/** **@NOTimothyLottes** ^2119112267648094671 + +Not a joke: I'm re-trying development through direct 32-bit hex editing of a binary, with a layer of annotation which consists of 9 character comment per 32-bits, and a 1-bit tag if a 32-bit value is an opcode. This is one layer more hardcore than assembly programming. + +**2/** **@NOTimothyLottes** ^2119112827591860340 + +I've made a subset of x86-64 where I use extra prefix bytes to make all "opcodes" 32-bit, as well as making it direct 1:1 map to different 32-bit values in ARM64, but with the same function. Meaning I can transcode simply if need be. + +**3/** **@NOTimothyLottes** ^2119113469702352935 + +32-bit opcode to human readable string (9-characters) is a search through a lookup table, and happens only at edit time. A human readable string to 32-bit opcode is also just a lookup table search at edit time. As simple as it gets. Everything factored into data, almost no code. + +**4/** **@NOTimothyLottes** ^2119113969030095287 + +Editor style is simply direct binary edits at runtime, with ability to see all memory live. Effectively the minimal hardcore dev environment. + +**5/** **@NOTimothyLottes** ^2119115446121111908 + +I've ditched RIP relative addressing and RIP relative call/jmp. Meaning I only do call/jmp to register. That was the core simplification. I still have conditional branching by a multiple of 4 bytes with a signed 8-bit immediate, for the few cases I might need that. + +**6/** **@NOTimothyLottes** ^2119115894148473152 + +So I don't need any relinking on edit motion, instead I stick the few 32-bit branch addresses (forced lower 32-bit runtime) in a lookup table and load then call. Call pointers are simply part of the data layout specification instead of being baked into source. + +**7/** **@NOTimothyLottes** ^2119117987462443034 + +Early in this path I was inspired by the ideas of Charles Moore and friends, but it was the sourceless direction rather than color forth itself that was most interesting to me personally - https://www.ultratechnology.com/prog.htm + +**8/** **@NOTimothyLottes** ^2119118979444699291 + +Getting this project finished is probably the point at which I'll be out of temporary home project retirement ... maybe will do a video blog on this one. Still refining the 32-bit subset and tables (the part that takes the longest time as it's like a mini virtual ISA design). + +**9/** **@NOTimothyLottes** ^2119121301592060301 + +Some useful references used in this project: +https://ref.x86asm.net/coder64.html +https://defuse.ca/online-x86-assembler.htm +https://www.felixcloutier.com/x86/ +https://www.scs.stanford.edu/~zyedidia/arm64/index.html + +**10/** **@NOTimothyLottes** ^2119122239224271302 + +My hardware targets are similar to before, to the metal dedicated stuff for either x86-64 or ARM64 and AMD GPUs on Linux. So any associated AMD based Steam HW platform. + +**11/** **@NOTimothyLottes** ^2119122622684238254 + +No user-space libraries. Only kernel interfaces, not running in X/Wayland, and instead going direct to the AMD kernel driver from a VT session. + +**12/** **@NOTimothyLottes** ^2119122982983651379 + +I'll be treating this as a vintage to the metal console platform with assembly-level dev for CPU/GPU. Bringing back a memory of how things had been, but on modern HW. Something more of an actual console than anything you'd see from MS/Sony/Nintendo. diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AgileJebrim-did-this-still-synchronize-all-threads-before.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AgileJebrim-did-this-still-synchronize-all-threads-before.md index 476e0ac..2b41581 100644 --- a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AgileJebrim-did-this-still-synchronize-all-threads-before.md +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AgileJebrim-did-this-still-synchronize-all-threads-before.md @@ -7,7 +7,7 @@ author: "Jebrim" handle: AgileJebrim post_id: "2121255478319604151" date: 2026-11-13 -archived: 2026-11-13 +archived: 2026-11-14 draft: false tags: - archive @@ -44,6 +44,12 @@ You can just read the CDP docs they go into detail. I think they have an old CDP I meant your non-atomic approach. The contract would thus be different if global sync guarantees were no longer required. I know how much you like pipelining. +**4/** **@TooMuchVoltage** ^2121650024593432685 + +**@AgileJebrim** **@NOTimothyLottes** + +Ok so, the difference seems to be between atomics and CU <-> L2 roundtrips and waiting for timestamps to be collected and coherent at L2 at a later (fuzzier) time before the parent thread can be woken up? + ## Related - Spine: [[archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id]] diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AmosAnon-was-this-related-to-iepm-i-dont-remember-cdp-but.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AmosAnon-was-this-related-to-iepm-i-dont-remember-cdp-but.md index 7d4f35a..a8fd63f 100644 --- a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AmosAnon-was-this-related-to-iepm-i-dont-remember-cdp-but.md +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-AmosAnon-was-this-related-to-iepm-i-dont-remember-cdp-but.md @@ -7,7 +7,7 @@ author: "Amos Anon" handle: AmosAnon post_id: "2121276265219207518" date: 2026-11-13 -archived: 2026-11-13 +archived: 2026-11-14 draft: false tags: - archive diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-appeal-to-authority-is-a-logical-fallacy-it.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-appeal-to-authority-is-a-logical-fallacy-it.md index 4674b25..a9ecc59 100644 --- a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-appeal-to-authority-is-a-logical-fallacy-it.md +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-appeal-to-authority-is-a-logical-fallacy-it.md @@ -7,7 +7,7 @@ author: ":3" handle: Colonthreee post_id: "2121260635375722605" date: 2026-11-13 -archived: 2026-11-13 +archived: 2026-11-14 draft: false tags: - archive diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-how-about-persistent-threads.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-how-about-persistent-threads.md index 40fb9db..efcb489 100644 --- a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-how-about-persistent-threads.md +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-Colonthreee-how-about-persistent-threads.md @@ -7,7 +7,7 @@ author: ":3" handle: Colonthreee post_id: "2121250089377153126" date: 2026-11-13 -archived: 2026-11-13 +archived: 2026-11-14 draft: false tags: - archive diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-damianGray-you-could-have-been-wrong-but-the-arrogance-of.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-damianGray-you-could-have-been-wrong-but-the-arrogance-of.md index 06ed0d7..9ebae6d 100644 --- a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-damianGray-you-could-have-been-wrong-but-the-arrogance-of.md +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-13-damianGray-you-could-have-been-wrong-but-the-arrogance-of.md @@ -7,7 +7,7 @@ author: "Damian Gray" handle: damianGray post_id: "2121286787410641075" date: 2026-11-13 -archived: 2026-11-13 +archived: 2026-11-14 draft: false tags: - archive diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-14-SebAaltonen-bloated-framework-design-so-many-entrypoints.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-14-SebAaltonen-bloated-framework-design-so-many-entrypoints.md new file mode 100644 index 0000000..df2b8f9 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-14-SebAaltonen-bloated-framework-design-so-many-entrypoints.md @@ -0,0 +1,37 @@ +--- +title: "@NOTimothyLottes Bloated framework design." +type: archive +source: twitter +source_url: "https://x.com/SebAaltonen/status/2121510428740059185" +author: "Sebastian Aaltonen" +handle: SebAaltonen +post_id: "2121510428740059185" +date: 2026-11-14 +archived: 2026-11-14 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes Bloated framework design." +in_reply_to: "" +parent_post_id: "2121259314627195297" +--- + +## Source + +- URL: https://x.com/SebAaltonen/status/2121510428740059185 +- Author: Sebastian Aaltonen (@SebAaltonen) +- Posted: 2026-11-14 07:47:56 + +## Branch + +**1/** **@SebAaltonen** ^2121510428740059185 + +**@NOTimothyLottes** + +Bloated framework design. So many entrypoints today. Hardware has one set of generic SIMD units today. It’s just an abstraction. Makes drivers complicated. And the RT API design is wrong. Not designed for performance. + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id]] diff --git a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/index.md b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/index.md index 9f3a1c4..40758c0 100644 --- a/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/index.md +++ b/archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/index.md @@ -7,7 +7,7 @@ author: "NOTimothyLottes" handle: NOTimothyLottes post_id: "2121244702649532667" date: 2026-11-13 -archived: 2026-11-13 +archived: 2026-11-14 draft: false tags: - archive @@ -173,6 +173,8 @@ Branches: [[archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent- Some of those who got this far are probably realizing now the parallels here - CDP, on-GPU workgraphs, Ray Tracing, they all have horrible designs - all designed to hook the high level thinkers - make the worst way of doing something faster, but never teaching the good stuff. +Branches: [[archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id/2026-11-14-SebAaltonen-bloated-framework-design-so-many-entrypoints]] + **25/** **@NOTimothyLottes** ^2121260463732453668 My suggestion is always the same, profile, look at your sources of latency and memory bandwidth, and re-work your thinking from first principles from the bottom up instead. Minimize everything, what doesn't need to be there, remove that. diff --git a/archive/threads/NOTimothyLottes/index.md b/archive/threads/NOTimothyLottes/index.md index 8aaa36e..1a241ea 100644 --- a/archive/threads/NOTimothyLottes/index.md +++ b/archive/threads/NOTimothyLottes/index.md @@ -157,4 +157,5 @@ tags: - [[archive/threads/NOTimothyLottes/2026-10-04-if-the-deck-1-did-4m-units-youd-only-need-a-2-5]] - [[archive/threads/NOTimothyLottes/2026-10-04-thread-serious-talk-on-steamdeck-2-speculation]] - [[archive/threads/NOTimothyLottes/2026-10-06-if-one-used-bc7-for-a-giant-vq-code-book-like-a]] +- [[archive/threads/NOTimothyLottes/2026-11-07-not-a-joke-im-re-trying-development-through]] - [[archive/threads/NOTimothyLottes/2026-11-13-thankfully-a-friend-sent-this-to-me-otherwise-id]] diff --git a/archive/threads/index.md b/archive/threads/index.md index 9b14736..ab6ec0b 100644 --- a/archive/threads/index.md +++ b/archive/threads/index.md @@ -64,6 +64,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to - [[archive/threads/martin_cohen]] - [[archive/threads/matiasgoldberg]] - [[archive/threads/meesedev]] +- [[archive/threads/mike64_t]] - [[archive/threads/mike_acton]] - [[archive/threads/MissQuickstep]] - [[archive/threads/mmalex]] @@ -75,6 +76,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to - [[archive/threads/noinconsistency]] - [[archive/threads/NOTimothyLottes]] - [[archive/threads/ocornut]] +- [[archive/threads/onatt0]] - [[archive/threads/OSdev_]] - [[archive/threads/pickover]] - [[archive/threads/pikuma]] diff --git a/archive/threads/mike64_t/2026-11-13-at-the-risk-of-saying-something-wrong-on-the/index.md b/archive/threads/mike64_t/2026-11-13-at-the-risk-of-saying-something-wrong-on-the/index.md new file mode 100644 index 0000000..1f50b12 --- /dev/null +++ b/archive/threads/mike64_t/2026-11-13-at-the-risk-of-saying-something-wrong-on-the/index.md @@ -0,0 +1,78 @@ +--- +title: "At the risk of saying something wrong on the internet in hopes of getting corrected, I think one of the best things Nvidia has ever done is the qmd dependent ptr." +type: archive +source: twitter +source_url: "https://x.com/mike64_t/status/2121365444632457412" +author: "mike" +handle: mike64_t +post_id: "2121365444632457412" +date: 2026-11-13 +archived: 2026-11-14 +draft: false +tags: + - archive + - twitter + - mike64_t +description: "At the risk of saying something wrong on the internet in hopes of getting corrected, I think one of the best things Nvidia has ever done is the qmd dependent ptr." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/mike64_t/status/2121365444632457412 +- Author: mike (@mike64_t) +- Posted: 2026-11-13 22:11:49 + +## Thread + +**1/** **@mike64_t** ^2121365444632457412 + +At the risk of saying something wrong on the internet in hopes of getting corrected, I think one of the best things Nvidia has ever done is the qmd dependent ptr. +as far as i can tell, in 2012 the dependent QMD exists in hardware, with no user-facing API beyond whatever the CDP runtime did with it internally. +in 2018, cuda graphs re-abstracts the mechanism to use dependent chains to drive down inter-kernel latency. +In 2022, PDL on Hopper hides the cold I$ issue of dependent kernels with overlap. +In 2026, Vera Rubin fixes the remaining issue of uneven completion with tile-level triggering. +Now I think the dependent ptr and the decrement dependence counters in QMD are one of the best things nvidia has ever done and I think an under-appreciated aspect of what makes CUDA great despite nobody being consciously aware of it... +now I am cautiously awaiting on which side this places me in this debate 😳 + +**2/** **@NOTimothyLottes** ^2121442149736788275 + +**@mike64_t** + +Perhaps move deeper a few levels, why break up problem solving into multiple kernel dispatches? No need to do that in CPU-land, why do it in GPU-land? Must of the unnecessary complexity was added under the theory that one needs to vary registers/wave (thus launch new kernel) ... + +**3/** **@NOTimothyLottes** ^2121442736213778793 + +**@mike64_t** + +Yet maximizing waves/CU does not bring max perf, rather you want to minimize waves/CU to maximize cache/work but stop at the point of still being able to hide latency. And there is another axis of work ILP, where a lane can do N things in parallel instead of 1 ... + +**4/** **@NOTimothyLottes** ^2121443260962947076 + +**@mike64_t** + +Turns out ILP is what you need anyway to hide ALU latency. Etc. Etc. Meaning one can simply fix registers/wave, adapting N to how much work fits in fixed register space, and therefore not need to launch waves any more ... + +**5/** **@NOTimothyLottes** ^2121443822123286667 + +**@mike64_t** + +At that stage one could treat the GPU just like a CPU, running one program. Now people trying to get the last few percent of perf out of the GPU, get kicked down by the variability and volatility of HW scheduling ... + +**6/** **@mike64_t** ^2121454911003254919 + +right, I think you just arrived at the mega kernel discourse from first principles, but register allocation etc is not the only reason why you want to split things into multiple kernels. I think in general composing workloads from kernels when everything has to be one giant binary is a big problem. It's the same dillema as having to recompile a PSO just because you changed some rasterizer state. Your application needs to be able to decide fast and it needs to do so along certain granularities. You already die from data type kernel variant combinatorial explosion just trying to make GEMM-likes work, now think about the possible schedules of orchestrating work for say an NN forward and backward pass. Your hyper parameters are at the end of the day runtime state and you cannot afford to actually compile all those out. I'm not sure I see any other way there than to have a JIT/graph compiler, which I am generally opposed to. I just don't see the mega kernel reacting to config state and then doing the equivalent of control flow on the GPU. That just seems bad. Glueing kernels together with a graph just happens to be a very very good paradigm to get the best of both worlds, not actually needing to have logic to decide what to do next within the kernerls, thus being able to reuse them. Also, a PDL edge is not actually that slow compared to a grid sync. I suspect most mega kernels are wasting more time managing their intra-kernel task-calling convention than they realize. +And not being able to do this is actively holding alternative hardware back to run actual training workloads. I think hardware that thinks "megakernels are the future" only win under a narrow subset of futures where flexibility of no concern while the performance benefits are close to zero. Now, hardware scheduling might sound less appealing depending on what it is you want to do, but if you view cuda graphs as a time-sharing + schedule declaration / overlap api, I think the design space is just more appealing than having to do any of this in isa space. I believe any piece of hardware that thinks this layer of scheduling must happen in ISA is creating unnecessary trouble and self-sabotaging themselves. Having *both* hardware scheduling and instruction level scheduling available to you does create *more* freedom in how you write and orchestrate kernels. There is no reason to double down on any one principle out of a sense of purism. There are cases where you just want to split things into two kernels and eat the PDL edge at a well understood point. say kernel A has associated work in kernel B, and A dependent kernel C, but C does not depend on B. Just get it out of the critical path and b can take however long it takes and you don't need to worry about the "lifetime" of A being long enough to encompass that. + +**7/** **@NOTimothyLottes** ^2121457929328980217 + +**@mike64_t** + +Man the blue check crowd has a serious advantage in text capacity :) I'm for 100% free form (not language or API limited) access to the HW. Solve problems any way you want. But APIs have evolved more to force people into certain ways of doing things, not a fan + +**8/** **@mike64_t** ^2121459529997320399 + +**@NOTimothyLottes** + +Hahah true true. Not looking back on thread splitting xD +i guess its my observation that a very good property seems to have emerged by accident here… or not so much as an accident (?) diff --git a/archive/threads/mike64_t/index.md b/archive/threads/mike64_t/index.md new file mode 100644 index 0000000..9edbfc5 --- /dev/null +++ b/archive/threads/mike64_t/index.md @@ -0,0 +1,12 @@ +--- +title: mike64_t +type: note +draft: false +description: Archived threads by mike64_t. +tags: + - archive + - twitter + - mike64_t +--- + +- [[archive/threads/mike64_t/2026-11-13-at-the-risk-of-saying-something-wrong-on-the]] diff --git a/archive/threads/onatt0/index.md b/archive/threads/onatt0/index.md new file mode 100644 index 0000000..59d52ba --- /dev/null +++ b/archive/threads/onatt0/index.md @@ -0,0 +1,14 @@ +--- +title: onatt0 +type: note +draft: false +description: Archived threads by onatt0. +tags: + - archive + - twitter + - onatt0 +--- + +- [[archive/threads/onatt0/2025-04-30-holy-truthnuke-and-people-think-c-is-the-optimal-state-of]] +- [[archive/threads/onatt0/2025-07-25-onatt0-simple-pure-data-interfaces-in-memory]] +- [[archive/threads/onatt0/2025-11-04-onatt0-gpu-could-decide-the-cpu-control-flow]] diff --git a/archive/threads/pikuma/index.md b/archive/threads/pikuma/index.md index dcb18dd..efb424f 100644 --- a/archive/threads/pikuma/index.md +++ b/archive/threads/pikuma/index.md @@ -18,3 +18,4 @@ tags: - [[archive/threads/pikuma/2025-08-19-you-need-to-walk-before-you-run]] - [[archive/threads/pikuma/2025-08-26-assuming-the-risk-of-appearing-extremely-dumb-in]] - [[archive/threads/pikuma/2026-05-26-nobody-cracks-open-a-programming-book-anymore]] +- [[archive/threads/pikuma/2026-08-25-just-a-heads-up-that-i-have-added-a-few-new]]