From 09e0d9b8ea0c1ad7d15b537537bed0eed9d58dca Mon Sep 17 00:00:00 2001 From: Ed_ Date: Tue, 25 Aug 2026 23:48:10 -0400 Subject: [PATCH] 1946452873656631650 --- ...-about-when-each-stage-depends-upon-the.md | 101 +++++++++++++++++ ...-sure-you-cant-do-this-properly-for-the.md | 103 ++++++++++++++++++ ...-remember-the-gpu-scheduler-ruining-the.md | 49 +++++++++ ...is-that-possible-when-you-have-a-linear.md | 77 +++++++++++++ .../index.md | 50 +++++++++ archive/threads/NOTimothyLottes/index.md | 1 + 6 files changed, 381 insertions(+) create mode 100644 archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-AgileJebrim-what-about-when-each-stage-depends-upon-the.md create mode 100644 archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-ISzlachtycz-im-pretty-sure-you-cant-do-this-properly-for-the.md create mode 100644 archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-bmcnett-i-remember-the-gpu-scheduler-ruining-the.md create mode 100644 archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-jakubtomsu_-is-that-possible-when-you-have-a-linear.md create mode 100644 archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/index.md diff --git a/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-AgileJebrim-what-about-when-each-stage-depends-upon-the.md b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-AgileJebrim-what-about-when-each-stage-depends-upon-the.md new file mode 100644 index 0000000..c49c67e --- /dev/null +++ b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-AgileJebrim-what-about-when-each-stage-depends-upon-the.md @@ -0,0 +1,101 @@ +--- +title: "@NOTimothyLottes What about when each stage depends upon the results of the previous stage?" +type: archive +source: twitter +source_url: "https://x.com/AgileJebrim/status/1946573560840958248" +author: "Jebrim" +handle: AgileJebrim +post_id: "1946573560840958248" +date: 2025-07-19 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes What about when each stage depends upon the results of the previous stage?" +in_reply_to: "" +parent_post_id: "1946453750085808492" +--- + +## Source + +- URL: https://x.com/AgileJebrim/status/1946573560840958248 +- Author: Jebrim (@AgileJebrim) +- Posted: 2025-07-19 14:11:17 + +## Branch + +**1/** **@AgileJebrim** ^1946573560840958248 + +**@NOTimothyLottes** + +What about when each stage depends upon the results of the previous stage? + +**2/** **@AgileJebrim** ^1946574048575533243 + +**@NOTimothyLottes** + +I guess that’s the same question as this. I think it’s still fine to have some gaps when syncing but to better aim for more evenly distributed execution times between cores and to keep these sync points to a minimum. + +https://x.com/jakubtomsu_/status/1946485199006498933?s=46&t=ZbNecpPBsBMrvteeaA6IcA + +**3/** **@NOTimothyLottes** ^1946576354905911587 + +**@AgileJebrim** + +What do you do if a worker in a wide-multithread dependency chain gets preempted? The house of cards should fall right? Or one can offer self healing, instead of waiting on a specific fine grain dependency, use work duplication to avoid waiting. + +**4/** **@AgileJebrim** ^1946577376915120212 + +**@NOTimothyLottes** + +You just don’t allow for preemption to occur. I assume we’re talking OS/CPUs at this point rather than GPUs. You pin threads to cores and assign them the highest criticality/priority. On Linux we use the FIFO scheduler and isolate the OS, drivers, and IRQs to non-critical cores. + +**5/** **@AgileJebrim** ^1946577673179861353 + +**@NOTimothyLottes** + +There’s a bit of OS configuration involved to achieve this. + +**6/** **@AgileJebrim** ^1946578113657237820 + +**@NOTimothyLottes** + +Disabling SMT/hyperthreading is another one. + +**7/** **@AgileJebrim** ^1946578976064835720 + +**@NOTimothyLottes** + +All of this works fine if you control the hardware and system yourself but is more problematic if you don’t. This is one of many reasons why I’d prefer living within a GPU dispatch instead. Much harder to get interrupted by anything and much more portable on end user machines. + +**8/** **@NOTimothyLottes** ^1946596411513954798 + +**@AgileJebrim** + +Unfortunately consumer platforms with GPUs have OEM overlords who take over the GPU with irregular behavior for their purposes. Things like multi-monitor with OS windowing compositors are norm and highly irregular behavior. + +**9/** **@AgileJebrim** ^1946596970304278694 + +**@NOTimothyLottes** + +Even NVIDIA’s DriveOS/Tegra platform with Vulkan SC is using a compositor. That surprised me. + +**10/** **@AgileJebrim** ^1946597247954612264 + +**@NOTimothyLottes** + +Ironically their non-certified Vulkan SC driver on Windows does not and completely bypasses it with direct to display. + +**11/** **@AgileJebrim** ^1946598012152959081 + +**@NOTimothyLottes** + +Quite frankly, I think we in the flight sim industry should consider using direct-to-display. See this extension: + +VK_KHR_display + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver]] diff --git a/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-ISzlachtycz-im-pretty-sure-you-cant-do-this-properly-for-the.md b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-ISzlachtycz-im-pretty-sure-you-cant-do-this-properly-for-the.md new file mode 100644 index 0000000..f675823 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-ISzlachtycz-im-pretty-sure-you-cant-do-this-properly-for-the.md @@ -0,0 +1,103 @@ +--- +title: "@NOTimothyLottes Im pretty sure you cant do this properly for the physics workload, because it would mess with the convergence of the optimizer." +type: archive +source: twitter +source_url: "https://x.com/ISzlachtycz/status/1946605956785184781" +author: "Ihor_Szlachtycz 🇺🇦" +handle: ISzlachtycz +post_id: "1946605956785184781" +date: 2025-07-19 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes Im pretty sure you cant do this properly for the physics workload, because it would mess with the convergence of the optimizer." +in_reply_to: "" +parent_post_id: "1946453750085808492" +--- + +## Source + +- URL: https://x.com/ISzlachtycz/status/1946605956785184781 +- Author: Ihor_Szlachtycz 🇺🇦 (@ISzlachtycz) +- Posted: 2025-07-19 16:20:00 + +## Branch + +**1/** **@ISzlachtycz** ^1946605956785184781 + +**@NOTimothyLottes** + +Im pretty sure you cant do this properly for the physics workload, because it would mess with the convergence of the optimizer. Processing color b would mess with the processing of color a, and add randomness to the order of resolving constraints. + +**2/** **@NOTimothyLottes** ^1946609109375041541 + +**@ISzlachtycz** + +So much lost in translation. The methods I'm suggesting don't change the answer, they change the ordering of execution of independent pairs while keeping dependent ordering the same. + +**3/** **@NOTimothyLottes** ^1946609910432600507 + +**@ISzlachtycz** + +Another extreme example, if you color first and take a sufficiently random sampling of pairs, you can hierarchy resolve the earlier color dependencies until the object you need to process is in the right update state too ... + +**4/** **@NOTimothyLottes** ^1946610706909950118 + +**@ISzlachtycz** + +Doing things this way requires versioning by color though (memory) and can sometimes involve some work duplication. But it allows a sufficiently large complex problem to get pipelined parallelization. + +**5/** **@NOTimothyLottes** ^1946611382708834700 + +**@ISzlachtycz** + +This family of ideas is how I did my hierarchical cone stepped ray macher in my GTC demo about a decade back. The core ideas involve moving a hierarchical dependent workload into a single dispatch without any barriers. + +**6/** **@NOTimothyLottes** ^1946612166791946530 + +**@ISzlachtycz** + +You guarantee correctness by risking some amount of work duplication if the dependency isn't satisfied by the time the answer is needed. But in practice it is possible to make it so that duplication is rare and massive optimization is guaranteed. + +**7/** **@NOTimothyLottes** ^1946612579087839232 + +**@ISzlachtycz** + +It also naturally adapts to highly irregular behavior and changing machine size, etc. while being robust to cores getting preempted (self healing, whatever is running is guaranteed to continue forward progress) + +**8/** **@ISzlachtycz** ^1946613205779837126 + +**@NOTimothyLottes** + +So if you have colors a and b, you process color a and b in parallel, but when you run into a situation where some constraint from color b needs results from color a to be completed, you just have it process those dependencies right there? + +**9/** **@ISzlachtycz** ^1946613231071478069 + +**@NOTimothyLottes** + +Then when color a processing gets to those nodes, you recompute them and restore them? + +**10/** **@NOTimothyLottes** ^1946618143498973205 + +**@ISzlachtycz** + +If version of the object at a specific finished prior colors isn't available, you just recursively build those dependencies so you can finish the job. But you save the versioned objects so others won't have to recompute in practice ... + +**11/** **@ISzlachtycz** ^1946618734728065201 + +**@NOTimothyLottes** + +Yeah makes sense. I guess you gotta keep some metadata around to know whether the object is computed or not, but i get the idea. Maybe sometimes it can be implicitly figured out. Thanks for the explanation :) + +**12/** **@ISzlachtycz** ^1946618995697754615 + +**@NOTimothyLottes** + +I guess you do run the risk of the island approach though, where the dependency chain can grow to be quite large. But i havent worked in large physics sims, so not sure how it would work in practice + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver]] diff --git a/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-bmcnett-i-remember-the-gpu-scheduler-ruining-the.md b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-bmcnett-i-remember-the-gpu-scheduler-ruining-the.md new file mode 100644 index 0000000..0f396ae --- /dev/null +++ b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-bmcnett-i-remember-the-gpu-scheduler-ruining-the.md @@ -0,0 +1,49 @@ +--- +title: "@NOTimothyLottes i remember the GPU scheduler ruining the implementation of many clever hardware features" +type: archive +source: twitter +source_url: "https://x.com/bmcnett/status/1946598602274668836" +author: "bmcnett" +handle: bmcnett +post_id: "1946598602274668836" +date: 2025-07-19 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes i remember the GPU scheduler ruining the implementation of many clever hardware features" +in_reply_to: "" +parent_post_id: "1946452873656631650" +--- + +## Source + +- URL: https://x.com/bmcnett/status/1946598602274668836 +- Author: bmcnett (@bmcnett) +- Posted: 2025-07-19 15:50:47 + +## Branch + +**1/** **@bmcnett** ^1946598602274668836 + +**@NOTimothyLottes** + +i remember the GPU scheduler ruining the implementation of many clever hardware features + +**2/** **@NOTimothyLottes** ^1946600327408423288 + +**@bmcnett** + +It's a constant fight on AMD HW against the HW wave scheduler when working on highly VALU loaded workloads and not being able to get forward progress in other waves to keep memory requests saturated enough to avoid pipeline bubbles + +**3/** **@bmcnett** ^1946603750917128458 + +**@NOTimothyLottes** + +there was some discussion of software scheduling, which I still believe is more worthy of silicon than RTX etc. + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver]] diff --git a/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-jakubtomsu_-is-that-possible-when-you-have-a-linear.md b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-jakubtomsu_-is-that-possible-when-you-have-a-linear.md new file mode 100644 index 0000000..f7f8c9d --- /dev/null +++ b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-jakubtomsu_-is-that-possible-when-you-have-a-linear.md @@ -0,0 +1,77 @@ +--- +title: "@NOTimothyLottes Is that possible when you have a linear dependency chain with no independent work? I can't think of anything other thanks splitting up the workload even more, which doesn't sound great" +type: archive +source: twitter +source_url: "https://x.com/jakubtomsu_/status/1946485199006498933" +author: "Jakub Tomšů" +handle: jakubtomsu_ +post_id: "1946485199006498933" +date: 2025-07-19 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes Is that possible when you have a linear dependency chain with no independent work? I can't think of anything other thanks splitting up the workload even more, which doesn't sound great" +in_reply_to: "" +parent_post_id: "1946453750085808492" +--- + +## Source + +- URL: https://x.com/jakubtomsu_/status/1946485199006498933 +- Author: Jakub Tomšů (@jakubtomsu_) +- Posted: 2025-07-19 08:20:10 + +## Branch + +**1/** **@jakubtomsu_** ^1946485199006498933 + +**@NOTimothyLottes** + +Is that possible when you have a linear dependency chain with no independent work? I can't think of anything other thanks splitting up the workload even more, which doesn't sound great + +**2/** **@NOTimothyLottes** ^1946572986628108566 + +**@jakubtomsu_** + +Even the typical serially dependent post processing passes can be chunked spatially to re-introduce pipelining. + +**3/** **@NOTimothyLottes** ^1946574786861121592 + +**@jakubtomsu_** + +Besides cutting groups into pipelinable subsets, one could unfactor the global barrier counter into the objects. So that a queue can start on pairs early if they have completed before the whole independent group finishes. + +**4/** **@AgileJebrim** ^1946575640368709944 + +The problem with pipelining is that you still get idleness as it’s only as fast as the slowest pipeline stage. It makes it difficult to optimize and improve overall performance if the thing you’re optimizing isn’t what’s bottlenecking the system. A more purely data parallel approach allows for any stage to be optimized and have an improvement on the entire tick’s execution time. + +**5/** **@NOTimothyLottes** ^1946582048224768487 + +**@AgileJebrim** **@jakubtomsu_** + +One cannot maintain high utilization in a problem with high non-pipelined global barriers. Period. And as the presentation showed extremely well, as core count increases mixed with the natural irregular thread completion times, the whole machine idle time gets quite big. + +**6/** **@NOTimothyLottes** ^1946584861713584280 + +**@AgileJebrim** **@jakubtomsu_** + +Long ago during my time at a GPU IHV, I had implemented a driver perf strategy that uid'ed barriers per title and selectively ignored them. Running the games at very low resolutions to get conservative set. Even back then one could find double digit perf returns in trace replays. + +**7/** **@NOTimothyLottes** ^1946586982311707005 + +**@AgileJebrim** **@jakubtomsu_** + +Fast forward to modern times, it wouldn't be surprising to see GPUs with under 50% whole frame utilization of both ALU and MEM due to lack of keeping the work flowing well in the machine. + +**8/** **@NOTimothyLottes** ^1946588772419719389 + +**@AgileJebrim** **@jakubtomsu_** + +And in that, some good amount is non pipelined barriers, mixed with other bottlenecks. This poor utilization is likely why IHVs are burning area on fine grain clock gaiting which wouldn't help if devs all authored like power virus + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver]] diff --git a/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/index.md b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/index.md new file mode 100644 index 0000000..f799ddf --- /dev/null +++ b/archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/index.md @@ -0,0 +1,50 @@ +--- +title: "Peanut gallery vs Parallelizing the Physics Solver" +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/1946452873656631650" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "1946452873656631650" +date: 2025-07-19 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Peanut gallery vs Parallelizing the Physics Solver" +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/1946452873656631650 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2025-07-19 06:11:43 + +## Thread + +**1/** **@NOTimothyLottes** ^1946452873656631650 + +Peanut gallery vs Parallelizing the Physics Solver +(1.) Yeah always write your own low level primitives for CPU stuff. It's cool to see just how bad std+OS sync actually is visually in this presentation +(2.) Presentation never fully optimized! ... + +![](https://pbs.twimg.com/media/GwMwA9dXYAAwYaO?format=jpg&name=orig) + +Branches: [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-bmcnett-i-remember-the-gpu-scheduler-ruining-the]] + +**2/** **@NOTimothyLottes** ^1946453750085808492 + +The graph coloring splits into serialized batches of independent work, but this is the DX GPU way of doing stuff, ZERO pipelining (still huge idle gaps). Would be far better to split into pipelined (overlapped) batches -> +do(A) +do(B) +wait(A) +do(C) +wait(B) +do(D) +wait(C) +... + +Branches: [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-jakubtomsu_-is-that-possible-when-you-have-a-linear]], [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-AgileJebrim-what-about-when-each-stage-depends-upon-the]], [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver/2025-07-19-ISzlachtycz-im-pretty-sure-you-cant-do-this-properly-for-the]] diff --git a/archive/threads/NOTimothyLottes/index.md b/archive/threads/NOTimothyLottes/index.md index e4973f8..26fd2c5 100644 --- a/archive/threads/NOTimothyLottes/index.md +++ b/archive/threads/NOTimothyLottes/index.md @@ -57,6 +57,7 @@ tags: - [[archive/threads/NOTimothyLottes/2025-06-01-i-personally-go-free-form-no-data-stack-no]] - [[archive/threads/NOTimothyLottes/2025-07-06-so-lets-root-skg-the-core-problem-is-near-zero]] - [[archive/threads/NOTimothyLottes/2025-07-08-0-physical-video-games-are-dying-mvgs-take-https]] +- [[archive/threads/NOTimothyLottes/2025-07-19-peanut-gallery-vs-parallelizing-the-physics-solver]] - [[archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c]] - [[archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in]] - [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard]]