1873744231719956872, 1870942850684420564, 1738800602568638492

2026-08-26 12:00:21 -04:00
1 parent ba3674cbd7
commit a6e6d7616c
@@ -0,0 +1,93 @@
+---
+title: "@NOTimothyLottes Humor me… have you tried entering in atomicAdd(adr,lane==0?v:0)? How bad is it relative to the rest?"
+type: archive
+source: twitter
+source_url: "https://x.com/AgileJebrim/status/1870948791534203086"
+author: "Jebrim"
+handle: AgileJebrim
+post_id: "1870948791534203086"
+date: 2024-12-22
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes Humor me… have you tried entering in atomicAdd(adr,lane==0?v:0)? How bad is it relative to the rest?"
+in_reply_to: ""
+parent_post_id: "1870942850684420564"
+---
+
+## Source
+
+- URL: https://x.com/AgileJebrim/status/1870948791534203086
+- Author: Jebrim (@AgileJebrim)
+- Posted: 2024-12-22 21:45:27
+
+## Branch
+
+**1/** **@AgileJebrim** ^1870948791534203086
+
+**@NOTimothyLottes**
+
+Humor me… have you tried entering in atomicAdd(adr,lane==0?v:0)? How bad is it relative to the rest?
+
+**2/** **@NOTimothyLottes** ^1870953014481269098
+
+**@AgileJebrim**
+
+You cannot get that behavior because the driver will "fix" it for you. There had been so many bad programmers not predicating atomics that the IHVs had been forced to workaround (too the expense of everyone who had optimized correctly)
+
+**3/** **@AgileJebrim** ^1870953397920129344
+
+**@NOTimothyLottes**
+
+The driver is going to replace my code to what?
+
+**4/** **@AgileJebrim** ^1870954001585607042
+
+**@NOTimothyLottes**
+
+This is why I said humor me. I’m frankly curious to see what performance it’ll get on your test suite. Just try it.
+
+**5/** **@NOTimothyLottes** ^1870958724476461290
+
+**@AgileJebrim**
+
+110% if dividing by the type of the prior worst. So it's a bunch slower than the prior worst case. But I don't have NV's disassembly, so not sure exactly what it did under the hood.
+
+**6/** **@NOTimothyLottes** ^1870961042257236009
+
+**@AgileJebrim**
+
+If we look at AMD disassembly for atomicAdd'ing "gl_LocalInvocationID.x==0?256:0" you will see the AMD driver do a wave-op ADD reduction (highlighted) and I'd suspect the same from NVIDIA. Note the atomic at the end of the shader uses my trick (and sums the runtime).
+
+![](https://pbs.twimg.com/media/Gfb82ROXIAAtJff?format=png&name=orig)
+
+**7/** **@AgileJebrim** ^1870962166796632486
+
+**@NOTimothyLottes**
+
+Even though it knows it’s 0 it’ll still waste time reducing? Lame.
+
+**8/** **@NOTimothyLottes** ^1870963440485101720
+
+**@AgileJebrim**
+
+There have traditionally been a lot of driver workarounds in this area (like using ballot and bitcount if the adder is 1, etc). And I remember as far back as being at NV (so more than a decade ago) and having this same problem of NV drivers breaking perf of pre-optimized shaders.
+
+**9/** **@NOTimothyLottes** ^1870963879255101507
+
+**@AgileJebrim**
+
+I do find it interesting that it took me a decade to figure out a proper good workaround. So yeah, I'm the "idiot" too. But I'm one workaround less of an idiot this week, which is progress.
+
+**10/** **@AgileJebrim** ^1870964580085555600
+
+**@NOTimothyLottes**
+
+It’d be nice if there were a way to configure the optimizer settings like you can do with many compilers.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv]]
@@ -0,0 +1,61 @@
+---
+title: "@NOTimothyLottes I wonder is there explainable perf and algorithmic different between atomicAdd on uint cell vs incrementing a buffer counter (for append/consume buffer)"
+type: archive
+source: twitter
+source_url: "https://x.com/Meetem4/status/1870944398839620087"
+author: "Meetem"
+handle: Meetem4
+post_id: "1870944398839620087"
+date: 2024-12-22
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes I wonder is there explainable perf and algorithmic different between atomicAdd on uint cell vs incrementing a buffer counter (for append/consume buffer)"
+in_reply_to: ""
+parent_post_id: "1870942850684420564"
+---
+
+## Source
+
+- URL: https://x.com/Meetem4/status/1870944398839620087
+- Author: Meetem (@Meetem4)
+- Posted: 2024-12-22 21:27:59
+
+## Branch
+
+**1/** **@Meetem4** ^1870944398839620087
+
+**@NOTimothyLottes**
+
+I wonder is there explainable perf and algorithmic different between atomicAdd on uint cell vs incrementing a buffer counter (for append/consume buffer)
+
+**2/** **@NOTimothyLottes** ^1870946922233749918
+
+**@Meetem4**
+
+So I don't use the "fixed function" atomic counters (which are going to be emulated likely with global atomics), nor do I use the "fixed function" append or consume of graphics. However ...
+
+**3/** **@NOTimothyLottes** ^1870947271568973944
+
+**@Meetem4**
+
+Some platforms probably optimized append and consume by parallelizing the global atomics to multiple L2 partitions (had parallel counters). Which of course one can do in software too.
+
+**4/** **@NOTimothyLottes** ^1870947546987647064
+
+**@Meetem4**
+
+And at least AMD traditionally had GDS which could be used, but that is the great serializer, so not sure if that is wise for huge GPU appending (multiple append queues is probably better, in theory)
+
+**5/** **@Meetem4** ^1870947985351483769
+
+**@NOTimothyLottes**
+
+Well, yeah, I was expecting some form of optimization here, because the counter is only valid for the current thread, according to D3D specification, which raises the suspicion that some higher level optimization can be applied
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv]]
@@ -0,0 +1,94 @@
+---
+title: "@NOTimothyLottes I'm not going to pretend I understand a lick of this, which is why I have a humble request, well 2 actually:"
+type: archive
+source: twitter
+source_url: "https://x.com/RouaniJihad/status/1870960478572499239"
+author: "🕹️G🅰MESTUFFS🎮"
+handle: RouaniJihad
+post_id: "1870960478572499239"
+date: 2024-12-22
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes I'm not going to pretend I understand a lick of this, which is why I have a humble request, well 2 actually:"
+in_reply_to: ""
+parent_post_id: "1870942850684420564"
+---
+
+## Source
+
+- URL: https://x.com/RouaniJihad/status/1870960478572499239
+- Author: 🕹️G🅰MESTUFFS🎮 (@RouaniJihad)
+- Posted: 2024-12-22 22:31:53
+
+## Branch
+
+**1/** **@RouaniJihad** ^1870960478572499239
+
+**@NOTimothyLottes**
+
+I'm not going to pretend I understand a lick of this, which is why I have a humble request, well 2 actually:
+1- Is there a way for you to finish working on STP.
+2- Can you create an open source denoiser for say, a real-time Path Tracer 👉👈
+Reading this is enough as well... =]
+
+**2/** **@NOTimothyLottes** ^1871178158155714646
+
+**@RouaniJihad**
+
+My recommendation: ask Unity to open source STP under a MIT license so any external person could finish it. And then both Unity and anyone else could benefit from it's long term evolution.
+
+**3/** **@NOTimothyLottes** ^1871178888543687059
+
+**@RouaniJihad**
+
+One fundamental problem with bespoke high-tech solutions like these are that in many cases they become abandonware when all the original people involved in the projects no longer work at the company (which is the case here)
+
+**4/** **@NOTimothyLottes** ^1871180562016387273
+
+**@RouaniJihad**
+
+There are very few people who could work on it, and after Unity shed it's high tech rendering staff during it's downsizing efforts to stay live during it's stock crash, who knows when they will have an environment that fosters that kind of R&D again
+
+**5/** **@NOTimothyLottes** ^1871182399876559216
+
+**@RouaniJihad**
+
+As for STP it wasn't ever designed to denoise per say, it does get a little denoising as a side effect of temporal filtering though, but things like stochastic GI on disocclusions will show a mismatch in noise with other parts of the image that get good temporal feedback
+
+**6/** **@NOTimothyLottes** ^1871183683459145777
+
+**@RouaniJihad**
+
+The cases where people have merged scaling TAAs and denoisers, they do so by augmenting the TAA with extra side channel information from the G-buffer {normals, albedo, etc} and then keep a lot more recurrent data in feedback across frames, this massively increases costs
+
+**7/** **@NOTimothyLottes** ^1871184146795491786
+
+**@RouaniJihad**
+
+Traditionally those who have managed to improve temporal feedback in cases of {rendered mirror reflections, SSR, or even RT} have needed to generate a section reprojection vector of where the mirrored reflection was in the prior frame, this is something Unity doesn't have today
+
+**8/** **@NOTimothyLottes** ^1871184992803672572
+
+**@RouaniJihad**
+
+There is another interesting option that a scaling-TAA typically tracks the amount of screen convergence, and one could pass that information back into an input denoiser before the TAA that denoises less where things have converged and a lot where things would be disoccluded
+
+**9/** **@NOTimothyLottes** ^1871190322346377591
+
+**@RouaniJihad**
+
+Can watch videos like this https://www.youtube.com/watch?v=K3ZHzJ_bhaI ... and you start to see that no one has actually come to a great solution for screen-space denoise+scaling+TAA, even given the ML solutions ...
+
+**10/** **@NOTimothyLottes** ^1871191321974817274
+
+**@RouaniJihad**
+
+Suggests maybe it would ultimately be better to push the RT usage back into the environment probe space and do the spatial temporal denoise there, and then use those probes to light the scene instead.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv]]
@@ -0,0 +1,58 @@
+---
+title: "__/ Fixing AtomicAdd - Benchmarking AMD+NV \\__"
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/1870942850684420564"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "1870942850684420564"
+date: 2024-12-22
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "__/ Fixing AtomicAdd - Benchmarking AMD+NV \\__"
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/1870942850684420564
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2024-12-22 21:21:50
+
+## Thread
+
+**1/** **@NOTimothyLottes** ^1870942850684420564
+
+__/ Fixing AtomicAdd - Benchmarking AMD+NV \__
+RTX 3060
+100% - if(lane==0) atomicAdd(adr,v*lanes) ... smart
+84% - atomicAdd(adr,v) ... stupid
+82% - atomicAdd(lane==0?adr:-4,v*lanes) ... mine
+
+NV's compiler has same "bug" as AMD :)
+My workaround is faster than their compiler too!
+
+Branches: [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv/2024-12-22-Meetem4-i-wonder-is-there-explainable-perf-and]], [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv/2024-12-22-AgileJebrim-humor-me-have-you-tried-entering-in-atomicadd-adr]], [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv/2024-12-22-RouaniJihad-im-not-going-to-pretend-i-understand-a-lick-of]]
+
+**2/** **@NOTimothyLottes** ^1870943585388110229
+
+Review/
+So NV and AMD share the same "optimization" that works as an "anti-optimization" if you predicate the atomic to one lane. Neither checks if the dev actually knows what they are doing and had already predicated to just one lane ...
+
+**3/** **@NOTimothyLottes** ^1870944106463031312
+
+The best workaround however is to rely on BUFFER bounds checking: instead of predicating to one lane, conditionally set the lanes to disable to out-of-bounds addresses instead!
+
+Because then the compiler silly behavior is disabled. And that actually is faster too!
+
+**4/** **@NOTimothyLottes** ^1870944638183538927
+
+My easy access AMD machine is an APU right now, and the numbers were not rock stable like the NV dGPU. So I didn't get exact % (as my test wasn't written with long enough runtimes). But the AMD behavior looks similar.
+
+**5/** **@NOTimothyLottes** ^1870945104586035589
+
+If anyone is wondering how I tested: I wrapped the code with clockRealtimeEXT() and then summed the total runtimes across all waves. I find that is often better than trying to invoke some external profiler. I also have live shader editing so I can watch the behavior live too :)
@@ -54,6 +54,7 @@ tags:
 - [[archive/threads/NOTimothyLottes/2024-12-20-raytastic-friday]]
 - [[archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im]]
 - [[archive/threads/NOTimothyLottes/2024-12-21-how-to-unbreak-atomicadd-on-amd-pc]]
+- [[archive/threads/NOTimothyLottes/2024-12-22-fixing-atomicadd-benchmarking-amd-nv]]
 - [[archive/threads/NOTimothyLottes/2024-12-24-been-playing-with-the-spatial-energy]]
 - [[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]]
@@ -0,0 +1,49 @@
+---
+title: "@SheriefFYI 2x faster today perhaps."
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/1738916459655336202"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "1738916459655336202"
+date: 2023-12-24
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - SheriefFYI
+description: "@SheriefFYI 2x faster today perhaps."
+in_reply_to: ""
+parent_post_id: "1738800602568638492"
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/1738916459655336202
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2023-12-24 13:36:06
+
+## Branch
+
+**1/** **@NOTimothyLottes** ^1738916459655336202
+
+**@SheriefFYI**
+
+2x faster today perhaps. Prior on AMD I had RGP captures of game with 3 separate DMAs. See 0.1ms of GFX idle for a semaphore signal, and 0.1 ms idle for semaphore wait (already signaled) -> 3=0.6 ms GFX idle time/frame. At 120Hz that's >7% of the frame lost, not acceptable IMO.
+
+**2/** **@NOTimothyLottes** ^1738917893348159912
+
+**@SheriefFYI**
+
+... That was just for the transfers, the capture had a lot of dependent async-compute too, but at 200us idle/instance, all that had to be converted to non-async. Cutting waits from 100us to 50us {per signal or wait} wouldn't change the conclusion.
+
+**3/** **@NOTimothyLottes** ^1738919198192017531
+
+**@SheriefFYI**
+
+If drivers had on-GPU syncs, then async would be useful for things like CS index culling into a ring-buffer feeding GFX. But you need fully pipelined syncs for that. Even if they got 50us to 1us, it's still perf death simply due to the idle during drain and fill.
+
+## Related
+
+- Spine: [[archive/threads/SheriefFYI/2023-12-24-im-going-to-retract-my-support-for-this-i-just]]
@@ -0,0 +1,37 @@
+---
+title: "@SheriefFYI Sorry I didn't have time to do this during the week, but it seems to be matching my experience a bit more !"
+type: archive
+source: twitter
+source_url: "https://x.com/lectem/status/1738841583707951402"
+author: "Clément Grégoire"
+handle: lectem
+post_id: "1738841583707951402"
+date: 2023-12-24
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - SheriefFYI
+description: "@SheriefFYI Sorry I didn't have time to do this during the week, but it seems to be matching my experience a bit more !"
+in_reply_to: ""
+parent_post_id: "1738800602568638492"
+---
+
+## Source
+
+- URL: https://x.com/lectem/status/1738841583707951402
+- Author: Clément Grégoire (@lectem)
+- Posted: 2023-12-24 08:38:34
+
+## Branch
+
+**1/** **@lectem** ^1738841583707951402
+
+**@SheriefFYI**
+
+Sorry I didn't have time to do this during the week, but it seems to be matching my experience a bit more !
+
+## Related
+
+- Spine: [[archive/threads/SheriefFYI/2023-12-24-im-going-to-retract-my-support-for-this-i-just]]
@@ -0,0 +1,42 @@
+---
+title: "I'm going to retract my support for this - I just profiled a scenario where I generate geometry on the CPU every frame, upload it via a copy queue, then have the gfx queue do clears + some work before waiting for same-frame copy."
+type: archive
+source: twitter
+source_url: "https://x.com/SheriefFYI/status/1738800602568638492"
+author: "Sherief, FYI"
+handle: SheriefFYI
+post_id: "1738800602568638492"
+date: 2023-12-24
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - SheriefFYI
+description: "I'm going to retract my support for this - I just profiled a scenario where I generate geometry on the CPU every frame, upload it via a copy queue, then have the gfx queue do clears + some work before waiting for same-frame copy."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/SheriefFYI/status/1738800602568638492
+- Author: Sherief, FYI (@SheriefFYI)
+- Posted: 2023-12-24 05:55:43
+
+## Thread
+
+**1/** **@SheriefFYI** ^1738800602568638492
+
+I'm going to retract my support for this - I just profiled a scenario where I generate geometry on the CPU every frame, upload it via a copy queue, then have the gfx queue do clears + some work before waiting for same-frame copy. Delay is ~50us from signal to gfx queue resuming.
+
+Branches: [[archive/threads/SheriefFYI/2023-12-24-im-going-to-retract-my-support-for-this-i-just/2023-12-24-lectem-sorry-i-didnt-have-time-to-do-this-during-the]], [[archive/threads/SheriefFYI/2023-12-24-im-going-to-retract-my-support-for-this-i-just/2023-12-24-NOTimothyLottes-2x-faster-today-perhaps-prior-on-amd-i-had-rgp]]
+
+**2/** **@SheriefFYI** ^1738801049228411350
+
+I profiled this in multiple cases - vsync on and frame taking < 16ms the wait is longer but that's because other parts of the system clock down, so you still hit your vsync window. At no point was this cross-queue wait a significant cause of delay / missing frame time.
+
+**3/** **@SheriefFYI** ^1738801643108413737
+
+Sample data:
+
+![](https://pbs.twimg.com/media/GCF2xqxXQAAAYb3?format=png&name=orig)
@@ -10,3 +10,4 @@ tags:
 ---

 - [[archive/threads/SheriefFYI/2023-12-19-always-always-always-use-an-async-copy-queue]]
+- [[archive/threads/SheriefFYI/2023-12-24-im-going-to-retract-my-support-for-this-i-just]]
@@ -0,0 +1,37 @@
+---
+title: "I just do combinations of separate SPSC ring buffers with a known amount of input and output threads."
+type: archive
+source: twitter
+source_url: "https://x.com/AgileJebrim/status/1873824152013959209"
+author: "Jebrim"
+handle: AgileJebrim
+post_id: "1873824152013959209"
+date: 2024-12-30
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - bmcnett
+description: "I just do combinations of separate SPSC ring buffers with a known amount of input and output threads."
+in_reply_to: ""
+parent_post_id: "1873744231719956872"
+---
+
+## Source
+
+- URL: https://x.com/AgileJebrim/status/1873824152013959209
+- Author: Jebrim (@AgileJebrim)
+- Posted: 2024-12-30 20:11:06
+
+## Branch
+
+**1/** **@AgileJebrim** ^1873824152013959209
+
+I just do combinations of separate SPSC ring buffers with a known amount of input and output threads. The ratio of producers to consumers dictates how many of each ring buffer each thread gets assigned to it. They just iterate through each per pass.
+
+Way more predictable execution times when done like this. No spin loops of unknown duration.
+
+## Related
+
+- Spine: [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring]]
@@ -0,0 +1,63 @@
+---
+title: "@bmcnett There is another way, one can group items and just do counting per group, release the whole group only when all items in group are ready"
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/1873749894437187586"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "1873749894437187586"
+date: 2024-12-30
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - bmcnett
+description: "@bmcnett There is another way, one can group items and just do counting per group, release the whole group only when all items in group are ready"
+in_reply_to: ""
+parent_post_id: "1873744231719956872"
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/1873749894437187586
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2024-12-30 15:16:02
+
+## Branch
+
+**1/** **@NOTimothyLottes** ^1873749894437187586
+
+**@bmcnett**
+
+There is another way, one can group items and just do counting per group, release the whole group only when all items in group are ready
+
+**2/** **@bmcnett** ^1873752260020404449
+
+**@NOTimothyLottes**
+
+that's trivial for a multi producer single consumer, how do you do it simply for a multi consumer?
+
+**3/** **@NOTimothyLottes** ^1873823299819758004
+
+**@bmcnett**
+
+Here is an idea how to do it via minimal atomics. 2M max items per frame. Tune group size to machine, and have the producers start ahead enough, and the (lock-free) spins likely won't happen in practice ... (if on GPU then optimize the atomicAdd()'s, etc)
+
+![](https://pbs.twimg.com/media/GgEn-GCWwAAZm7I?format=png&name=orig)
+
+**4/** **@bmcnett** ^1873830067270541695
+
+**@NOTimothyLottes**
+
+ah, ok i get it now. i don't spin inside API, so user can decide when they want to be wait-free
+
+**5/** **@NOTimothyLottes** ^1873831867499381145
+
+**@bmcnett**
+
+Yeah, exactly that, there are many optimizations possible. Like producers can amortize to one atomic per group to advance ready. Producers could queue the group locally if it isn't active and keep going. Etc.
+
+## Related
+
+- Spine: [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring]]
@@ -0,0 +1,39 @@
+---
+title: "@bmcnett Qubits:"
+type: archive
+source: twitter
+source_url: "https://x.com/mbur82/status/1873745174435860798"
+author: "MB82"
+handle: mbur82
+post_id: "1873745174435860798"
+date: 2024-12-30
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - bmcnett
+description: "@bmcnett Qubits:"
+in_reply_to: ""
+parent_post_id: "1873744231719956872"
+---
+
+## Source
+
+- URL: https://x.com/mbur82/status/1873745174435860798
+- Author: MB82 (@mbur82)
+- Posted: 2024-12-30 14:57:16
+
+## Branch
+
+**1/** **@mbur82** ^1873745174435860798
+
+**@bmcnett**
+
+Qubits:
+
+<video controls src="https://video.twimg.com/tweet_video/GgDhTaJWYAA9UqB.mp4"></video>
+
+## Related
+
+- Spine: [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring]]
@@ -0,0 +1,32 @@
+---
+title: "The simplest multi-producer-multi-consumer ring buffer data structure would seem to need one \"trit\" (ternary bit) of state per buffer entry, for the states \"awaiting write\", \"awaiting read\", \"busy\""
+type: archive
+source: twitter
+source_url: "https://x.com/bmcnett/status/1873744231719956872"
+author: "bmcnett"
+handle: bmcnett
+post_id: "1873744231719956872"
+date: 2024-12-30
+archived: 2026-08-26
+draft: false
+tags:
+  - archive
+  - twitter
+  - bmcnett
+description: "The simplest multi-producer-multi-consumer ring buffer data structure would seem to need one \"trit\" (ternary bit) of state per buffer entry, for the states \"awaiting write\", \"awaiting read\", \"busy\""
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/bmcnett/status/1873744231719956872
+- Author: bmcnett (@bmcnett)
+- Posted: 2024-12-30 14:53:31
+
+## Thread
+
+**1/** **@bmcnett** ^1873744231719956872
+
+The simplest multi-producer-multi-consumer ring buffer data structure would seem to need one "trit" (ternary bit) of state per buffer entry, for the states "awaiting write", "awaiting read", "busy"
+
+Branches: [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring/2024-12-30-mbur82-qubits]], [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring/2024-12-30-NOTimothyLottes-there-is-another-way-one-can-group-items-and-just]], [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring/2024-12-30-AgileJebrim-i-just-do-combinations-of-separate-spsc-ring]]
@@ -0,0 +1,12 @@
+---
+title: bmcnett
+type: note
+draft: false
+description: Archived threads by bmcnett.
+tags:
+  - archive
+  - twitter
+  - bmcnett
+---
+
+- [[archive/threads/bmcnett/2024-12-30-the-simplest-multi-producer-multi-consumer-ring]]
@@ -29,6 +29,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
 - [[archive/threads/Triang3l]]
 - [[archive/threads/VPCOMPRESSB]]
 - [[archive/threads/VictorTaelin]]
+- [[archive/threads/bmcnett]]
 - [[archive/threads/cmuratori]]
 - [[archive/threads/hsn8086]]
 - [[archive/threads/kechogarcia]]