From da75d92244a377c7538804ad6deab21f8c4e1c3b Mon Sep 17 00:00:00 2001 From: Ed_ Date: Tue, 25 Aug 2026 01:10:30 -0400 Subject: [PATCH] 1782636381720006711, 1651938781610508288, 2001144169536884919, 1990460012385522118 --- .../index.md | 111 ++++++++++++++++++ archive/threads/MyNameIsMJP/index.md | 12 ++ .../index.md | 46 ++++++++ archive/threads/NOTimothyLottes/index.md | 1 + archive/threads/index.md | 2 + ...is-how-much-overhead-of-course-even-not.md | 43 +++++++ .../index.md | 66 +++++++++++ archive/threads/rianflo/index.md | 1 + ...is-is-not-timothy-lottes-then-who-is-it.md | 35 ++++++ ...e-goes-a-bit-beyond-that-judging-by-the.md | 39 ++++++ .../index.md | 42 +++++++ archive/threads/valigo/index.md | 12 ++ 12 files changed, 410 insertions(+) create mode 100644 archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md create mode 100644 archive/threads/MyNameIsMJP/index.md create mode 100644 archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md create mode 100644 archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md create mode 100644 archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md create mode 100644 archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md create mode 100644 archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md create mode 100644 archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md create mode 100644 archive/threads/valigo/index.md diff --git a/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md b/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md new file mode 100644 index 0000000..0c47615 --- /dev/null +++ b/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md @@ -0,0 +1,111 @@ +--- +title: "@BelgianRenderer @KostasAAA @Nicolas_Lopez_ Apparently uniformity analysis is hard." +type: archive +source: twitter +source_url: "https://x.com/MyNameIsMJP/status/1782636381720006711" +author: "Matt Pettineo" +handle: MyNameIsMJP +post_id: "1782636381720006711" +date: 2024-04-23 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - MyNameIsMJP +description: "@BelgianRenderer @KostasAAA @Nicolas_Lopez_ Apparently uniformity analysis is hard." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/MyNameIsMJP/status/1782636381720006711 +- Author: Matt Pettineo (@MyNameIsMJP) +- Posted: 2024-04-23 05:03:27 + +## Thread + +**1/** + +@BelgianRenderer @KostasAAA @Nicolas_Lopez_ Apparently uniformity analysis is hard. ๐Ÿ™ + +**2/** + +@MyNameIsMJP @BelgianRenderer @Nicolas_Lopez_ If uniformity can't be deduced, the compiler could be conservative and assume divergence. If it guessed wrong, the waterfall loop won't be executed and all threads will use the same index. Also, the shader author could help the compiler with a UniformResourceIndex qualifier. + +**3/** + +@KostasAAA @BelgianRenderer @Nicolas_Lopez_ Yeah I tend to agree that assuming non-uniformity by default for descriptor indexing would have been a better path, with some better language support for explicit tagging of uniform variables. Maybe in HLSL 2027. ๐Ÿ™‚ + +**4/** + +@MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ Uniformity is the fast path, it would be horrible to tax the fast path for the sake of things designed to be slow (aka using resource divergence). The right thing to do is place in explicit uniform/nonuniform qualifiers into the languages so it's explicit. + +**5/** + +@NOTimothyLottes @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ We do nuri for almost all our access (we sometimes turn it off because of badly readable Isa on amd). However the performance impact is in the noise, not all hw resolves this in the shader cores. + +**6/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ NV doesn't advertise this: 32-byte sector size (even with 128-byte lines) mixed with per lane IPs (so you can pipeline latency of divergent accesses) is all about shifting the perf cliff of bad behavior enough to win benchmarks, it is still a cliff (look at ALU utilization) ... + +**7/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ AMD never invested in pipelining divergent latency, and their compiler compounds this by serializing a lot of other things that shouldn't be serialized ... + +**8/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ If one is already into the perf cliff, it's easy on AMD to compound perf debt to the point something can never be optimized, and maybe that's ok if time-to-market/ease-of-use/etc is the primary goal ... + +**9/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ There are cases where AMD's compiler is still failing hard on UNIFORM (aka wave coherent) multi-resource access: zero latency hiding -> every resource is a worst case serialization of {fetch descriptor, wait, sample} with zero pipelining ... example below + +![](https://pbs.twimg.com/media/GL7p5vJXUAECnVi?format=png&name=orig) + +**10/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ Or this case where the images get batched, but the descriptors accesses are serialized (below) ... so it's easy sometimes to assume NURI is not that expensive because the compiler already shot itself in the face (which is quite common in high complexity material shading). + +![](https://pbs.twimg.com/media/GL7rS7uWsAEebjc?format=png&name=orig) + +**11/** + +@NOTimothyLottes @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ Most of the time for us the resource access is uniform, so the overhead is just a few waves to test this though. + +**12/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ If the whole shader coherently branches into uniform vs non-uniform material paths, sure that can work if the non-uniform path is almost never used, and the compiler doesn't choak on the register pressure of the non-uniform code path. + +**13/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ At least for the sake of learnings for others, I'll continue down the compiler rabbit hole a little more ... even serialized latency of K$ (constant) HITs (all in the cache) will destroy shader perf (a single hit is like 30 some clocks). This pattern happens on AMD today still. + +![](https://pbs.twimg.com/media/GL7uT1wXoAA7CQj?format=png&name=orig) + +**14/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ And as for 'fixing' bad programmer behavior via the compiler, lets look at atomicAdd() behavior. First the compiler will burn the overhead to elect an active lane even when the compiler statically knows lane zero is active (simple example below). + +![](https://pbs.twimg.com/media/GL7wLb8WgAEicQD?format=png&name=orig) + +**15/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ Try to out smart it like this, + +int k=readOnlySsbo[1]; +if(int(gl_LocalInvocationID.x)==0){atomicAdd(adr, k);} + +It fights back, and makes something even worse. [RED] ... see the multiply by active lane count ... + +![](https://pbs.twimg.com/media/GL7xh8ZWsAArlkO?format=png&name=orig) + +**16/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ And sometimes it gets really squirrly and throws in a full wave reduction (see the DPP ops). When the good dev is just trying to do an already predicated to lane zero atomic ADD ... + +![](https://pbs.twimg.com/media/GL7yB5cXIAACo5E?format=png&name=orig) + +**17/** + +@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ So if any solution depends on trusting a compiler to implicitly do the right thing, I'd be very very concerned, because they don't. Compiler size perf 'fixes' are brittle, break easy, and become massive nightmares for programmers who know what they are doing. diff --git a/archive/threads/MyNameIsMJP/index.md b/archive/threads/MyNameIsMJP/index.md new file mode 100644 index 0000000..6e069a5 --- /dev/null +++ b/archive/threads/MyNameIsMJP/index.md @@ -0,0 +1,12 @@ +--- +title: MyNameIsMJP +type: note +draft: false +description: Archived threads by MyNameIsMJP. +tags: + - archive + - twitter + - MyNameIsMJP +--- + +- [[archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard]] diff --git a/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md b/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md new file mode 100644 index 0000000..6c96152 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md @@ -0,0 +1,46 @@ +--- +title: "https://gpuopen.com/learn/rgp-1-15-enhanced-isa-view/ Nice Disasm View :) - However op latency isn't useful." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/1651938781610508288" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "1651938781610508288" +date: 2023-04-28 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "https://gpuopen.com/learn/rgp-1-15-enhanced-isa-view/ Nice Disasm View :) - However op latency isn't useful." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/1651938781610508288 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2023-04-28 13:17:51 + +## Thread + +**1/** + +https://gpuopen.com/learn/rgp-1-15-enhanced-isa-view/ Nice Disasm View :) - However op latency isn't useful. Need to see multiwave instruction trace across time, colored by instruction type, enhanced with mark if wave is waiting to issue a given functional unit. Only then will great optimization be possible. + +**2/** + +It would also be best to see overlay of board power (because !/W is the end goal), and an overlay of exactly where there are bubbles in DRAM traffic. Because anything memory bound, the goal is to minimize DRAM bubbles. Need to see how they form dynamically over time to fix ... + +**3/** + +For GPU profilers, might see say {92% ALU, 50% TEX, 21% L2}, then wonder, where is 8% I'm missing. And only way to start to understand that, is to be seeing how waves are executing instruction wise against each other. CPU-profiler-like averages per disassembly line won't cut it. + +**4/** + +Parallel machines can only be understood by seeing the parallel execution. I still have examples today of taking a vanila 32-bit shader (already designed to be fast) and getting 30% returns on all micro optimizations. + +**5/** + +Lastly, side with enabling. Remember people can learn too. And there is typically super skilled people seeded at all companies that teach others how to use advanced tools when they are available. diff --git a/archive/threads/NOTimothyLottes/index.md b/archive/threads/NOTimothyLottes/index.md index aaea865..a4dbbc3 100644 --- a/archive/threads/NOTimothyLottes/index.md +++ b/archive/threads/NOTimothyLottes/index.md @@ -14,6 +14,7 @@ tags: - [[archive/threads/NOTimothyLottes/2022-11-08-example-of-bind-everything-once-layout-aliasing]] - [[archive/threads/NOTimothyLottes/2022-11-09-if-only-pc-vendors-with-open-isas-amd-intel-would]] - [[archive/threads/NOTimothyLottes/2022-11-13-my-prefered-method-of-managing-application-data]] +- [[archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa]] - [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an]] - [[archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop-where-the-goal]] - [[archive/threads/NOTimothyLottes/2023-08-03-spc-using-8-deep-swap-all-aliasing-same-bo-image]] diff --git a/archive/threads/index.md b/archive/threads/index.md index 47a39a5..1a1d34a 100644 --- a/archive/threads/index.md +++ b/archive/threads/index.md @@ -16,6 +16,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to - [[archive/threads/AgileJebrim]] - [[archive/threads/FFmpeg]] - [[archive/threads/KostasAAA]] +- [[archive/threads/MyNameIsMJP]] - [[archive/threads/NOTimothyLottes]] - [[archive/threads/SebAaltonen]] - [[archive/threads/VPCOMPRESSB]] @@ -23,4 +24,5 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to - [[archive/threads/kenpex]] - [[archive/threads/mmalex]] - [[archive/threads/rianflo]] +- [[archive/threads/valigo]] - [[archive/threads/winning_tactic]] diff --git a/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md new file mode 100644 index 0000000..b712c64 --- /dev/null +++ b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md @@ -0,0 +1,43 @@ +--- +title: "@NOTimothyLottes question is how much overhead." +type: archive +source: twitter +source_url: "https://x.com/rianflo/status/2001144169536884919" +author: "Florian Hoenig" +handle: rianflo +post_id: "2001144169536884919" +date: 2025-12-17 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - rianflo +description: "@NOTimothyLottes question is how much overhead." +in_reply_to: "" +parent_post_id: "2001106069238563204" +--- + +## Source + +- URL: https://x.com/rianflo/status/2001144169536884919 +- Author: Florian Hoenig (@rianflo) +- Posted: 2025-12-17 04:15:24 + +## Branch + +**1/** + +@NOTimothyLottes question is how much overhead. of course even not knowing how it was implemented, its obviously complex. but iโ€™d take a bit of overhead in favor of writing a โ€œprogramโ€ top down on the gpu. + +**2/** + +@NOTimothyLottes you already know weโ€™re on the same page wrt to rendering stuff differently, but it would be fun to show a proof of concept for rendering trad stuff this way, even just to proof a point. like load and render any gltf. :-) + +**3/** + +@rianflo I just need to get off the R&D train at some point and actually ship something :) + +## Related + +- Spine: [[archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped]] diff --git a/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md new file mode 100644 index 0000000..9253338 --- /dev/null +++ b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md @@ -0,0 +1,66 @@ +--- +title: "Significant amount of bloat dropped :-) ๐ŸŽ‰๐Ÿฅณ๐ŸŽˆ" +type: archive +source: twitter +source_url: "https://x.com/rianflo/status/2001080321802977727" +author: "Florian Hoenig" +handle: rianflo +post_id: "2001080321802977727" +date: 2025-12-17 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - rianflo +description: "Significant amount of bloat dropped :-) ๐ŸŽ‰๐Ÿฅณ๐ŸŽˆ" +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/rianflo/status/2001080321802977727 +- Author: Florian Hoenig (@rianflo) +- Posted: 2025-12-17 00:01:41 + +## Thread + +**1/** + +Significant amount of bloat dropped :-) ๐ŸŽ‰๐Ÿฅณ๐ŸŽˆ + +Iโ€™d move it all to the GPU though. A single kernel that launches your pipeline steps per frame or per whatever. Pretty sure NV can do it. AMD I have no deep knowledge. @NOTimothyLottes ? + +**2/** + +@rianflo From my perspective being compute-only for graphics, few reasons to launch kernels because I'd always use a fixed amount of VGPRs. The larger problem is compilers that cannot keep up with the large program sizes (in compile time or register allocation). + +Branches: [[archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not]] + +**3/** + +@rianflo Huge amount of pitfalls with compute-side dynamic dispatch of work (NV had it back when I worked there BTW), from long latency chains, to overheads tracking work completion, preemption, state restore, etc. It's not the golden answer people think it is. It is a slow path. + +**4/** + +@rianflo There are however a bunch of things we could trivially do GPU side that are currently CPU side, like computing best tiling modes for images, computing image {size, alignment, etc}, building descriptors, etc. Lots of other driver stuff could be done on the GPU for sure. + +**5/** + +@rianflo My plan for 2026 is actually to build my open source AMD SteamOS/Linux driver for a future compute-graphics API, and it will be doing some radical stuff since I'm also doing shader binary code generation too :) Hopefully you all get live examples. + +**6/** + +@NOTimothyLottes @rianflo Can't wait! This compute-graphics API is something like compute + meshlets + fragment shaders only graphics API? + +**7/** + +@bkaradzic @rianflo Compute as in only compute shader dispatches, no fixed function graphics (no fragment/etc). And graphics via pure compute. + +**8/** + +@NOTimothyLottes @bkaradzic @rianflo Considering how much we already software rasterize, we are not so far from it :) + +**9/** + +@Nicolas_Lopez_ @NOTimothyLottes @bkaradzic yeah but then someone insists on a couple of large triangles and wants to access the rasterizer hw again, which is supposedly too small of die area to be even worth ripping it out. diff --git a/archive/threads/rianflo/index.md b/archive/threads/rianflo/index.md index 4127943..b0d21c8 100644 --- a/archive/threads/rianflo/index.md +++ b/archive/threads/rianflo/index.md @@ -10,3 +10,4 @@ tags: --- - [[archive/threads/rianflo/2022-11-29-the-road-to-16-bit-floats-gpu-is-paved-with-our]] +- [[archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped]] diff --git a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md new file mode 100644 index 0000000..c727ac5 --- /dev/null +++ b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md @@ -0,0 +1,35 @@ +--- +title: "@valigo @NOTimothyLottes If this is not Timothy Lottes then who is it?" +type: archive +source: twitter +source_url: "https://x.com/Cheezaight/status/1990482324635725950" +author: "Hank" +handle: Cheezaight +post_id: "1990482324635725950" +date: 2025-11-17 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - valigo +description: "@valigo @NOTimothyLottes If this is not Timothy Lottes then who is it?" +in_reply_to: "" +parent_post_id: "1990462184170926463" +--- + +## Source + +- URL: https://x.com/Cheezaight/status/1990482324635725950 +- Author: Hank (@Cheezaight) +- Posted: 2025-11-17 18:09:02 + +## Branch + +**1/** + +@valigo @NOTimothyLottes If this is not Timothy Lottes then who is it? + +## Related + +- Spine: [[archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually]] diff --git a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md new file mode 100644 index 0000000..20edaf1 --- /dev/null +++ b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md @@ -0,0 +1,39 @@ +--- +title: "@valigo His style goes a bit beyond that, judging by the defines used itโ€™s similar to some form of literate programming but with C preprocessor." +type: archive +source: twitter +source_url: "https://x.com/mrsteyk1/status/1990467157357150599" +author: "mrsteyk" +handle: mrsteyk1 +post_id: "1990467157357150599" +date: 2025-11-17 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - valigo +description: "@valigo His style goes a bit beyond that, judging by the defines used itโ€™s similar to some form of literate programming but with C preprocessor." +in_reply_to: "" +parent_post_id: "1990462184170926463" +--- + +## Source + +- URL: https://x.com/mrsteyk1/status/1990467157357150599 +- Author: mrsteyk (@mrsteyk1) +- Posted: 2025-11-17 17:08:46 + +## Branch + +**1/** + +@valigo His style goes a bit beyond that, judging by the defines used itโ€™s similar to some form of literate programming but with C preprocessor. And the whole RAM thing iirc was for when he was hot reloading C, he said he later switched to GPU and itโ€™s not exactly required anymore? + +**2/** + +@mrsteyk1 @valigo Oh I still use the RAM global struct and pointer even without using CPU side hot reload. + +## Related + +- Spine: [[archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually]] diff --git a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md new file mode 100644 index 0000000..3c736d6 --- /dev/null +++ b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md @@ -0,0 +1,42 @@ +--- +title: "People who say \"C is modern-day assembly\" usually way undershoot it." +type: archive +source: twitter +source_url: "https://x.com/valigo/status/1990460012385522118" +author: "Valentin Ignatev" +handle: valigo +post_id: "1990460012385522118" +date: 2025-11-17 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - valigo +description: "People who say \"C is modern-day assembly\" usually way undershoot it." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/valigo/status/1990460012385522118 +- Author: Valentin Ignatev (@valigo) +- Posted: 2025-11-17 16:40:22 + +## Thread + +**1/** + +People who say "C is modern-day assembly" usually way undershoot it. This guy actually writes C like it's asm: +- No types - uints everywhere until a cast to actual type on access. +- No pointers - only integers, types only on load/store. +Is this how all GPU programmers write C? + +![](https://pbs.twimg.com/media/G5-G1WZXoAIm5WW?format=jpg&name=orig) +![](https://pbs.twimg.com/media/G5-HR8yXoAEae5Z?format=jpg&name=orig) + +**2/** + +This is @NOTimothyLottes btw, with his "Fixing C" talk, it's very cool. I really like mixing up shader code and regular C code in the same file and just ifdefind it out depending on which compiler you runt it through: https://www.youtube.com/watch?v=RrL7121MOeA + +Branches: [[archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the]], [[archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it]] diff --git a/archive/threads/valigo/index.md b/archive/threads/valigo/index.md new file mode 100644 index 0000000..70a298b --- /dev/null +++ b/archive/threads/valigo/index.md @@ -0,0 +1,12 @@ +--- +title: valigo +type: note +draft: false +description: Archived threads by valigo. +tags: + - archive + - twitter + - valigo +--- + +- [[archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually]]