1880476705728655733, 2085365714412556730

2026-08-25 22:06:01 -04:00
1 parent c2f0e52b35
commit 856467d76b
@@ -0,0 +1,61 @@
+---
+title: "@NOTimothyLottes I can’t speak about AI but we do have Genlock to worry about in our multi-GPU setups."
+type: archive
+source: twitter
+source_url: "https://x.com/AgileJebrim/status/1880480958044152264"
+author: "Jebrim"
+handle: AgileJebrim
+post_id: "1880480958044152264"
+date: 2025-01-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes I can’t speak about AI but we do have Genlock to worry about in our multi-GPU setups."
+in_reply_to: ""
+parent_post_id: "1880479856632426572"
+---
+
+## Source
+
+- URL: https://x.com/AgileJebrim/status/1880480958044152264
+- Author: Jebrim (@AgileJebrim)
+- Posted: 2025-01-18 05:02:52
+
+## Branch
+
+**1/** **@AgileJebrim** ^1880480958044152264
+
+**@NOTimothyLottes**
+
+I can’t speak about AI but we do have Genlock to worry about in our multi-GPU setups.
+
+**2/** **@AgileJebrim** ^1880481085093736697
+
+**@NOTimothyLottes**
+
+That syncing can be quite troublesome, even with NVIDIA.
+
+**3/** **@NOTimothyLottes** ^1880482464419967111
+
+**@AgileJebrim**
+
+Related, could never understand how such basic obvious stuff like getting devices phased in time to minimize latency is either impossible or extremely hard to do.
+
+**4/** **@AgileJebrim** ^1880484093181456521
+
+**@NOTimothyLottes**
+
+The APIs are just really error-prone and can stop working easily. Basically success or failure in our whole industry is predicated in part upon being one of the rare ones able to figure out little tricks on how to get it to work reliably. One of our most important trade secrets.
+
+**5/** **@AgileJebrim** ^1880484294742929740
+
+**@NOTimothyLottes**
+
+Most companies fail to get it working right in multi-GPU, multi-node configurations.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz]]
@@ -0,0 +1,73 @@
+---
+title: "@NOTimothyLottes Best guess from what they have said is they want unrestricted access to the command processor/ultra-threaded dispatch processor(micro-engine scheduler) to implement their own scheduling program(targeting specific CUs for example)."
+type: archive
+source: twitter
+source_url: "https://x.com/LeviathanGamer2/status/1880503685534638343"
+author: "LeviathanGamer"
+handle: LeviathanGamer2
+post_id: "1880503685534638343"
+date: 2025-01-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes Best guess from what they have said is they want unrestricted access to the command processor/ultra-threaded dispatch processor(micro-engine scheduler) to implement their own scheduling program(targeting specific CUs for example)."
+in_reply_to: ""
+parent_post_id: "1880479856632426572"
+---
+
+## Source
+
+- URL: https://x.com/LeviathanGamer2/status/1880503685534638343
+- Author: LeviathanGamer (@LeviathanGamer2)
+- Posted: 2025-01-18 06:33:11
+
+## Branch
+
+**1/** **@LeviathanGamer2** ^1880503685534638343
+
+**@NOTimothyLottes**
+
+Best guess from what they have said is they want unrestricted access to the command processor/ultra-threaded dispatch processor(micro-engine scheduler) to implement their own scheduling program(targeting specific CUs for example).
+
+**2/** **@NOTimothyLottes** ^1880606749671190680
+
+**@LeviathanGamer2**
+
+That is the part that is likely workaroundable (for example if programs are CU aware, then they can choose to exit and open up those CUs to another launch)
+
+**3/** **@LeviathanGamer2** ^1880647971743932701
+
+**@NOTimothyLottes**
+
+I am assuming you mean ExecuteIndirect? As far as I am aware, you can't explicitly schedule to a target CU without disabling CUs. You are at the mercy of the driver, which might result in poor latency(mainly for a workload you might want to share across multiple GPUs).
+
+**4/** **@NOTimothyLottes** ^1880679657315733597
+
+**@LeviathanGamer2**
+
+If you have persistent workgroups, that have fully filled the GPU, when you launch work, nothing happens until waves choose to exit, so CU aware waves can choose to exit, and the HW will restrict its launch to the newly open CUs I believe
+
+**5/** **@NOTimothyLottes** ^1880680467122536572
+
+**@LeviathanGamer2**
+
+Also besides adjusting schedule priority and avoiding TDRs, there is little reason to launch at all. Just reuse existing waves with fixed VGPR counts.
+
+**6/** **@NOTimothyLottes** ^1880682699016540277
+
+**@LeviathanGamer2**
+
+From a latency perspective the worst option one has is to "launch work" in response to something. The best option is to already be running on the machine and respond to something you'd polled from a memory partition that is set to bypass cache (which AMD already exposes on PC)
+
+**7/** **@LeviathanGamer2** ^1880693145513722176
+
+**@NOTimothyLottes**
+
+Yeah, I think the use case would be passing work from 1 GPU to another GPU, and you would want to launch immediately and try to have low LDS/Cache conflicts while also having the highest priority, so you would want a specific CU for that. Still, that is spitballing an edge case.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz]]
@@ -0,0 +1,49 @@
+---
+title: "@NOTimothyLottes One thing I know about multi-gpu is that tinygrad (the ai training framework he is building) want to use peer-to-peer gpu communication on consumer hardware (rtx 4090 and rx 7900 xtx), but it is only enabled on enterprise hw, so he made his own driver to support it on consumer hw"
+type: archive
+source: twitter
+source_url: "https://x.com/alifahrri2/status/1880525767303713050"
+author: "Fahri Ali Rahman"
+handle: alifahrri2
+post_id: "1880525767303713050"
+date: 2025-01-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes One thing I know about multi-gpu is that tinygrad (the ai training framework he is building) want to use peer-to-peer gpu communication on consumer hardware (rtx 4090 and rx 7900 xtx), but it is only enabled on enterprise hw, so he made his own driver to support it on consumer hw"
+in_reply_to: ""
+parent_post_id: "1880479856632426572"
+---
+
+## Source
+
+- URL: https://x.com/alifahrri2/status/1880525767303713050
+- Author: Fahri Ali Rahman (@alifahrri2)
+- Posted: 2025-01-18 08:00:56
+
+## Branch
+
+**1/** **@alifahrri2** ^1880525767303713050
+
+**@NOTimothyLottes**
+
+One thing I know about multi-gpu is that tinygrad (the ai training framework he is building) want to use peer-to-peer gpu communication on consumer hardware (rtx 4090 and rx 7900 xtx), but it is only enabled on enterprise hw, so he made his own driver to support it on consumer hw
+
+**2/** **@NOTimothyLottes** ^1880603021291487247
+
+**@alifahrri2**
+
+Consumer PCs certainly are soft-crippled there using the CPU as an intermediate stop on the perf tax train when going device to/from GPU. SteamDeck was page fault limited (soft-cripped) on initial load from SSD for example. These seem like good things to actually fix.
+
+**3/** **@NOTimothyLottes** ^1880604611423441095
+
+**@alifahrri2**
+
+Meaning likely had AMD actually worked with Hotz, the fruits of that would probably be useful outside AI too. So our loss.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz]]
@@ -0,0 +1,37 @@
+---
+title: "@NOTimothyLottes Also George started with RX7900 A0 silicon, so i guess there are hardware hazards, which he did hit when doing custom stuff..."
+type: archive
+source: twitter
+source_url: "https://x.com/pyrek_p/status/1880635958905000013"
+author: "Pyrek Paweł"
+handle: pyrek_p
+post_id: "1880635958905000013"
+date: 2025-01-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes Also George started with RX7900 A0 silicon, so i guess there are hardware hazards, which he did hit when doing custom stuff..."
+in_reply_to: ""
+parent_post_id: "1880479856632426572"
+---
+
+## Source
+
+- URL: https://x.com/pyrek_p/status/1880635958905000013
+- Author: Pyrek Paweł (@pyrek_p)
+- Posted: 2025-01-18 15:18:47
+
+## Branch
+
+**1/** **@pyrek_p** ^1880635958905000013
+
+**@NOTimothyLottes**
+
+Also George started with RX7900 A0 silicon, so i guess there are hardware hazards, which he did hit when doing custom stuff... Always something, but compute, BW / price was/is nice... We will see what's up with RDNA4 and UDNA soon enough...
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz]]
@@ -0,0 +1,62 @@
+---
+title: "Good landmine to step on: AMD vs Hotz."
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/1880476705728655733"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "1880476705728655733"
+date: 2025-01-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "Good landmine to step on: AMD vs Hotz."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/1880476705728655733
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2025-01-18 04:45:58
+
+## Thread
+
+**1/** **@NOTimothyLottes** ^1880476705728655733
+
+Good landmine to step on: AMD vs Hotz.
+Speculation follows ...
+
+Can only guess the line in the sand here is wanting access to write signed firmware. Specifically aspects of the GPU-side driver which manage compute dispatch and synchronization.
+
+![](https://pbs.twimg.com/media/GhjLil-WsAAl5Tp?format=png&name=orig)
+
+**2/** **@NOTimothyLottes** ^1880476956287987779
+
+If so, likely a HW problem is single level security and putting too much functionality that shouldn't need to be secure on the signed side. Perhaps AMD both: (a.) cannot open access, (b.) nor has the willingness to partner to fix/improve the firmware on their end.
+
+**3/** **@NOTimothyLottes** ^1880477351013937579
+
+What I'd like to know is what aspects of the PM4 (command stream) are the actual contention point?
+I bet engineering folks could bang out a solution to whatever problem there is an a short time, but instead business people get involved, words get exchanged, and stupid wins
+
+**4/** **@NOTimothyLottes** ^1880477715700281601
+
+I also suspect one can "fix it" without changing the command processor firmware. Perhaps the way they are trying to go about solving a problem is actually not the right way.
+
+**5/** **@NOTimothyLottes** ^1880478110531145955
+
+Specifically in Linux, you can layout your VA space and allocations using the existing AMD kernel driver interfaces, and with no other applications using the GPU, basically get access to do whatever you want that is describable in existing PM4 packets
+
+**6/** **@NOTimothyLottes** ^1880478802230509835
+
+This means they are not actually limited at all on the compiler side. Compile your own binaries. Setup your memory once on init-time and then do dispatches to keep persistent work running on the GPU without any real driver involvement at all
+
+**7/** **@NOTimothyLottes** ^1880479856632426572
+
+So probably I'm missing something specific with regards to multi-GPU or memory mapping which indeed isn't easily possible in today's kernel driver. Because I'm basically only thinking about gamedev stuff.
+
+Branches: [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz/2025-01-18-AgileJebrim-i-cant-speak-about-ai-but-we-do-have-genlock-to]], [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz/2025-01-18-LeviathanGamer2-best-guess-from-what-they-have-said-is-they-want]], [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz/2025-01-18-alifahrri2-one-thing-i-know-about-multi-gpu-is-that-tinygrad]], [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz/2025-01-18-pyrek_p-also-george-started-with-rx7900-a0-silicon-so-i]]
@@ -0,0 +1,54 @@
+---
+title: "Seems like one of the pain points with Xlinix DSPs that if you want either a 32-bit ADD or a MAD you need to CLB the A B inputs differently due to how the ADD path takes A:B and the MUL takes A,B."
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/2085365714412556730"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "2085365714412556730"
+date: 2026-08-06
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "Seems like one of the pain points with Xlinix DSPs that if you want either a 32-bit ADD or a MAD you need to CLB the A B inputs differently due to how the ADD path takes A:B and the MUL takes A,B."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/2085365714412556730
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2026-08-06 14:01:45
+
+## Thread
+
+**1/** **@NOTimothyLottes** ^2085365714412556730
+
+Seems like one of the pain points with Xlinix DSPs that if you want either a 32-bit ADD or a MAD you need to CLB the A B inputs differently due to how the ADD path takes A:B and the MUL takes A,B.
+
+**2/** **@NOTimothyLottes** ^2085366833033392185
+
+In my case the top 4-bit MSBs of operands already use a 8:1 mux so im out of single pipeline stage CLB. Puts the design back into the slow burn on break rethink mode …
+
+**3/** **@NOTimothyLottes** ^2085369523838787831
+
+The aim was to place a sub-word decode pipeline stage (CLB) between a direct mapped shift register (SLICEM) to DSP inputs for operand fetch. With shift register getting a program controlled MUX as input/clk …
+
+**4/** **@NOTimothyLottes** ^2085370511807136007
+
+… that mux taking things like bits of P, operands conditional to the sign bit of P (for 1 clk compare and swap), BRAM read, etc. But each of the 3 gets separate CE and mux choice. So functions like 32 entry 3 bank registers file.
+
+**5/** **@NOTimothyLottes** ^2085371367000563887
+
+So in register sorting actually works out at 1 clk per compareswap. Because it’s a 3 bank store, and one can bank swap too on the swap.
+
+**6/** **@NOTimothyLottes** ^2085372781026283653
+
+In some ways this is an evolution of forth where the data stack transforms into multi bank and one replaces the stack with an indexable looping queue (without a pop).
+
+**7/** **@NOTimothyLottes** ^2085390994212565000
+
+Note sub-word extract is right justified (fills MSBs) and left side gets zero fill. Far better than the left justified zero/sign extraction, but requires a IMAD fixed shift (fixed point op).
@@ -42,6 +42,7 @@ tags:
 - [[archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs]]
 - [[archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is]]
 - [[archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic]]
+- [[archive/threads/NOTimothyLottes/2025-01-18-good-landmine-to-step-on-amd-vs-hotz]]
 - [[archive/threads/NOTimothyLottes/2025-01-22-simple-napkin-analysis-of-that-high-end-crt]]
 - [[archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling]]
 - [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the]]
@@ -101,6 +102,7 @@ tags:
 - [[archive/threads/NOTimothyLottes/2026-07-22-working-through-rough-draft-of-assembly-for-a]]
 - [[archive/threads/NOTimothyLottes/2026-08-02-m64-the-physical-fpga-psram-hardware-offers-such]]
 - [[archive/threads/NOTimothyLottes/2026-08-02-re-fpga-land-alus-im-firmly-distracted-by-an]]
+- [[archive/threads/NOTimothyLottes/2026-08-06-seems-like-one-of-the-pain-points-with-xlinix]]
 - [[archive/threads/NOTimothyLottes/2026-08-10-been-saying-this-for-a-decade-now-hu-has-a-really]]
 - [[archive/threads/NOTimothyLottes/2026-08-23-operands-time-perf]]
 - [[archive/threads/NOTimothyLottes/2026-08-25-one-downsides-to-being-a-left-justified-machine]]