From 6f2fa3b25966f3ad5b64fc07901c0b39c7cdefc5 Mon Sep 17 00:00:00 2001 From: Ed_ Date: Wed, 26 Aug 2026 23:31:17 -0400 Subject: [PATCH] 2060513369065754969, 2054216103904063525 --- .../index.md | 44 +++++++++ ...-arm-based-so-its-not-like-a-gpu-in-the.md | 81 ++++++++++++++++ ...unately-few-know-how-to-author-programs.md | 80 ++++++++++++++++ ...ont-think-thats-a-good-idea-theres-some.md | 43 +++++++++ ...unrealistic-to-have-hard-real-time-in-a.md | 49 ++++++++++ ...guys-trying-to-rebuild-the-world-in-the.md | 43 +++++++++ ...problem-are-you-solving-what-is-the-cpu.md | 93 +++++++++++++++++++ ...s-isochron-https-www-isochron-org-about.md | 49 ++++++++++ .../index.md | 36 +++++++ archive/threads/AgileJebrim/index.md | 2 + 10 files changed, 520 insertions(+) create mode 100644 archive/threads/AgileJebrim/2026-05-12-we-have-code-reviews-at-isochron-and-i-require-my/index.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-JesseStojan-its-arm-based-so-its-not-like-a-gpu-in-the.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-NOTimothyLottes-unfortunately-few-know-how-to-author-programs.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-Sacb0y-i-dont-think-thats-a-good-idea-theres-some.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-loganb-seems-unrealistic-to-have-hard-real-time-in-a.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-nate_the_sneak-why-you-guys-trying-to-rebuild-the-world-in-the.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-olenbaranasalat-what-problem-are-you-solving-what-is-the-cpu.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-31-xyzw_io-this-isochron-https-www-isochron-org-about.md create mode 100644 archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/index.md diff --git a/archive/threads/AgileJebrim/2026-05-12-we-have-code-reviews-at-isochron-and-i-require-my/index.md b/archive/threads/AgileJebrim/2026-05-12-we-have-code-reviews-at-isochron-and-i-require-my/index.md new file mode 100644 index 0000000..3f4c9c8 --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-12-we-have-code-reviews-at-isochron-and-i-require-my/index.md @@ -0,0 +1,44 @@ +--- +title: "We have code reviews at Isochron and I require my devs to produce streamlined, not modular, code." +type: archive +source: twitter +source_url: "https://x.com/AgileJebrim/status/2054216103904063525" +author: "Jebrim" +handle: AgileJebrim +post_id: "2054216103904063525" +date: 2026-05-12 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "We have code reviews at Isochron and I require my devs to produce streamlined, not modular, code." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/AgileJebrim/status/2054216103904063525 +- Author: Jebrim (@AgileJebrim) +- Posted: 2026-05-12 15:04:19 + +## Thread + +**1/** **@AgileJebrim** ^2054216103904063525 + +We have code reviews at Isochron and I require my devs to produce streamlined, not modular, code. + +Too many modules and interfaces is how you achieve a complex bloated Raptor 1 design. + +Streamlining by inlining to eliminate interfaces is how you achieve a Raptor 3 design. + +![](https://pbs.twimg.com/media/HIIKhDLXQAE8P3p?format=jpg&name=orig) + +**2/** **@AgileJebrim** ^2054216901069246938 + +Each module must be so custom to a particular task to be efficient for it that it’s simply not practical for it to be designed in a modular manner. + +Otherwise you focus so much on the generic portability and reusability of each individual module that you make it highly inefficient and needlessly complex for your particular task. + +Produce your entire product this way and you get a lot of added dev times, architectural tension, and little to show for it as you didn’t really actually require such modularity in the first place. diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-JesseStojan-its-arm-based-so-its-not-like-a-gpu-in-the.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-JesseStojan-its-arm-based-so-its-not-like-a-gpu-in-the.md new file mode 100644 index 0000000..17e3b11 --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-JesseStojan-its-arm-based-so-its-not-like-a-gpu-in-the.md @@ -0,0 +1,81 @@ +--- +title: "It's ARM based, so it's not like a GPU in the traditional sense, NVIDIA has made CPU/APUs AFAIK." +type: archive +source: twitter +source_url: "https://x.com/JesseStojan/status/2060540898149048338" +author: "Jesse S" +handle: JesseStojan +post_id: "2060540898149048338" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "It's ARM based, so it's not like a GPU in the traditional sense, NVIDIA has made CPU/APUs AFAIK." +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/JesseStojan/status/2060540898149048338 +- Author: Jesse S (@JesseStojan) +- Posted: 2026-05-30 01:56:47 + +## Branch + +**1/** **@JesseStojan** ^2060540898149048338 + +It's ARM based, so it's not like a GPU in the traditional sense, NVIDIA has made CPU/APUs AFAIK. So the difference is probably going to be unified memory like Apple and NVIDIA DGX, alongside others going that route. The gaming side and even the professional workstation side is nothing compared to their server side products. + +**2/** **@AgileJebrim** ^2060543431538037055 + +**@JesseStojan** + +We already develop for the Tegra-based Jetson, so that’s fine. + +**3/** **@JesseStojan** ^2060559836023022012 + +**@AgileJebrim** + +Nice, I've been focusing on CNC/CAE and simulation/analysis stuff, so it's a mix of CPU and whatever hardware is available, I'll utilize the iGPU to squeeze out every last drop of performance if I have to. + +**4/** **@AgileJebrim** ^2060560952844485032 + +**@JesseStojan** + +We’re really big on trying to eliminate offline steps entirely from the stack. Everything is real-time, including the dev tools. No static analysis. + +**5/** **@AgileJebrim** ^2060561152082333950 + +**@JesseStojan** + +Basically have a solidly proven compiler and interpreter such that everything else built on top of it just works. + +**6/** **@JesseStojan** ^2060567168689836209 + +**@AgileJebrim** + +No static analysis sounds pretty wild. Though idk what you're working on aside from it being rendering related and you've been making your own programming language for it. I'm cool with both real-time and offline rendering though. Especially massive parallelism. + +**7/** **@AgileJebrim** ^2060569318899773465 + +Well the compiler itself needs to be tested to death to ensure no varying performance instructions can be generated. But anything built on top will not, that’s the beauty that makes it stand apart from anything else on the market in SC. + +We’re not just doing rendering. This can power a metaverse server, editor, or even a social media server like X, alongside a client for it. This can run the computer vision for autonomous vehicles and robotics. + +Even the editor itself is being created on top of it and is a client-server application to allow for version control and real-time multi-user collaboration. We aren’t doing a text-based language, so traditional offline tools won’t work. + +Quite literally rebuilding a new stack from the bottom up. Lots of work to do. + +**8/** **@JesseStojan** ^2060571172887023876 + +**@AgileJebrim** + +Niceee, yeah the SDK I've been working on has all the cross platform/architecture support for IPC, Rendering, Physics, etc.. the whole stack. Mostly freestanding C++ and Assembly. That'd be interesting to see what you're cooking up, I'd imagine a node based graph like Houdini? + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-NOTimothyLottes-unfortunately-few-know-how-to-author-programs.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-NOTimothyLottes-unfortunately-few-know-how-to-author-programs.md new file mode 100644 index 0000000..d50fa1e --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-NOTimothyLottes-unfortunately-few-know-how-to-author-programs.md @@ -0,0 +1,80 @@ +--- +title: "@AgileJebrim Unfortunately few know how to author programs that could fit in the GPUs tiny instruction caches." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2060536518024855743" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2060536518024855743" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "@AgileJebrim Unfortunately few know how to author programs that could fit in the GPUs tiny instruction caches." +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2060536518024855743 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-05-30 01:39:23 + +## Branch + +**1/** **@NOTimothyLottes** ^2060536518024855743 + +**@AgileJebrim** + +Unfortunately few know how to author programs that could fit in the GPUs tiny instruction caches. They definitely overbuild scalar SALU capacity on AMD , if stick to wave64 for parallel vector work, there are lots of free issue slots for scalar workloads. + +**2/** **@AgileJebrim** ^2060536966194556958 + +**@NOTimothyLottes** + +This is why we’re doing our own custom visual shader language. They’ll be required to make passes of a limited instruction size and data buffers of a limited size. We can talk more about it privately. + +**3/** **@NOTimothyLottes** ^2060538886539837470 + +**@AgileJebrim** + +For one employer, one of my projects actually pushes the limit of the I$ for a complex vector workload. It requires rethinking classic GPU workload distribution. + +**4/** **@NOTimothyLottes** ^2060539563378942151 + +**@AgileJebrim** + +Traditional GPU kernel launch goes wide first. So if you have say just enough work in the kernel to fill the GPU once, you never hit good efficiency due to servicing I$ misses across all those caches. + +**5/** **@NOTimothyLottes** ^2060540118390186338 + +**@AgileJebrim** + +So small tasks on the GPU require persistent waves looping through work instead, limiting launch to say one CU and running for longer. This way enough of the workload runs in the warmed I$. + +**6/** **@AgileJebrim** ^2060541173685436901 + +**@NOTimothyLottes** + +Nah. We’re literally aiming for a single persistent dispatch to rule them all, controlling all the SMs/CUs/EUs in full shader-side. Never letting the CPU even have a chance at interfering. + +**7/** **@NOTimothyLottes** ^2060542249574764955 + +**@AgileJebrim** + +Oh I’ve gone there, always get limited by vendor shader compilers that cannot handle large shaders. Need a large tool bag of workarounds to trick the compiler into not doing common sub expression elimination (especially for memory ops) + +**8/** **@NOTimothyLottes** ^2060543164994159077 + +**@AgileJebrim** + +If the vendors just opened up gfx apis to external shader +compilation with 3rd party tool chains we could easily start a GPU programming golden age, one compiled kernel just like the CPU. + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-Sacb0y-i-dont-think-thats-a-good-idea-theres-some.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-Sacb0y-i-dont-think-thats-a-good-idea-theres-some.md new file mode 100644 index 0000000..7f85f5d --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-Sacb0y-i-dont-think-thats-a-good-idea-theres-some.md @@ -0,0 +1,43 @@ +--- +title: "I don't think thats a good idea, there's some escalating problems where games focus too much on GPU methods and end up suffering as a result." +type: archive +source: twitter +source_url: "https://x.com/Sacb0y/status/2060704573795283381" +author: "🔞 Our Apartment by Sacb0y" +handle: Sacb0y +post_id: "2060704573795283381" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "I don't think thats a good idea, there's some escalating problems where games focus too much on GPU methods and end up suffering as a result." +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/Sacb0y/status/2060704573795283381 +- Author: 🔞 Our Apartment by Sacb0y (@Sacb0y) +- Posted: 2026-05-30 12:47:11 + +## Branch + +**1/** **@Sacb0y** ^2060704573795283381 + +I don't think thats a good idea, there's some escalating problems where games focus too much on GPU methods and end up suffering as a result. + +Plus as a PC user, there's benefits to say when I'm rendering something and it's all on the GPU and not locking up the CPU so I can still use the PC. + +**2/** **@AgileJebrim** ^2060760957911962084 + +**@Sacb0y** + +I think you’re arguing against a red herring because nothing I’m talking about here reflects your complaints. + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-loganb-seems-unrealistic-to-have-hard-real-time-in-a.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-loganb-seems-unrealistic-to-have-hard-real-time-in-a.md new file mode 100644 index 0000000..e172674 --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-loganb-seems-unrealistic-to-have-hard-real-time-in-a.md @@ -0,0 +1,49 @@ +--- +title: "@AgileJebrim Seems unrealistic to have hard real-time in a general purpose OS." +type: archive +source: twitter +source_url: "https://x.com/loganb/status/2060543691291607199" +author: "Logan Bowers 🏗️ 🏘️" +handle: loganb +post_id: "2060543691291607199" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "@AgileJebrim Seems unrealistic to have hard real-time in a general purpose OS." +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/loganb/status/2060543691291607199 +- Author: Logan Bowers 🏗️ 🏘️ (@loganb) +- Posted: 2026-05-30 02:07:53 + +## Branch + +**1/** **@loganb** ^2060543691291607199 + +**@AgileJebrim** + +Seems unrealistic to have hard real-time in a general purpose OS. At least no one has done it yet. + +**2/** **@AgileJebrim** ^2060545289778328000 + +**@loganb** + +If they ran on the same hardware, that would be true. But we’re running on isolated GPU cores with isolated memory instead. The CPU side isn’t allowed to interfere with them. + +**3/** **@AgileJebrim** ^2060546330645213562 + +**@loganb** + +This also means bypassing the compositor and drawing directly to the display. + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-nate_the_sneak-why-you-guys-trying-to-rebuild-the-world-in-the.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-nate_the_sneak-why-you-guys-trying-to-rebuild-the-world-in-the.md new file mode 100644 index 0000000..4227a6b --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-nate_the_sneak-why-you-guys-trying-to-rebuild-the-world-in-the.md @@ -0,0 +1,43 @@ +--- +title: "@AgileJebrim Why you guys trying to rebuild the world in the image of the raspberry pi?" +type: archive +source: twitter +source_url: "https://x.com/nate_the_sneak/status/2060514346371863032" +author: "Shame WoW!!!" +handle: nate_the_sneak +post_id: "2060514346371863032" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "@AgileJebrim Why you guys trying to rebuild the world in the image of the raspberry pi?" +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/nate_the_sneak/status/2060514346371863032 +- Author: Shame WoW!!! (@nate_the_sneak) +- Posted: 2026-05-30 00:11:17 + +## Branch + +**1/** **@nate_the_sneak** ^2060514346371863032 + +**@AgileJebrim** + +Why you guys trying to rebuild the world in the image of the raspberry pi? + +**2/** **@AgileJebrim** ^2060514806143103120 + +**@nate_the_sneak** + +Because raspberry pis do not offer trivial hard real-time guarantees. + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-olenbaranasalat-what-problem-are-you-solving-what-is-the-cpu.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-olenbaranasalat-what-problem-are-you-solving-what-is-the-cpu.md new file mode 100644 index 0000000..d8f82ec --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-olenbaranasalat-what-problem-are-you-solving-what-is-the-cpu.md @@ -0,0 +1,93 @@ +--- +title: "What problem are you solving? What is the CPU lacking, and what does the GPU offer when the OS is ported to it? And I’m curious to know how you deal with stalls." +type: archive +source: twitter +source_url: "https://x.com/olenbaranasalat/status/2060552308052615363" +author: "Гала Перидоловна 🇳🇵" +handle: olenbaranasalat +post_id: "2060552308052615363" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "What problem are you solving? What is the CPU lacking, and what does the GPU offer when the OS is ported to it? And I’m curious to know how you deal with stalls." +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/olenbaranasalat/status/2060552308052615363 +- Author: Гала Перидоловна 🇳🇵 (@olenbaranasalat) +- Posted: 2026-05-30 02:42:08 + +## Branch + +**1/** **@olenbaranasalat** ^2060552308052615363 + +What problem are you solving? What is the CPU lacking, and what does the GPU offer when the OS is ported to it? And I’m curious to know how you deal with stalls. Have you written your own branch predictor and are you manually inserting something into each Warp? I’m also curious to know how you handle threads. Do all threads run sequentially on each Warp? + +**2/** **@AgileJebrim** ^2060557227581112684 + +“What problem are you solving?” + +Hard real-time guarantees are too difficult and expensive to verify in the safety-critical market and usually requires leveraging expensive and dated custom hardware and software toolchains. This is doubly so when needing high performance requirements for stuff like computer vision, sensor fusion, autonomous vehicles, enhanced flight vision systems, HWIL sims, robotics, etc. + +We’re looking to make it cheap to produce such high performance safety-critical systems on existing affordable COTS hardware. + +“What is the CPU lacking, and what does the GPU offer when the OS is ported to it?” + +CPU lacks a programmer-managed cache. GPUs have scratchpad memory. They also cannot be arbitrarily interrupted. We don’t pursue a preemption-based design but instead actually target having EVERYTHING on the GPU meet the real-time deadline, thereby avoiding the problem entirely. This is achieved through a custom compiler we’re building that guarantees isochronous (constant time) execution, minimizing jitter. This also works very well with SIMD. + +Your later questions have too many false premises. We don’t have a branch predictor because nothing ever branches or diverges to begin with. All hardware runs the same code, syncs, then runs the next bit of code. No warp specialization is planned at this time. + +**3/** **@AgileJebrim** ^2060557537863139453 + +**@olenbaranasalat** + +The other problem we’re solving is data, not just code. Changing the data should not require recertifying anything. It should just work with the same execution times as any other data input. + +**4/** **@olenbaranasalat** ^2060719310603972993 + +How do you prove constant-time execution in the presence of global memory, barriers, bank conflicts, DRAM arbitration, TLB/IOMMU behavior? Is your model a general RTOS, or more like a statically scheduled synchronous dataflow runtime? Is your GPU-native RTOS mainly meant for deterministic high-performance perception/data processing, rather than replacing the cheaper and well-understood MCU/FPGA layer for physical hard real-time control? + +**5/** **@AgileJebrim** ^2060764703186460992 + +Great questions! + +We do not allow for random access memory. Everything from global memory is linearly streamed in. Random access lookups are only allowed to occur within shared memory on 64KB tiles or shuffles within a warp. To avoid bank conflicts in shared memory, we utilize warp-uniform techniques. + +Barriers are a potential source of slight jitter fluctuations, especially when globally syncing, but they are data-independent, few in number, and well-bounded. It helps a lot that all threads have equal execution times. + +We have techniques to avoid getting bottlenecked by CPU-side interference. It’s important to not directly share resources with them at arbitrary points. We treat the CPU as unreliable low priority background threads to be safe. + +You can get both experiences. The former is supported via a scripting language where we interpret bytecode dynamically at runtime with a fixed amount of cycles per task, sacrificing throughput to achieve arbitrary code execution. The latter is precompiled in with a static schedule. + +It’ll all still be relatively static compared to a typical RTOS simply because RTOSes are not actually guaranteeing all threads within them are high criticality. They’re assuming some are low priority; we don’t have that problem. We dedicate 100% of all GPU hardware to a single task before moving on to the next. No preemption. + +Both. Competing against FPGAs is one of my biggest goals with this. We can achieve their isochronous behavior but with much higher bandwidth, all on cheap COTS hardware that people already have. + +I’m going quite broadly with the applications I have in mind of supporting. You could do sensor fusion, computer vision, and autonomous driving with this, sure, but you could also use it to power a metaverse or social media app like X. Reduce your costs by replacing distributed microservices with SIMT lanes. + +**6/** **@olenbaranasalat** ^2060772978128814271 + +**@AgileJebrim** + +Not gonna lie, I’m a bit jealous — this sounds like an insanely fun systems problem to work on. + +**7/** **@AgileJebrim** ^2060774071479013674 + +**@olenbaranasalat** + +What’s your rate? We can dm. + +**8/** **@olenbaranasalat** ^2060781078843957541 + +Thank you, but I only interview candidates for roles related to GPUs, so I’ve had to familiarise myself with how GPUs work. My main specialism is I/O virtualisation. I have little production experience writing code for GPUs - at most, I’ve run tests to assess inference performance in virtual machines. I’m unlikely to be the right fit for you :) + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-31-xyzw_io-this-isochron-https-www-isochron-org-about.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-31-xyzw_io-this-isochron-https-www-isochron-org-about.md new file mode 100644 index 0000000..eb07eb2 --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-31-xyzw_io-this-isochron-https-www-isochron-org-about.md @@ -0,0 +1,49 @@ +--- +title: "@AgileJebrim This Isochron https://www.isochron.org/about ?" +type: archive +source: twitter +source_url: "https://x.com/xyzw_io/status/2061097305143390348" +author: "xyzw" +handle: xyzw_io +post_id: "2061097305143390348" +date: 2026-05-31 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "@AgileJebrim This Isochron https://www.isochron.org/about ?" +in_reply_to: "" +parent_post_id: "2060513369065754969" +--- + +## Source + +- URL: https://x.com/xyzw_io/status/2061097305143390348 +- Author: xyzw (@xyzw_io) +- Posted: 2026-05-31 14:47:45 + +## Branch + +**1/** **@xyzw_io** ^2061097305143390348 + +**@AgileJebrim** + +This Isochron https://www.isochron.org/about ? + +**2/** **@AgileJebrim** ^2061098721262133300 + +**@xyzw_io** + +No. We don’t really have a public presence at this time detailing our future products. It’s mostly just my X account, @IsochronTech (empty atm), and my Discord server. + +https://www.isochrontechnologies.com + +**3/** **@AgileJebrim** ^2061099593874440320 + +I suppose I should mention http://www.jebscape.com too as that’s part of our IP as well. Our Pred product in many ways is building upon the lessons learned in that project and is borrowing some of the code and design principles from it. I give our team members access to that server source for inspiration. + +## Related + +- Spine: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]] diff --git a/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/index.md b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/index.md new file mode 100644 index 0000000..85e422c --- /dev/null +++ b/archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/index.md @@ -0,0 +1,36 @@ +--- +title: "I don’t think hardware vendors are going to practically be able to ditch the CPU from system architectures any more than they’ll ditch the GPU, but I do think the GPU should become the master device driving decisions rather than just a slave accelerator for heterogeneous apps." +type: archive +source: twitter +source_url: "https://x.com/AgileJebrim/status/2060513369065754969" +author: "Jebrim" +handle: AgileJebrim +post_id: "2060513369065754969" +date: 2026-05-30 +archived: 2026-08-26 +draft: false +tags: + - archive + - twitter + - AgileJebrim +description: "I don’t think hardware vendors are going to practically be able to ditch the CPU from system architectures any more than they’ll ditch the GPU, but I do think the GPU should become the master device driving decisions rather than just a slave accelerator for heterogeneous apps." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/AgileJebrim/status/2060513369065754969 +- Author: Jebrim (@AgileJebrim) +- Posted: 2026-05-30 00:07:24 + +## Thread + +**1/** **@AgileJebrim** ^2060513369065754969 + +I don’t think hardware vendors are going to practically be able to ditch the CPU from system architectures any more than they’ll ditch the GPU, but I do think the GPU should become the master device driving decisions rather than just a slave accelerator for heterogeneous apps. + +We (Isochron) believe we have a method of doing something like that by creating a GPU-native RTOS. It however won’t boot directly into it (although that would be nice) as we still depend upon existing third party drivers for I/O, but the GPU RTOS would run in parallel alongside a CPU-based OS as a hard real-time coprocessor without interference from the CPU. + +What’s key here is that all control logic is on the GPU itself and is what tells the CPU what to do, such as load data from disk or send packets out over the network. + +Branches: [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-nate_the_sneak-why-you-guys-trying-to-rebuild-the-world-in-the]], [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-NOTimothyLottes-unfortunately-few-know-how-to-author-programs]], [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-JesseStojan-its-arm-based-so-its-not-like-a-gpu-in-the]], [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-loganb-seems-unrealistic-to-have-hard-real-time-in-a]], [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-olenbaranasalat-what-problem-are-you-solving-what-is-the-cpu]], [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-30-Sacb0y-i-dont-think-thats-a-good-idea-theres-some]], [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to/2026-05-31-xyzw_io-this-isochron-https-www-isochron-org-about]] diff --git a/archive/threads/AgileJebrim/index.md b/archive/threads/AgileJebrim/index.md index b1df965..dbf36a6 100644 --- a/archive/threads/AgileJebrim/index.md +++ b/archive/threads/AgileJebrim/index.md @@ -11,3 +11,5 @@ tags: - [[archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no]] - [[archive/threads/AgileJebrim/2025-02-09-check-your-compiler]] +- [[archive/threads/AgileJebrim/2026-05-12-we-have-code-reviews-at-isochron-and-i-require-my]] +- [[archive/threads/AgileJebrim/2026-05-30-i-dont-think-hardware-vendors-are-going-to]]