render mentions on a separate line from the reply content.

2026-08-25 15:03:12 -04:00
1 parent f8380db665
commit 880640d935
@@ -28,107 +28,157 @@ parent_post_id: "1869436199884222515"

 **1/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari (3.) If you had multiple line stores collecting on a given line with ECC, you'd have the same bottleneck as fire-and-forget atomics. A throughput of one line modification per clock.
+@AgileJebrim @SebAaltonen @munohikari
+
+(3.) If you had multiple line stores collecting on a given line with ECC, you'd have the same bottleneck as fire-and-forget atomics. A throughput of one line modification per clock.

 **2/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari (4.) Note the prior assumes a read hit! 
+@AgileJebrim @SebAaltonen @munohikari
+
+(4.) Note the prior assumes a read hit! 

 So at the point you get anti-atomic, you are also anti-store and anti-ECC, and anti-etc. It's the same pipelines with the same variability due to on-chip networking, different clock domain crossing, etc.

 **3/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari (5.) Good GPUs have multiple ALUs doing the atomic by the last level cache. So it scales very well as a function of line collisions. Meaning if all lanes access separate addresses on a cacheline, those go in parallel.
+@AgileJebrim @SebAaltonen @munohikari
+
+(5.) Good GPUs have multiple ALUs doing the atomic by the last level cache. So it scales very well as a function of line collisions. Meaning if all lanes access separate addresses on a cacheline, those go in parallel.

 **4/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari (6.) Atomics and regular stores have the same memory controller base-camping behavior. If all SIMDs store to addresses that hash to the same last level cache partition, they will drop efficiency just like doing all atomics to the same address.
+@AgileJebrim @SebAaltonen @munohikari
+
+(6.) Atomics and regular stores have the same memory controller base-camping behavior. If all SIMDs store to addresses that hash to the same last level cache partition, they will drop efficiency just like doing all atomics to the same address.

 **5/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari (7.) Anyway, while CPU atomics are serious design fail, GPU atomics on good GPUs are your best friend. They are actually a fantastic tool for getting more regular performance in many parallel algorithms.
+@AgileJebrim @SebAaltonen @munohikari
+
+(7.) Anyway, while CPU atomics are serious design fail, GPU atomics on good GPUs are your best friend. They are actually a fantastic tool for getting more regular performance in many parallel algorithms.

 **6/** @SebAaltonen

-@NOTimothyLottes @AgileJebrim @munohikari Indeed. Many CPU programmers have the wrong belief that GPU atomics are slow and unusable. They are fantastic. Bump allocator is your best friend on CPU side. On GPU you do atomic add to implement a bump allocator. As simple as that. It's super fast.
+@NOTimothyLottes @AgileJebrim @munohikari
+
+Indeed. Many CPU programmers have the wrong belief that GPU atomics are slow and unusable. They are fantastic. Bump allocator is your best friend on CPU side. On GPU you do atomic add to implement a bump allocator. As simple as that. It's super fast.

 **7/** @AgileJebrim

-@SebAaltonen @NOTimothyLottes @munohikari I know NVIDIA did a really good atomicAdd, especially if you don’t use the result of the atomicAdd(). If you use it, then it forces it down a significantly slower path. But it’s all implementation-specific and different vendors will do different things yes?
+@SebAaltonen @NOTimothyLottes @munohikari
+
+I know NVIDIA did a really good atomicAdd, especially if you don’t use the result of the atomicAdd(). If you use it, then it forces it down a significantly slower path. But it’s all implementation-specific and different vendors will do different things yes?

 **8/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari Atomics come in two forms
+@AgileJebrim @SebAaltonen @munohikari
+
+Atomics come in two forms
 (1.) fire-and-forget (aka you don't use the return) - the compiler will flag it for no-return, so it behaves like a store
 (2.) read the return - it behaves like a {store, and read} simultaneously with layout "coherent"

 **9/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari Good GPUs have address coalescing on writes and atomics. So a wave wide store is reduced to a cost that scales with the number of total cachelines all waves touch, with byte-write-mask so there is no read-modify-write
+@AgileJebrim @SebAaltonen @munohikari
+
+Good GPUs have address coalescing on writes and atomics. So a wave wide store is reduced to a cost that scales with the number of total cachelines all waves touch, with byte-write-mask so there is no read-modify-write

 **10/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari ... atomics have the same but if any wave lane's addresses collide it will bump those to another request (for the same cacheline). Possible that some HW implements a HW reduction for collisions of some kinds of atomics locally before the requests go out, but don't assume that
+@AgileJebrim @SebAaltonen @munohikari
+
+... atomics have the same but if any wave lane's addresses collide it will bump those to another request (for the same cacheline). Possible that some HW implements a HW reduction for collisions of some kinds of atomics locally before the requests go out, but don't assume that

 **11/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari ... it's more likely that some compilers try to fix stupid behavior by doing a wave-reduction in software, and that causes hell for those of us who already write good code
+@AgileJebrim @SebAaltonen @munohikari
+
+... it's more likely that some compilers try to fix stupid behavior by doing a wave-reduction in software, and that causes hell for those of us who already write good code

 **12/** @AgileJebrim

-@NOTimothyLottes @SebAaltonen @munohikari Thoughts on atomic compare exchange? I use similar functionality on CPUs to globally synchronize threads and I figured I’d give it a shot attempting to do that on GPUs.
+@NOTimothyLottes @SebAaltonen @munohikari
+
+Thoughts on atomic compare exchange? I use similar functionality on CPUs to globally synchronize threads and I figured I’d give it a shot attempting to do that on GPUs.

 **13/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari Compare and exchange since it takes 2 values, it could have half the peak rate through on-chip network. Personally I have always used algorithms that do better things without the cmpswap atomic. You always can get the return (value pre-atomic), so cmpswap utility is less
+@AgileJebrim @SebAaltonen @munohikari
+
+Compare and exchange since it takes 2 values, it could have half the peak rate through on-chip network. Personally I have always used algorithms that do better things without the cmpswap atomic. You always can get the return (value pre-atomic), so cmpswap utility is less

 **14/** @AgileJebrim

-@NOTimothyLottes @SebAaltonen My CPU sync mechanism works by stalling each thread until it reaches a multiple of the total number of threads to be synced, only incrementing an integer (swapping) when it reaches its specific thread index.
+@NOTimothyLottes @SebAaltonen
+
+My CPU sync mechanism works by stalling each thread until it reaches a multiple of the total number of threads to be synced, only incrementing an integer (swapping) when it reaches its specific thread index.

 **15/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen I assume you are using a futex then on Linux to block? But the GPU doesn't have such a thing exposed in software. Instead you'd be effectively polling using serial global memory atomic latency as your rate limiter and 'blocking'
+@AgileJebrim @SebAaltonen
+
+I assume you are using a futex then on Linux to block? But the GPU doesn't have such a thing exposed in software. Instead you'd be effectively polling using serial global memory atomic latency as your rate limiter and 'blocking'

 **16/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen Serializing workgroups on the GPU in this way has a very high latency granularity. There is also the issue of preemption on PCs, there is no guarantee of forward progress due to no guarantee all workgroups get restored
+@AgileJebrim @SebAaltonen
+
+Serializing workgroups on the GPU in this way has a very high latency granularity. There is also the issue of preemption on PCs, there is no guarantee of forward progress due to no guarantee all workgroups get restored

 **17/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen So you can deadlock post preemption if the workgroup that needs to do the atomic to unblock those spinning cannot get back on the machine
+@AgileJebrim @SebAaltonen
+
+So you can deadlock post preemption if the workgroup that needs to do the atomic to unblock those spinning cannot get back on the machine

 **18/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen Now, the important part, there is one compromise rule that has the highest chance of being possible, that is an ask that if there is a partial restore, that it restores the oldest launched workgroups first ...
+@AgileJebrim @SebAaltonen
+
+Now, the important part, there is one compromise rule that has the highest chance of being possible, that is an ask that if there is a partial restore, that it restores the oldest launched workgroups first ...

 **19/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen And with that you can have some forward progress if an algorithm only has dependencies on workgroups launched before it (like lower kernel global workgroup index), food for thought for algorithm design
+@AgileJebrim @SebAaltonen
+
+And with that you can have some forward progress if an algorithm only has dependencies on workgroups launched before it (like lower kernel global workgroup index), food for thought for algorithm design

 **20/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen on the CPU side, you'd futex block to get the thread off being scheduled so the dependent one could get on the machine to avoid deadlock, it isn't efficient by any means but works, the GPU's exposed only voluntary method to get off the machine is to exit the workgroup ...
+@AgileJebrim @SebAaltonen
+
+on the CPU side, you'd futex block to get the thread off being scheduled so the dependent one could get on the machine to avoid deadlock, it isn't efficient by any means but works, the GPU's exposed only voluntary method to get off the machine is to exit the workgroup ...

 **21/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen So if you uber-task, meaning just keep launching the same dispatch, and the workgroup finds what it needs to do (instead of working off kernel global index), then you can workaround preemption that way too ...
+@AgileJebrim @SebAaltonen
+
+So if you uber-task, meaning just keep launching the same dispatch, and the workgroup finds what it needs to do (instead of working off kernel global index), then you can workaround preemption that way too ...

 **22/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen Blocking becomes just workgroup exit. And the next workgroup gets lower schedule priority than existing active workgroups which helps solve of the scheduling issues
+@AgileJebrim @SebAaltonen
+
+Blocking becomes just workgroup exit. And the next workgroup gets lower schedule priority than existing active workgroups which helps solve of the scheduling issues

 **23/** @AgileJebrim

-@NOTimothyLottes @SebAaltonen I’m not using a Linux futex. Could you look over my code here?
+@NOTimothyLottes @SebAaltonen
+
+I’m not using a Linux futex. Could you look over my code here?

 **24/** @simplex_fx

-@AgileJebrim @NOTimothyLottes @SebAaltonen Hey Jeb, have you considered hitting the funny L shaped button on the right of your keyboard more frequently? 😅
+@AgileJebrim @NOTimothyLottes @SebAaltonen
+
+Hey Jeb, have you considered hitting the funny L shaped button on the right of your keyboard more frequently? 😅

 **25/** @AgileJebrim

-@simplex_fx @NOTimothyLottes @SebAaltonen Enter? Nah
+@simplex_fx @NOTimothyLottes @SebAaltonen
+
+Enter? Nah

 **26/** @simplex_fx

@@ -138,89 +188,131 @@ So at the point you get anti-atomic, you are also anti-store and anti-ECC, and a

 **27/** @AgileJebrim

-@simplex_fx @NOTimothyLottes @SebAaltonen If I don’t have to scroll right…
+@simplex_fx @NOTimothyLottes @SebAaltonen
+
+If I don’t have to scroll right…

 **28/** @simplex_fx

-@AgileJebrim @NOTimothyLottes @SebAaltonen Dude, stop with that WQHD bullshit, buy a proper tv and limit yourself to 80-120
+@AgileJebrim @NOTimothyLottes @SebAaltonen
+
+Dude, stop with that WQHD bullshit, buy a proper tv and limit yourself to 80-120

 **29/** @AgileJebrim

-@simplex_fx @NOTimothyLottes @SebAaltonen Nty. The hell do I need a tv for? I have several monitors.
+@simplex_fx @NOTimothyLottes @SebAaltonen
+
+Nty. The hell do I need a tv for? I have several monitors.

 **30/** @simplex_fx

-@AgileJebrim @NOTimothyLottes @SebAaltonen How big?
+@AgileJebrim @NOTimothyLottes @SebAaltonen
+
+How big?

 **31/** @AgileJebrim

-@simplex_fx @NOTimothyLottes @SebAaltonen Big enough to maximize a window on each.
+@simplex_fx @NOTimothyLottes @SebAaltonen
+
+Big enough to maximize a window on each.

 **32/** @simplex_fx

-@AgileJebrim @NOTimothyLottes @SebAaltonen If you go too wide, you will just kill your neck on the long run
+@AgileJebrim @NOTimothyLottes @SebAaltonen
+
+If you go too wide, you will just kill your neck on the long run

 **33/** @AgileJebrim

-@simplex_fx @NOTimothyLottes @SebAaltonen I have 4 monitors
+@simplex_fx @NOTimothyLottes @SebAaltonen
+
+I have 4 monitors

 **34/** @simplex_fx

-@AgileJebrim @NOTimothyLottes @SebAaltonen How big?
+@AgileJebrim @NOTimothyLottes @SebAaltonen
+
+How big?

 **35/** @NOTimothyLottes

-@simplex_fx @AgileJebrim @SebAaltonen Ideally one of these
+@simplex_fx @AgileJebrim @SebAaltonen
+
+Ideally one of these

 ![](https://pbs.twimg.com/media/GfHntpaWYAAGnOk?format=png&name=orig)

 **36/** @AgileJebrim

-@NOTimothyLottes @simplex_fx @SebAaltonen Not big enough. Evans & Sutherland still makes planetariums. We have smaller scale 360 degree domes. I think they’re about 14ft high.
+@NOTimothyLottes @simplex_fx @SebAaltonen
+
+Not big enough. Evans & Sutherland still makes planetariums. We have smaller scale 360 degree domes. I think they’re about 14ft high.

 **37/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes Same is true for everything. All memory loads on GPUs are highly vendor specific. On GTX 1080 (Pascal) your memory load goes through sampler, which is around 85 cycles of latency. While on Turing your raw load is only 28 cycles of latency (CUDA benchmarks).
+@AgileJebrim @NOTimothyLottes
+
+Same is true for everything. All memory loads on GPUs are highly vendor specific. On GTX 1080 (Pascal) your memory load goes through sampler, which is around 85 cycles of latency. While on Turing your raw load is only 28 cycles of latency (CUDA benchmarks).

 **38/** @AgileJebrim

-@SebAaltonen @NOTimothyLottes For sure, but my focus is more on how deterministic and predictable these are. I’ll take 85 if it’s always 85 over something that might vary unpredictably between 28 and 100.
+@SebAaltonen @NOTimothyLottes
+
+For sure, but my focus is more on how deterministic and predictable these are. I’ll take 85 if it’s always 85 over something that might vary unpredictably between 28 and 100.

 **39/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes Nvidia has big L1$, so they are more predictable. Texture samplers are shared with all waves running on the same compute unit. They are not really predictable. You wait until the unit is ready. There's quite a lot of fluctuation. That's why you have 8x-10x hyperthreading per CU.
+@AgileJebrim @NOTimothyLottes
+
+Nvidia has big L1$, so they are more predictable. Texture samplers are shared with all waves running on the same compute unit. They are not really predictable. You wait until the unit is ready. There's quite a lot of fluctuation. That's why you have 8x-10x hyperthreading per CU.

 **40/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes The idea is to keep the SIMD running all the time. Wave execution time variance hasn't been a big optimization goal. There's always more work coming, so it's not a problem if some wave takes 10x time to execute compared to others.
+@AgileJebrim @NOTimothyLottes
+
+The idea is to keep the SIMD running all the time. Wave execution time variance hasn't been a big optimization goal. There's always more work coming, so it's not a problem if some wave takes 10x time to execute compared to others.

 **41/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes Basically if the SIMD is executing instructions all the time, then your workload runs at predictable amount of instructions per cycle. The problem is barriers. You wait for longest wave to finish. You can't to batch barriers to avoid turning latency into real lost SIMD cycles.
+@AgileJebrim @NOTimothyLottes
+
+Basically if the SIMD is executing instructions all the time, then your workload runs at predictable amount of instructions per cycle. The problem is barriers. You wait for longest wave to finish. You can't to batch barriers to avoid turning latency into real lost SIMD cycles.

 **42/** @AgileJebrim

-@SebAaltonen @NOTimothyLottes If they all take the same amount of time then there shouldn’t be much idling of hardware for waiting on the longest wave.
+@SebAaltonen @NOTimothyLottes
+
+If they all take the same amount of time then there shouldn’t be much idling of hardware for waiting on the longest wave.

 **43/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes That's true. But they don't take the same amount of time due to caches. That's where the 10x hyper-threading kicks in. As long as the SIMD is fed all the time, there's no visible issue with fluctuating wave lengths. Barriers make that visible. Minimal amount of barriers = good.
+@AgileJebrim @NOTimothyLottes
+
+That's true. But they don't take the same amount of time due to caches. That's where the 10x hyper-threading kicks in. As long as the SIMD is fed all the time, there's no visible issue with fluctuating wave lengths. Barriers make that visible. Minimal amount of barriers = good.

 **44/** @AgileJebrim

-@NOTimothyLottes @SebAaltonen @munohikari Would you implement a prefix sum compaction algorithm using atomicAdd?
+@NOTimothyLottes @SebAaltonen @munohikari
+
+Would you implement a prefix sum compaction algorithm using atomicAdd?

 **45/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari Standard optimizations apply, like doing wave-reductions first.
+@AgileJebrim @SebAaltonen @munohikari
+
+Standard optimizations apply, like doing wave-reductions first.

 **46/** @AgileJebrim

-@NOTimothyLottes @SebAaltonen @munohikari Okay so you don’t just blanket throw an atomicAdd on it then.
+@NOTimothyLottes @SebAaltonen @munohikari
+
+Okay so you don’t just blanket throw an atomicAdd on it then.

 **47/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari No. For things like scanning a 1-bit value, it's a wave masked bit count op in software, followed by predicating the atomic to just lane 0 of the wave. For scanning uint32s it's a log2 wave reduction, then predicating the add to lane 0. And so on
+@AgileJebrim @SebAaltonen @munohikari
+
+No. For things like scanning a 1-bit value, it's a wave masked bit count op in software, followed by predicating the atomic to just lane 0 of the wave. For scanning uint32s it's a log2 wave reduction, then predicating the add to lane 0. And so on

 ## Related

@@ -28,13 +28,17 @@ parent_post_id: "1869424048607993895"

 **1/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes @munohikari Yes, but it's going to be MUCH slower. You can do sums and reductions in groupshared memory, but if that mobile GPU doesn't have real groupshared memory, it's going to be very slow. For example GMEM based groupshared is this slow on Qualcomm (and 730 is much better than 610):
+@AgileJebrim @NOTimothyLottes @munohikari
+
+Yes, but it's going to be MUCH slower. You can do sums and reductions in groupshared memory, but if that mobile GPU doesn't have real groupshared memory, it's going to be very slow. For example GMEM based groupshared is this slow on Qualcomm (and 730 is much better than 610):

 ![](https://pbs.twimg.com/media/GfGISwfWgAI6UuY?format=jpg&name=orig)

 **2/** @SebAaltonen

-@AgileJebrim @NOTimothyLottes @munohikari X1 is the brand new laptop chip. This architecture is only on latest mobile phones. Low end is Adreno 610 and similar.
+@AgileJebrim @NOTimothyLottes @munohikari
+
+X1 is the brand new laptop chip. This architecture is only on latest mobile phones. Low end is Adreno 610 and similar.

 ## Related

@@ -27,55 +27,79 @@ in_reply_to: ""

 **1/** @AgileJebrim

-@munohikari @SebAaltonen You left out the bit where I also said no graphics pipeline. :P
+@munohikari @SebAaltonen
+
+You left out the bit where I also said no graphics pipeline. :P

 **2/** @SebAaltonen

-@AgileJebrim @munohikari Computer shaders are a can of worms for old mobile GPUs too. Some have fast groupshared memory (could be tiny), some emulate it. Some have wave intrinsics, some don't. 64-bit atomic support is nonexistent (for MM Dreams / Native style Z+payload packing).
+@AgileJebrim @munohikari
+
+Computer shaders are a can of worms for old mobile GPUs too. Some have fast groupshared memory (could be tiny), some emulate it. Some have wave intrinsics, some don't. 64-bit atomic support is nonexistent (for MM Dreams / Native style Z+payload packing).

 **3/** @SebAaltonen

-@AgileJebrim @munohikari Also compute shader writes are not compressed (pixel shader framebuffer writes have HW lossless compressor). You pay full memory bandwidth cost, which causes phone to heat (drain battery) and eventually throttle.
+@AgileJebrim @munohikari
+
+Also compute shader writes are not compressed (pixel shader framebuffer writes have HW lossless compressor). You pay full memory bandwidth cost, which causes phone to heat (drain battery) and eventually throttle.

 **4/** @AgileJebrim

-@SebAaltonen @munohikari Alternative approach is to do all rendering in screen space in a fragment shader.
+@SebAaltonen @munohikari
+
+Alternative approach is to do all rendering in screen space in a fragment shader.

 **5/** @SebAaltonen

-@AgileJebrim @munohikari If you intend to do distance field ray-tracing using volume textures, worth noting that most mobile GPUs don't do proper 3d tiling layout for volume textures. Instead they use legacy 2d sliced layout, which results in significantly more L1$ trashing. Can 5x your mem BW use.
+@AgileJebrim @munohikari
+
+If you intend to do distance field ray-tracing using volume textures, worth noting that most mobile GPUs don't do proper 3d tiling layout for volume textures. Instead they use legacy 2d sliced layout, which results in significantly more L1$ trashing. Can 5x your mem BW use.

 **6/** @AgileJebrim

-@SebAaltonen @munohikari Raycasting, no bouncing, using cubic textured bricks that emulate voxel surfaces via a parallax occlusion map approach measuring distances to each voxel surface.
+@SebAaltonen @munohikari
+
+Raycasting, no bouncing, using cubic textured bricks that emulate voxel surfaces via a parallax occlusion map approach measuring distances to each voxel surface.

 If I’m writing something for an avionics cockpit, I’d be either using an Arm Mali-G78AE or NVIDIA DRIVE AGX Thor GPU.

 **7/** @AgileJebrim

-@SebAaltonen @munohikari I’d also be using Vulkan SC, which I believe disables atomics entirely. :P
+@SebAaltonen @munohikari
+
+I’d also be using Vulkan SC, which I believe disables atomics entirely. :P

 **8/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari Disabling atomics is like chopping off both legs because someone thinks one tow has a blister when it actually doesn't.
+@AgileJebrim @SebAaltonen @munohikari
+
+Disabling atomics is like chopping off both legs because someone thinks one tow has a blister when it actually doesn't.

 **9/** @AgileJebrim

-@NOTimothyLottes @SebAaltonen @munohikari You can still implement a comparable feature yourself.
+@NOTimothyLottes @SebAaltonen @munohikari
+
+You can still implement a comparable feature yourself.

 Branches: [[archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-SebAaltonen-yes-but-its-going-to-be-much-slower-you-can-do]]

 **10/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari No actually you cannot. No method of software (or even HW) implemented lock-line algorithm survives the kind of latency in the GPU memory system. There is a big reason atomics on GPUs are done right by the last level of cache (the coherent memory domain)
+@AgileJebrim @SebAaltonen @munohikari
+
+No actually you cannot. No method of software (or even HW) implemented lock-line algorithm survives the kind of latency in the GPU memory system. There is a big reason atomics on GPUs are done right by the last level of cache (the coherent memory domain)

 **11/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari Something you really need to understand for your own benefit:
+@AgileJebrim @SebAaltonen @munohikari
+
+Something you really need to understand for your own benefit:
 (1.) There are a lot of more expensive things happening in the GPU memory system than atomics. For instance DCC compression. It requires metadata access (to get the state of memory just to do the compression on store).

 **12/** @NOTimothyLottes

-@AgileJebrim @SebAaltonen @munohikari (2.) Think of GPU atomics as a read-modify-write op. It's effectively the same behavior as a partial cacheline write-through STORE operation on HW using ECC. Because ECC eats the bits used for byte-write-mask.
+@AgileJebrim @SebAaltonen @munohikari
+
+(2.) Think of GPU atomics as a read-modify-write op. It's effectively the same behavior as a partial cacheline write-through STORE operation on HW using ECC. Because ECC eats the bits used for byte-write-mask.

 Branches: [[archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-NOTimothyLottes-3-if-you-had-multiple-line-stores-collecting-on-a]]
@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @Alecazam123

-@Dispatch_Graph Hard to believe I’m still writing games in Win32 25 years later.  But it runs on SteamOS, so can never be replaced now.
+@Dispatch_Graph
+
+Hard to believe I’m still writing games in Win32 25 years later.  But it runs on SteamOS, so can never be replaced now.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @BowTiedTails

-@Dispatch_Graph Yep. Win32 is heaven when you see what else is out there.
+@Dispatch_Graph
+
+Yep. Win32 is heaven when you see what else is out there.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @VPCOMPRESSB

-@Dispatch_Graph coincidentally, i made a Vulkan Wayland compute engine yesterday in ~600 LoC.
+@Dispatch_Graph
+
+coincidentally, i made a Vulkan Wayland compute engine yesterday in ~600 LoC.

 <video controls src="https://video.twimg.com/amplify_video/2010378825461309440/vid/avc1/1920x1080/Rbp-jYZAio7gk9-U.mp4?tag=21"></video>
 ![](https://pbs.twimg.com/media/G-ZM4-pWEAAN7YI?format=jpg&name=orig)
@@ -33,27 +33,37 @@ another problem with Win32 is that it modularizes too much, and make everything

 **2/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph You didn't get the true Wayland experience until you try interfacing to Wayland without the Wayland user-space library. Meaning do it with just the kernel calls required. Then you will have taken the gold off the poop, and understood how bad it actually is.
+@VPCOMPRESSB @Dispatch_Graph
+
+You didn't get the true Wayland experience until you try interfacing to Wayland without the Wayland user-space library. Meaning do it with just the kernel calls required. Then you will have taken the gold off the poop, and understood how bad it actually is.

 **3/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph WIN32 base system DLLs are a substantially cleaner interface. I only do non-decorated full-screen (foreground or background) window. Majority of WIN32 code fits on screen grab with mostly comments. I'm not a fan of their "WndProc" but at least it is simple.
+@VPCOMPRESSB @Dispatch_Graph
+
+WIN32 base system DLLs are a substantially cleaner interface. I only do non-decorated full-screen (foreground or background) window. Majority of WIN32 code fits on screen grab with mostly comments. I'm not a fan of their "WndProc" but at least it is simple.

 ![](https://pbs.twimg.com/media/G-Zd9wLWUAE9kZj?format=png&name=orig)

 **4/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph Some like to hate on X11, but for what it was designed to do (support both local and remote displays), it is at least very well documented and actually quite easy to roll an interface for with just Linux kernel calls (no external libraries). Docs here: https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
+@VPCOMPRESSB @Dispatch_Graph
+
+Some like to hate on X11, but for what it was designed to do (support both local and remote displays), it is at least very well documented and actually quite easy to roll an interface for with just Linux kernel calls (no external libraries). Docs here: https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html

 **5/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph Duckduckgo Wayland protocol and you get this garbage as documentation (below). Nothing there actually explains how it works, it's just high-level OOP obfustication speak. My vomit translator cannot even process this stuff.
+@VPCOMPRESSB @Dispatch_Graph
+
+Duckduckgo Wayland protocol and you get this garbage as documentation (below). Nothing there actually explains how it works, it's just high-level OOP obfustication speak. My vomit translator cannot even process this stuff.

 ![](https://pbs.twimg.com/media/G-Zjy3uXgAETWbE?format=jpg&name=orig)

 **6/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph Lets continue. It's built over unix domain sockets and doesn't support remote rendering. Haha, WFT. Just because they want to transfer file descriptors between processes for "bulk data". Wayland looses network displays and is SLOWER (fail): https://www.dedoimedo.com/computers/plasma-6-4-performance-wayland-x11-power-cpu-kernel.html
+@VPCOMPRESSB @Dispatch_Graph
+
+Lets continue. It's built over unix domain sockets and doesn't support remote rendering. Haha, WFT. Just because they want to transfer file descriptors between processes for "bulk data". Wayland looses network displays and is SLOWER (fail): https://www.dedoimedo.com/computers/plasma-6-4-performance-wayland-x11-power-cpu-kernel.html

 ![](https://pbs.twimg.com/media/G-Zk_VHW0AAFoC_?format=png&name=orig)
 ![](https://pbs.twimg.com/media/G-Zla8PXYAAdRoE?format=png&name=orig)
@@ -61,33 +71,47 @@ another problem with Win32 is that it modularizes too much, and make everything

 **7/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph Don't understand why Linux people had to take what was working, X11, and instead of just improving it, they had to make something that {removed the remote desktop, made it slower, and forces an OOP garbage design}. There is nothing good here.
+@VPCOMPRESSB @Dispatch_Graph
+
+Don't understand why Linux people had to take what was working, X11, and instead of just improving it, they had to make something that {removed the remote desktop, made it slower, and forces an OOP garbage design}. There is nothing good here.

 **8/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph Another great thing about X11, is that it was trivial to both write and use your own window manager, using the same stable system for DECADES. I had a 350 line minwm.c window manager. Dead easy.
+@VPCOMPRESSB @Dispatch_Graph
+
+Another great thing about X11, is that it was trivial to both write and use your own window manager, using the same stable system for DECADES. I had a 350 line minwm.c window manager. Dead easy.

 ![](https://pbs.twimg.com/media/G-ZrxUJXwAAINS7?format=png&name=orig)

 **9/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph Unix was about KISS (keep it simple stupid) then Linux user-space people transformed that into MISC {make it stupid complex}. Seen this trend with Audio, from OSS to ALSA, and so on.
+@VPCOMPRESSB @Dispatch_Graph
+
+Unix was about KISS (keep it simple stupid) then Linux user-space people transformed that into MISC {make it stupid complex}. Seen this trend with Audio, from OSS to ALSA, and so on.

 **10/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph I worked in the {SunOS,Solaris,HPUX,SGI,AXI,etc} workstation era and started on Linux before ELF and before pthreads. Meaning I build things based on fork() [instead of pthreads] and SHM (shared page mappings) when doing local-only interfaces (no high kernel call granularity).
+@VPCOMPRESSB @Dispatch_Graph
+
+I worked in the {SunOS,Solaris,HPUX,SGI,AXI,etc} workstation era and started on Linux before ELF and before pthreads. Meaning I build things based on fork() [instead of pthreads] and SHM (shared page mappings) when doing local-only interfaces (no high kernel call granularity).

 **11/** @NOTimothyLottes

-@VPCOMPRESSB @Dispatch_Graph If Linux people wanted to replace X11 with a local only interface, at a minimum it should have been simple SHM for the majority, and then only go outside SHM when needing to say kick a doorbell (make wake another process), etc.
+@VPCOMPRESSB @Dispatch_Graph
+
+If Linux people wanted to replace X11 with a local only interface, at a minimum it should have been simple SHM for the majority, and then only go outside SHM when needing to say kick a doorbell (make wake another process), etc.

 **12/** @o__boga

-@NOTimothyLottes @VPCOMPRESSB @Dispatch_Graph Obfuscation is the secret for its "security!"!
+@NOTimothyLottes @VPCOMPRESSB @Dispatch_Graph
+
+Obfuscation is the secret for its "security!"!

 **13/** @VPCOMPRESSB

-@NOTimothyLottes @Dispatch_Graph i've never actually used X11. this is much easier.
+@NOTimothyLottes @Dispatch_Graph
+
+i've never actually used X11. this is much easier.

 ![](https://pbs.twimg.com/media/G-a43PTXMAAIaEO?format=png&name=orig)

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @hadal101dev

-@Dispatch_Graph Yea windows makes some interesting choices lol. Calling CreateFile when you want to OPEN a file? very weird lol.
+@Dispatch_Graph
+
+Yea windows makes some interesting choices lol. Calling CreateFile when you want to OPEN a file? very weird lol.

 Never worked with wayland. What are some of the big pain points?

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @smolus

-@Dispatch_Graph one thing I appreciate about wayland is that it's just a simple protocol spec so you are not married to any particular API/library but yeah it can be a lot of work to get basic things working
+@Dispatch_Graph
+
+one thing I appreciate about wayland is that it's just a simple protocol spec so you are not married to any particular API/library but yeah it can be a lot of work to get basic things working

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @Chris_Linux

-@Dispatch_Graph Apples and oranges comparison here
+@Dispatch_Graph
+
+Apples and oranges comparison here

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @FoundryOfLies

-@Dispatch_Graph It's KWin
+@Dispatch_Graph
+
+It's KWin

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @JoaoBapt

-@Dispatch_Graph I suggest you to stick with GLFW if you’re only doing Vulkan.
+@Dispatch_Graph
+
+I suggest you to stick with GLFW if you’re only doing Vulkan.

 …and possibly use it in your D3D projects as well.

@@ -34,7 +34,9 @@ parent_post_id: "2010303501851877740"

 **2/** @Dispatch_Graph

-@Oka4902 if you give me 3 trillion dollars I can elaborate
+@Oka4902
+
+if you give me 3 trillion dollars I can elaborate

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @PervWizz

-@Dispatch_Graph Well. Win32 began as a bad API and then organically got reshaped into a worse one. Same goes for X11
+@Dispatch_Graph
+
+Well. Win32 began as a bad API and then organically got reshaped into a worse one. Same goes for X11

 Wayland was designed as the worst version of itself from the get go.

@@ -28,11 +28,15 @@ parent_post_id: "2010303501851877740"

 **1/** @Rami36217810

-@Dispatch_Graph What about x11
+@Dispatch_Graph
+
+What about x11

 **2/** @Dispatch_Graph

-@Rami36217810 its aight
+@Rami36217810
+
+its aight

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @SyntaxError2505

-@Dispatch_Graph Why? Sdl works great
+@Dispatch_Graph
+
+Why? Sdl works great

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @f82james

-@Dispatch_Graph fuck x11
+@Dispatch_Graph
+
+fuck x11

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @linux_version

-@Dispatch_Graph Oddly enough, with how old the wine project is, Win32 might be the most stable API on Linux.
+@Dispatch_Graph
+
+Oddly enough, with how old the wine project is, Win32 might be the most stable API on Linux.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @mizanyx

-@Dispatch_Graph Elaborate please, I'm still an X11 user
+@Dispatch_Graph
+
+Elaborate please, I'm still an X11 user

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @platonvin

-@Dispatch_Graph windows.h is like a nightmare but real. It is so bad, that many people manually paste parts of it to avoid including entire thing
+@Dispatch_Graph
+
+windows.h is like a nightmare but real. It is so bad, that many people manually paste parts of it to avoid including entire thing

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @ruminaik

-@Dispatch_Graph And let us say Amen
+@Dispatch_Graph
+
+And let us say Amen

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "2010303501851877740"

 **1/** @thedarkhog

-@Dispatch_Graph Get Xlibre instead. If you're using arch, btw., it's in the AUR.
+@Dispatch_Graph
+
+Get Xlibre instead. If you're using arch, btw., it's in the AUR.

 Also KDE Plasma is poorly written and has the performance of Windoze. You'll be better off with something like XFCE.

@@ -33,8 +33,12 @@ Branches: [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-s

 **2/** @ocarina588

-@Dispatch_Graph 😂😂😂, what are you using? Hyprland ?
+@Dispatch_Graph
+
+😂😂😂, what are you using? Hyprland ?

 **3/** @Dispatch_Graph

-@ocarina588 KDE Plasma
+@ocarina588
+
+KDE Plasma
@@ -28,27 +28,39 @@ parent_post_id: "1884730404587909544"

 **1/** @mu_chrinovic

-@FFmpeg I know a person with a PhD that might disagree with you
+@FFmpeg
+
+I know a person with a PhD that might disagree with you

 **2/** @NOTimothyLottes

-@mu_chrinovic @FFmpeg Yeah PTX is not assembly, it's a mid level language that is closer to a 1:1 match for the HW ISA --- BUT --- the actual register allocation and management is still done by a high-level compiler ...
+@mu_chrinovic @FFmpeg
+
+Yeah PTX is not assembly, it's a mid level language that is closer to a 1:1 match for the HW ISA --- BUT --- the actual register allocation and management is still done by a high-level compiler ...

 **3/** @janekm

-@NOTimothyLottes @mu_chrinovic @FFmpeg That's almost semantics at this point though? If you're writing x86 assembly it gets translated to microcode in the CPU as well, and will do register remapping etc. Only difference in Nvidia case that's happening in the driver, right?
+@NOTimothyLottes @mu_chrinovic @FFmpeg
+
+That's almost semantics at this point though? If you're writing x86 assembly it gets translated to microcode in the CPU as well, and will do register remapping etc. Only difference in Nvidia case that's happening in the driver, right?

 **4/** @NOTimothyLottes

-@janekm @mu_chrinovic @FFmpeg Sounds like you are trying to claim software compiler register allocation is the same as HW runtime register renaming? No. CPU register renaming maps a small set of registers to a larger set to get IPC. Compiler GPU reg allocation maps a massive SSA mess to a small set.
+@janekm @mu_chrinovic @FFmpeg
+
+Sounds like you are trying to claim software compiler register allocation is the same as HW runtime register renaming? No. CPU register renaming maps a small set of registers to a larger set to get IPC. Compiler GPU reg allocation maps a massive SSA mess to a small set.

 **5/** @janekm

-@NOTimothyLottes @mu_chrinovic @FFmpeg Fair point, my argument was merely that both cases of assembly language are really an intermediate language that gets translated to the final instructions executed by the CPU/GPU. Feels quite pedantic to claim that PTX assembly is not assembly, merely because of reg allocation 🤷‍♂️
+@NOTimothyLottes @mu_chrinovic @FFmpeg
+
+Fair point, my argument was merely that both cases of assembly language are really an intermediate language that gets translated to the final instructions executed by the CPU/GPU. Feels quite pedantic to claim that PTX assembly is not assembly, merely because of reg allocation 🤷‍♂️

 **6/** @NOTimothyLottes

-@janekm @mu_chrinovic @FFmpeg SOFTWARE
+@janekm @mu_chrinovic @FFmpeg
+
+SOFTWARE
 Assembler = human writes the physical HW instructions
 Compiler = program figures out the instructions from some other form
 ----DIFFERENT-THINGS----
@@ -58,11 +70,15 @@ Register renaming

 **7/** @janekm

-@NOTimothyLottes @mu_chrinovic @FFmpeg We've been calling it Assembly since at least when JVM byte code was first a thing. Doesn't matter that a JIT compiler will still do register allocation.
+@NOTimothyLottes @mu_chrinovic @FFmpeg
+
+We've been calling it Assembly since at least when JVM byte code was first a thing. Doesn't matter that a JIT compiler will still do register allocation.

 **8/** @NOTimothyLottes

-@janekm @mu_chrinovic @FFmpeg Sure people have been incorrectly labeling stuff for a long time
+@janekm @mu_chrinovic @FFmpeg
+
+Sure people have been incorrectly labeling stuff for a long time

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1781724279798686001"

 **1/** @jaap_null

-@KostasAAA It's a silly thing on many levels. The entire arch. limitation is awkward, then the way compilers deal (or not deal) with it is just broken. Sad to see it's still around.
+@KostasAAA
+
+It's a silly thing on many levels. The entire arch. limitation is awkward, then the way compilers deal (or not deal) with it is just broken. Sad to see it's still around.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1781724279798686001"

 **1/** @matiasgoldberg

-@KostasAAA What's the value of shaderSampledImageArrayDynamicIndexing?
+@KostasAAA
+
+What's the value of shaderSampledImageArrayDynamicIndexing?

 I'm seeing an alarming number of reports (93%!!!) saying this is true, when that'd be a blatant lie.

@@ -27,71 +27,101 @@ in_reply_to: ""

 **1/** @MyNameIsMJP

-@BelgianRenderer @KostasAAA @Nicolas_Lopez_ Apparently uniformity analysis is hard. 🙁
+@BelgianRenderer @KostasAAA @Nicolas_Lopez_
+
+Apparently uniformity analysis is hard. 🙁

 **2/** @KostasAAA

-@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.
+@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/** @MyNameIsMJP

-@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. 🙂
+@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/** @NOTimothyLottes

-@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.
+@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/** @JasperBekkers

-@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.
+@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/** @NOTimothyLottes

-@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) ...
+@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/** @NOTimothyLottes

-@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 ...
+@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/** @NOTimothyLottes

-@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 ...
+@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/** @NOTimothyLottes

-@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
+@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/** @NOTimothyLottes

-@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).
+@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/** @JasperBekkers

-@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.
+@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/** @NOTimothyLottes

-@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.
+@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/** @NOTimothyLottes

-@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.
+@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/** @NOTimothyLottes

-@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).
+@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/** @NOTimothyLottes

-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_ Try to out smart it like this,
+@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);}
@@ -102,10 +132,14 @@ It fights back, and makes something even worse. [RED] ... see the multiply by ac

 **16/** @NOTimothyLottes

-@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 ...
+@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/** @NOTimothyLottes

-@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.
+@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.
@@ -28,7 +28,9 @@ parent_post_id: "1588515348223254528"

 **1/** @rianflo

-@NOTimothyLottes Welcome Not Back! 🤘🏻♥️
+@NOTimothyLottes
+
+Welcome Not Back! 🤘🏻♥️

 ## Related

@@ -30,6 +30,8 @@ in_reply_to: "1588331007622930432"

 **1/** @NOTimothyLottes

-@rianflo Vulkan: ~1500 lines of overhead (including header src, as I don't include) for complete hotrod bind-everything-only-once compute-only gfx engine. Not a fan of VK bloatware API complexity, but frankly it can be minimized, and exposes enough to do wonderfull things to the hardware.
+@rianflo
+
+Vulkan: ~1500 lines of overhead (including header src, as I don't include) for complete hotrod bind-everything-only-once compute-only gfx engine. Not a fan of VK bloatware API complexity, but frankly it can be minimized, and exposes enough to do wonderfull things to the hardware.

 Branches: [[archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/2022-11-04-rianflo-welcome-not-back]]
@@ -27,4 +27,6 @@ in_reply_to: "1590003266129383424"

 **1/** @NOTimothyLottes

-@olson_dan If only PC vendors with open ISAs (AMD/Intel) would allow loading binary compute shaders in VK built using non-driver toolchains. If Valve enabled binary shaders on Steam Deck in Linux, that would be my new exclusive dev platform, instead of just a possible porting target
+@olson_dan
+
+If only PC vendors with open ISAs (AMD/Intel) would allow loading binary compute shaders in VK built using non-driver toolchains. If Valve enabled binary shaders on Steam Deck in Linux, that would be my new exclusive dev platform, instead of just a possible porting target
@@ -28,11 +28,15 @@ parent_post_id: "1653556990302470151"

 **1/** @BrianKaris

-@NOTimothyLottes Great to see these return. Still have any of the videos?
+@NOTimothyLottes
+
+Great to see these return. Still have any of the videos?

 **2/** @NOTimothyLottes

-@BrianKaris I might, but will have to build a machine to attach the old drives. Too busy making new stuff
+@BrianKaris
+
+I might, but will have to build a machine to attach the old drives. Too busy making new stuff

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1653556990302470151"

 **1/** @BrookeHodgman

-@NOTimothyLottes I remember watching all of these blog entries fondly ❤
+@NOTimothyLottes
+
+I remember watching all of these blog entries fondly ❤

 ## Related

@@ -28,15 +28,21 @@ parent_post_id: "1653556990302470151"

 **1/** @Karyuutensei

-@NOTimothyLottes Is the blog still up somewhere?
+@NOTimothyLottes
+
+Is the blog still up somewhere?

 **2/** @NOTimothyLottes

-@Karyuutensei No but I have archives in pieces on old hard drives. So there is a chance I might restore it some day.
+@Karyuutensei
+
+No but I have archives in pieces on old hard drives. So there is a chance I might restore it some day.

 **3/** @Karyuutensei

-@NOTimothyLottes Speaking of archives, http://archive.org  has some from the blogspot here https://web.archive.org/web/20160427173127/http://timothylottes.blogspot.com/ but basically nothing from the github page :S
+@NOTimothyLottes
+
+Speaking of archives, http://archive.org  has some from the blogspot here https://web.archive.org/web/20160427173127/http://timothylottes.blogspot.com/ but basically nothing from the github page :S

 ## Related

@@ -28,11 +28,15 @@ parent_post_id: "1653556990302470151"

 **1/** @oconnorkg

-@NOTimothyLottes Did you write an engine called Atom? Talked about it on the http://OpenGL.org forum?
+@NOTimothyLottes
+
+Did you write an engine called Atom? Talked about it on the http://OpenGL.org forum?

 **2/** @NOTimothyLottes

-@oconnorkg There was also Atomontage or something like that by another person. I had a project called Atom, but I don't remember if I was on the OGL message board
+@oconnorkg
+
+There was also Atomontage or something like that by another person. I had a project called Atom, but I don't remember if I was on the OGL message board

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1653556990302470151"

 **1/** @won3d

-@NOTimothyLottes I remember all those fondly. I also remembered the trick you did to batch logical draw calls with branching in the shader
+@NOTimothyLottes
+
+I remember all those fondly. I also remembered the trick you did to batch logical draw calls with branching in the shader

 ## Related

@@ -28,15 +28,21 @@ parent_post_id: "1653559205360553985"

 **1/** @won3d

-@NOTimothyLottes My former thesis advisor was a big proponent of forth. Apparently SunOS used forth in preboot and you could do all sorts of wacky things. He interfaced with custom compute accelerators this way. I agree that concatenantive programming languages are underexplored
+@NOTimothyLottes
+
+My former thesis advisor was a big proponent of forth. Apparently SunOS used forth in preboot and you could do all sorts of wacky things. He interfaced with custom compute accelerators this way. I agree that concatenantive programming languages are underexplored

 **2/** @NOTimothyLottes

-@won3d I think it is less the exact form of the language but more 'the way to make things simple' that truely important now.
+@won3d
+
+I think it is less the exact form of the language but more 'the way to make things simple' that truely important now.

 **3/** @won3d

-@NOTimothyLottes There's something about Forth-style composition that is has a very nice appeal. It really seems to marry syntax and semantics very directly (but I can appreciate it at a distance, having not done any real work in it as you have)
+@NOTimothyLottes
+
+There's something about Forth-style composition that is has a very nice appeal. It really seems to marry syntax and semantics very directly (but I can appreciate it at a distance, having not done any real work in it as you have)

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1653570742762479620"

 **1/** @Laxer3A

-@NOTimothyLottes This is when I learned about your work and found it incredible. Nowadays with 4K / 8K, people are really craving for a very good shader/model to emulate as close as possible the CRT feel for arcade / old console etc. (I am serious)
+@NOTimothyLottes
+
+This is when I learned about your work and found it incredible. Nowadays with 4K / 8K, people are really craving for a very good shader/model to emulate as close as possible the CRT feel for arcade / old console etc. (I am serious)

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1653556990302470151"

 **1/** @arm1n

-@NOTimothyLottes Thanks for digging those up! Great stuff, very inspiring.
+@NOTimothyLottes
+
+Thanks for digging those up! Great stuff, very inspiring.

 ## Related

@@ -217,15 +217,21 @@ Despite header docs which imply flag only works on DOMAIN_VRAM, using DOMAIN_GTT

 **37/** @DaveAirlie

-@NOTimothyLottes the problem there is usually tiling, GPUs expect graphicy things in VRAM to be tiled in very specific ways, it's hard to have a storage device do that. Using a transfer engine that can tile/detile makes a lot more sense.
+@NOTimothyLottes
+
+the problem there is usually tiling, GPUs expect graphicy things in VRAM to be tiled in very specific ways, it's hard to have a storage device do that. Using a transfer engine that can tile/detile makes a lot more sense.

 **38/** @NOTimothyLottes

-@DaveAirlie The obvious elephant is an engine using only buffers for resource streaming and doing its own GPU-side decompression. This is practical NOW and portable too. But the lack of a bus master no-CPU direct storage transfer is a serious problem for throughput.
+@DaveAirlie
+
+The obvious elephant is an engine using only buffers for resource streaming and doing its own GPU-side decompression. This is practical NOW and portable too. But the lack of a bus master no-CPU direct storage transfer is a serious problem for throughput.

 **39/** @NOTimothyLottes

-@DaveAirlie See raw texture streaming (even with lossless compression) is way less interesting now given modern massive data tech direction, u want substantially better lossy compression simply to fit in launch constraints. So really, buffers are the way to go anyway :)
+@DaveAirlie
+
+See raw texture streaming (even with lossless compression) is way less interesting now given modern massive data tech direction, u want substantially better lossy compression simply to fit in launch constraints. So really, buffers are the way to go anyway :)

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1671276990987370501"

 **1/** @SheriefFYI

-@NOTimothyLottes Great thread!
+@NOTimothyLottes
+
+Great thread!

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1671276990987370501"

 **1/** @never_released

-@NOTimothyLottes On Linux, NVIDIA has a very good UVM.
+@NOTimothyLottes
+
+On Linux, NVIDIA has a very good UVM.

 However, the infrastructure for doing that on Windows is quite lacking to say the least...

@@ -28,13 +28,17 @@ parent_post_id: "1674757854471806977"

 **1/** @SebAaltonen

-@NOTimothyLottes Would be nice to talk a full presentation about this topic, but people want me to show cool tech and pretty pixels instead. Maybe one day.
+@NOTimothyLottes
+
+Would be nice to talk a full presentation about this topic, but people want me to show cool tech and pretty pixels instead. Maybe one day.

 I will save your image for that day (if I get approval to use it), since Twitter search is super bad.

 **2/** @NOTimothyLottes

-@SebAaltonen "Approval", haha, sure it's covered under my favorite license
+@SebAaltonen
+
+"Approval", haha, sure it's covered under my favorite license

 ![](https://pbs.twimg.com/media/Fz3_kb8WYAMXvcT?format=png&name=orig)
 ## Related
@@ -28,12 +28,16 @@ parent_post_id: "1674757854471806977"

 **1/** @_spolsh

-@NOTimothyLottes Once in a while people need to be reminded to stop the bloat, understand the machine guts and be self aware about productive process
+@NOTimothyLottes
+
+Once in a while people need to be reminded to stop the bloat, understand the machine guts and be self aware about productive process
 https://tonsky.me/blog/disenchantment/

 **2/** @NOTimothyLottes

-@_spolsh That was a fantastic read, thanks
+@_spolsh
+
+That was a fantastic read, thanks

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @domipheus

-@NOTimothyLottes I like this, given I never write code any more.
+@NOTimothyLottes
+
+I like this, given I never write code any more.
 sadly i am still a grumpy git.

 ## Related
@@ -28,12 +28,16 @@ parent_post_id: "1674757854471806977"

 **1/** @leonard_coder

-@NOTimothyLottes $4e71
+@NOTimothyLottes
+
+$4e71
 if you know, you know

 **2/** @NOTimothyLottes

-@leonard_coder ${EA, 1A, 3A, 5A, 7A, DA, or FA}
+@leonard_coder
+
+${EA, 1A, 3A, 5A, 7A, DA, or FA}

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @CodingFiend

-@NOTimothyLottes @Jonathan_Blow i designed a language Beads, which uses a graph DB, has no memory allocation, super modular, approaches this minimalism as close as humanly possible, but billable hour / job security seeking programmers refuse to try it
+@NOTimothyLottes @Jonathan_Blow
+
+i designed a language Beads, which uses a graph DB, has no memory allocation, super modular, approaches this minimalism as close as humanly possible, but billable hour / job security seeking programmers refuse to try it

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @DefenceForceOrg

-@NOTimothyLottes Many games used to be like that, at least the ones without dynamic content, mods, etc...
+@NOTimothyLottes
+
+Many games used to be like that, at least the ones without dynamic content, mods, etc...

 Most of the stuff I worked on on PSX and Dreamcast basically just loads big files with everything pre-allocated and aligned properly at the final location, ready to use.

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @PierreTerdiman

-@NOTimothyLottes I was calling it "disoriented programming" just the other day.
+@NOTimothyLottes
+
+I was calling it "disoriented programming" just the other day.

 https://x.com/PierreTerdiman/status/1673389650172321813?s=20

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @SimonNordon

-@NOTimothyLottes NOP is ideal.
+@NOTimothyLottes
+
+NOP is ideal.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @TimSweeneyEpic

-@NOTimothyLottes Can teach it in abstinence-only programming classes!
+@NOTimothyLottes
+
+Can teach it in abstinence-only programming classes!

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @asparagiii

-@NOTimothyLottes Looks like a koala
+@NOTimothyLottes
+
+Looks like a koala

 ![](https://pbs.twimg.com/media/Fz88Bk0WAAApDzL?format=jpg&name=orig)
 ## Related
@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @azeke1984

-@NOTimothyLottes Best software is absense of it:
+@NOTimothyLottes
+
+Best software is absense of it:

 https://en.wikipedia.org/wiki/The_Mythical_Man-Month

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @claudiogonzalo

-@NOTimothyLottes c++ to √c
+@NOTimothyLottes
+
+c++ to √c

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @helpful_signage

-@NOTimothyLottes Folks, they're calling it "computer oriented programming". It's where you stop trying to impress peers and just tell the computer the best way to do things
+@NOTimothyLottes
+
+Folks, they're calling it "computer oriented programming". It's where you stop trying to impress peers and just tell the computer the best way to do things

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1674757854471806977"

 **1/** @wyattscarpenter

-@NOTimothyLottes https://github.com/wyattscarpenter/wu
+@NOTimothyLottes
+
+https://github.com/wyattscarpenter/wu

 ## Related

@@ -28,33 +28,45 @@ parent_post_id: "1688491417109196800"

 **1/** @BlurBusters

-@NOTimothyLottes Very interesting "crosstalk from voltage inversion" artifact. Some repeating patterns or flicker patterns can trigger crosstalk artifacts too. Behavior varies a lot between TN, IPS, and VA, but all of them have to alternate voltage polarity spatially and temporally.
+@NOTimothyLottes
+
+Very interesting "crosstalk from voltage inversion" artifact. Some repeating patterns or flicker patterns can trigger crosstalk artifacts too. Behavior varies a lot between TN, IPS, and VA, but all of them have to alternate voltage polarity spatially and temporally.

 ![](https://pbs.twimg.com/media/F3I8AZmW0AEy6jn?format=png&name=orig)
 ![](https://pbs.twimg.com/media/F3I8BVlXoAAnuJB?format=png&name=orig)

 **2/** @BlurBusters

-@NOTimothyLottes Related reads:
+@NOTimothyLottes
+
+Related reads:
 https://www.lagom.nl/lcd-test/inversion.php
 https://forums.blurbusters.com/viewtopic.php?t=7539
 http://www.techmind.org/lcd/#:~:text=Inversion

 **3/** @NOTimothyLottes

-@BlurBusters I appreciate the links. Came to the same conclusion, for LCDs when doing low scaling like 1:2x2 'CRT' emulation, I'll have to do a stylized blue noise phosphor pattern instead.
+@BlurBusters
+
+I appreciate the links. Came to the same conclusion, for LCDs when doing low scaling like 1:2x2 'CRT' emulation, I'll have to do a stylized blue noise phosphor pattern instead.

 **4/** @Ak4115x

-@NOTimothyLottes @BlurBusters "VCOM inversion" -if wasn't line2line but frame2frame that'd "flicker" instead at half the refresh rate so that's why it's preferred& there's also another peculiarity of this scheme. Worth looking into, spent a few hours afternoon,it's late evening now maybe share another time.
+@NOTimothyLottes @BlurBusters
+
+"VCOM inversion" -if wasn't line2line but frame2frame that'd "flicker" instead at half the refresh rate so that's why it's preferred& there's also another peculiarity of this scheme. Worth looking into, spent a few hours afternoon,it's late evening now maybe share another time.

 **5/** @BlurBusters

-@Ak4115x @NOTimothyLottes Inversion algorithm is both spatial and temporal on all of them, regardless of spatial pattern of voltage inversion. Line to line is also frame to frame. (lines swaps voltage polarity in next frame)
+@Ak4115x @NOTimothyLottes
+
+Inversion algorithm is both spatial and temporal on all of them, regardless of spatial pattern of voltage inversion. Line to line is also frame to frame. (lines swaps voltage polarity in next frame)

 **6/** @Ak4115x

-@BlurBusters @NOTimothyLottes LCOS has singular VCOM there's no pattern to it and no such artifact.
+@BlurBusters @NOTimothyLottes
+
+LCOS has singular VCOM there's no pattern to it and no such artifact.

 ## Related

@@ -28,15 +28,21 @@ parent_post_id: "1692560907988029769"

 **1/** @tomcr2100

-@NOTimothyLottes i am not quite sure what do you mean by subpixel scan? do you override the normal (refresh) scanout process?
+@NOTimothyLottes
+
+i am not quite sure what do you mean by subpixel scan? do you override the normal (refresh) scanout process?

 **2/** @NOTimothyLottes

-@tomcr2100 It's like "clear-type" font rendering where if you know the LCD sub-pixel configuration for the RGB components of a pixel, you can do a much better job of computing and outputing the value at the specific RGB sub-pixel element. So i'm doing this for CRT-like emulation on the Deck
+@tomcr2100
+
+It's like "clear-type" font rendering where if you know the LCD sub-pixel configuration for the RGB components of a pixel, you can do a much better job of computing and outputing the value at the specific RGB sub-pixel element. So i'm doing this for CRT-like emulation on the Deck

 **3/** @tomcr2100

-@NOTimothyLottes just curious, i started doing something similar, but this year i have focused more on rest&recover. i went with a trilinear style aperture grill approximation, and just allow prim components to leak into the two others.
+@NOTimothyLottes
+
+just curious, i started doing something similar, but this year i have focused more on rest&recover. i went with a trilinear style aperture grill approximation, and just allow prim components to leak into the two others.

 ## Related

@@ -28,11 +28,15 @@ parent_post_id: "1692397318471926054"

 **1/** @Karyuutensei

-@NOTimothyLottes How many passes do you need to produce this result?
+@NOTimothyLottes
+
+How many passes do you need to produce this result?

 **2/** @NOTimothyLottes

-@Karyuutensei 1 pass: 12 fetches/outpix, in 2 batches. I use 6 gather4's to grab a 4-wide(x)2-line region for the {R,G,B} channels. Then 6 more fetches to do energy conserving computation of output for each {nearest 2 lines}x{R,G,B} channel based {intensity, position vertically on scan}.
+@Karyuutensei
+
+1 pass: 12 fetches/outpix, in 2 batches. I use 6 gather4's to grab a 4-wide(x)2-line region for the {R,G,B} channels. Then 6 more fetches to do energy conserving computation of output for each {nearest 2 lines}x{R,G,B} channel based {intensity, position vertically on scan}.

 ## Related

@@ -28,11 +28,15 @@ parent_post_id: "1735631826427732305"

 **1/** @SebAaltonen

-@NOTimothyLottes They design one API for each separate use case instead of making general purpose flexible SIMD hardware and API for the developers to implement what ever algorithm they need. CPU side got this right. PS2 had correct design, but Nvidia choose hardware T&L for desktop :(
+@NOTimothyLottes
+
+They design one API for each separate use case instead of making general purpose flexible SIMD hardware and API for the developers to implement what ever algorithm they need. CPU side got this right. PS2 had correct design, but Nvidia choose hardware T&L for desktop :(

 **2/** @SebAaltonen

-@NOTimothyLottes I kind of understand hardware T&L back then because it was a new field and programmable hardware didn't exist. But now we have massive amount of wide SIMDs and bandwidth and big caches too. We can do better!
+@NOTimothyLottes
+
+I kind of understand hardware T&L back then because it was a new field and programmable hardware didn't exist. But now we have massive amount of wide SIMDs and bandwidth and big caches too. We can do better!

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1736157335058300999"

 **1/** @AgileJebrim

-@NOTimothyLottes Yep put the whole game logic in a game.glsl compute shader.
+@NOTimothyLottes
+
+Yep put the whole game logic in a game.glsl compute shader.

 **2/** @AgileJebrim

@@ -28,25 +28,35 @@ parent_post_id: "1736147815829565624"

 **1/** @SheriefFYI

-@NOTimothyLottes two point six seconds?!! D3D12CreateDevice() on my machine is ~300ms..
+@NOTimothyLottes
+
+two point six seconds?!! D3D12CreateDevice() on my machine is ~300ms..

 **2/** @NOTimothyLottes

-@SheriefFYI Yeah and that's a warm second run too. I dev on crippled laptops so when the handicaps are removed the stuff really flies.
+@SheriefFYI
+
+Yeah and that's a warm second run too. I dev on crippled laptops so when the handicaps are removed the stuff really flies.

 **3/** @SheriefFYI

-@NOTimothyLottes still that sounds like a lot, what specs / driver? Any weird vk layers loading?
+@NOTimothyLottes
+
+still that sounds like a lot, what specs / driver? Any weird vk layers loading?

 **4/** @NOTimothyLottes

-@SheriefFYI Ok, yeah just reprofiled, and it's down to 269 ms. Best part of the Win10 experience, never know what is actually happening in the background.
+@SheriefFYI
+
+Ok, yeah just reprofiled, and it's down to 269 ms. Best part of the Win10 experience, never know what is actually happening in the background.

 ![](https://pbs.twimg.com/media/GBhSG-XXMAAT0FS?format=png&name=orig)

 **5/** @SheriefFYI

-@NOTimothyLottes *whew* that sounds more normal
+@NOTimothyLottes
+
+*whew* that sounds more normal

 ## Related

@@ -28,13 +28,17 @@ parent_post_id: "1736154923408953499"

 **1/** @VPCOMPRESSB

-@NOTimothyLottes so you're preallocating every type of descriptor to a max count and aliasing them with various qualifiers/attributes? all that in a single memory layout?
+@NOTimothyLottes
+
+so you're preallocating every type of descriptor to a max count and aliasing them with various qualifiers/attributes? all that in a single memory layout?

 if this is the case, the program identifier makes sense. you can just swap out the code, leaving the data untouched.

 **2/** @NOTimothyLottes

-@VPCOMPRESSB I use the layout aliasing to choose things like {read-only K$ reads, vs read-write texture cache access} for buffers, for making sure GLC=1 (write through to coherent cache domain) is enabled for stores (image and buffer), as well as selecting the texel format for image access :)
+@VPCOMPRESSB
+
+I use the layout aliasing to choose things like {read-only K$ reads, vs read-write texture cache access} for buffers, for making sure GLC=1 (write through to coherent cache domain) is enabled for stores (image and buffer), as well as selecting the texel format for image access :)

 **3/** @VPCOMPRESSB

@@ -50,27 +54,39 @@ aliasing supports this even further, with explicit intentions for resources.

 **4/** @NOTimothyLottes

-@VPCOMPRESSB On modern desktop GPUs it is very efficient to have everything bound all the time (bind everything once/frame). On AMD on use the descriptor is loaded into SGPRs. You only pay for what is used. And ideally group descriptors used together near so they share same cache lines.
+@VPCOMPRESSB
+
+On modern desktop GPUs it is very efficient to have everything bound all the time (bind everything once/frame). On AMD on use the descriptor is loaded into SGPRs. You only pay for what is used. And ideally group descriptors used together near so they share same cache lines.

 **5/** @NOTimothyLottes

-@VPCOMPRESSB Merging independent shaders is then easy. Merging dependent shaders is more complex. You can both do it an unsafe way or a safe way (too long for one tweet)...
+@VPCOMPRESSB
+
+Merging independent shaders is then easy. Merging dependent shaders is more complex. You can both do it an unsafe way or a safe way (too long for one tweet)...

 **6/** @NOTimothyLottes

-@VPCOMPRESSB The unsafe way: launch a N+M sized 1D dispatch. Bank on having enough work in N such that when the dependent M starts that enough of N is finished in practice. This can work when early M depends on only early N workgroups.
+@VPCOMPRESSB
+
+The unsafe way: launch a N+M sized 1D dispatch. Bank on having enough work in N such that when the dependent M starts that enough of N is finished in practice. This can work when early M depends on only early N workgroups.

 **7/** @NOTimothyLottes

-@VPCOMPRESSB There are various safe ways. For instance  if the dependent work isn't done, one can conditionally duplicate the work. Or conditionally use a fallback. Or only use the pre task if it had finished to accelerate the second, for example hierarchical empty space skipping ...
+@VPCOMPRESSB
+
+There are various safe ways. For instance  if the dependent work isn't done, one can conditionally duplicate the work. Or conditionally use a fallback. Or only use the pre task if it had finished to accelerate the second, for example hierarchical empty space skipping ...

 **8/** @NOTimothyLottes

-@VPCOMPRESSB The challenge of course is that the  obvious stuff like spin waiting isn't safe because of bad API and driver design : no forward progress guarantee (on preemption, etc)
+@VPCOMPRESSB
+
+The challenge of course is that the  obvious stuff like spin waiting isn't safe because of bad API and driver design : no forward progress guarantee (on preemption, etc)

 **9/** @NOTimothyLottes

-@VPCOMPRESSB Quite literally they just need to put in a guarantee that workgroups with lower coords in scan order are launched first and restored first in a partial preemption restore. Then you could safely spin on work in a prior numbered workgroup
+@VPCOMPRESSB
+
+Quite literally they just need to put in a guarantee that workgroups with lower coords in scan order are launched first and restored first in a partial preemption restore. Then you could safely spin on work in a prior numbered workgroup

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1742743018929557805"

 **1/** @kenpex

-@NOTimothyLottes It's what debuggers should be. Debuggers made zero progress in the last decade, but fundamentally they patch running code... just they are limited to patch an interrupt instead of allowing us to do... anything. Even tracepoints, while nice, are a castrated version of livecode.
+@NOTimothyLottes
+
+It's what debuggers should be. Debuggers made zero progress in the last decade, but fundamentally they patch running code... just they are limited to patch an interrupt instead of allowing us to do... anything. Even tracepoints, while nice, are a castrated version of livecode.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1776597200073568623"

 **1/** @MartinJIFuller

-@NOTimothyLottes @SebAaltonen A worthwhile project, knowledge well worth sharing, but is a book the right format? Perhaps yes, just thinking out loud.
+@NOTimothyLottes @SebAaltonen
+
+A worthwhile project, knowledge well worth sharing, but is a book the right format? Perhaps yes, just thinking out loud.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1776597200073568623"

 **1/** @RickyAH

-@NOTimothyLottes @SebAaltonen @MartinJIFuller Ha! That won’t save you from my follow
+@NOTimothyLottes @SebAaltonen @MartinJIFuller
+
+Ha! That won’t save you from my follow

 <video controls src="https://video.twimg.com/tweet_video/GKoMKCHWwAAWLvG.mp4"></video>
 ## Related
@@ -28,7 +28,9 @@ parent_post_id: "1776597200073568623"

 **1/** @BenSimsTech

-@NOTimothyLottes @SebAaltonen @MartinJIFuller Oh sick, I'm deep in optimising shaders in an AAA game for GCN hardware right now (You can probably guess the platform(s)) so this is super relevant to me. 😅
+@NOTimothyLottes @SebAaltonen @MartinJIFuller
+
+Oh sick, I'm deep in optimising shaders in an AAA game for GCN hardware right now (You can probably guess the platform(s)) so this is super relevant to me. 😅
 Going to give it all a thorough read, I'm after all the GCN info I can find right now.

 ## Related
@@ -29,7 +29,9 @@ in_reply_to: "1776518700230721688"

 **1/** @NOTimothyLottes

-@MartinJIFuller @SebAaltonen On https://mastodon.gamedev.place/@NOTimothyLottes I'm collecting posts with AMD GPU disassembly dumps for a book on everything the shader compiler 'isn't doing'. Constant AMD GPU compiler perf bug SPAM is a key part of my online strategy to keep a low follower count.
+@MartinJIFuller @SebAaltonen
+
+On https://mastodon.gamedev.place/@NOTimothyLottes I'm collecting posts with AMD GPU disassembly dumps for a book on everything the shader compiler 'isn't doing'. Constant AMD GPU compiler perf bug SPAM is a key part of my online strategy to keep a low follower count.

 ![](https://pbs.twimg.com/media/GKe8HDtXYAAOrfj?format=jpg&name=orig)
 Branches: [[archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-06-MartinJIFuller-a-worthwhile-project-knowledge-well-worth-sharing]], [[archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-08-RickyAH-ha-that-wont-save-you-from-my-follow]], [[archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-09-BenSimsTech-oh-sick-im-deep-in-optimising-shaders-in-an-aaa]]
@@ -27,4 +27,6 @@ in_reply_to: ""

 **1/** @NOTimothyLottes

-@Nerfoxingaround @SebAaltonen It was only later when systems forced C ABI library interfaces with it's stacks and junk that things got messy and only because of the C. Then C++ happened and things got much worse. Pure ASM is easy, its interfacing with the bloat world that got hard.
+@Nerfoxingaround @SebAaltonen
+
+It was only later when systems forced C ABI library interfaces with it's stacks and junk that things got messy and only because of the C. Then C++ happened and things got much worse. Pure ASM is easy, its interfacing with the bloat world that got hard.
@@ -28,19 +28,27 @@ parent_post_id: "1857813028349128825"

 **1/** @bmcnett

-@NOTimothyLottes So each line is 63 spaces followed by a \n, and those 63 spaces get replaced by printable characters dynamically? I have long dreamed of a text format with a fixed 128 byte line width, and cache line size is gradually switching over from 64 to 128
+@NOTimothyLottes
+
+So each line is 63 spaces followed by a \n, and those 63 spaces get replaced by printable characters dynamically? I have long dreamed of a text format with a fixed 128 byte line width, and cache line size is gradually switching over from 64 to 128

 **2/** @NOTimothyLottes

-@bmcnett Yes fixed character[63]='\n', string fills until then or spaces out. I did 128-char once, but still sometimes use small VGA resolutions. Also written a source editor a few times with this fixed line size, makes for a very simple implementation ...
+@bmcnett
+
+Yes fixed character[63]='\n', string fills until then or spaces out. I did 128-char once, but still sometimes use small VGA resolutions. Also written a source editor a few times with this fixed line size, makes for a very simple implementation ...

 **3/** @bmcnett

-@NOTimothyLottes Variable line width ASCII text files made a lot of sense when storage was 100KB or 100MB or 100GB, but now that it's in the terabytes, why even bother
+@NOTimothyLottes
+
+Variable line width ASCII text files made a lot of sense when storage was 100KB or 100MB or 100GB, but now that it's in the terabytes, why even bother

 **4/** @NOTimothyLottes

-@bmcnett That line of thinking is universal solution to most self-inflicted problems of the modern era.
+@bmcnett
+
+That line of thinking is universal solution to most self-inflicted problems of the modern era.

 ## Related

@@ -28,32 +28,46 @@ parent_post_id: "1857805438151983120"

 **1/** @datenwolf

-@NOTimothyLottes Why the heck do you care about cache lines, if you write to a mmaped file? Of course there's overhead: TLBs aren't free. And TLBs matter… at lot in fact. When you map the file, initially the kernel marks some address space, but doesn't populate it with pages. 1/
+@NOTimothyLottes
+
+Why the heck do you care about cache lines, if you write to a mmaped file? Of course there's overhead: TLBs aren't free. And TLBs matter… at lot in fact. When you map the file, initially the kernel marks some address space, but doesn't populate it with pages. 1/

 **2/** @datenwolf

-@NOTimothyLottes On the first write to a non-faulted page, the kernel has to find a free page in memory, associate it in the page table, all the while keeping an eye on all threads process, since changes to a process virtual address space must appear atomic. 2/
+@NOTimothyLottes
+
+On the first write to a non-faulted page, the kernel has to find a free page in memory, associate it in the page table, all the while keeping an eye on all threads process, since changes to a process virtual address space must appear atomic. 2/

 **3/** @datenwolf

-@NOTimothyLottes Memory maps aren't free. Simple writes to a file will easily outperform and cause less overhead, than naively implemented mmaped I/O. 3/
+@NOTimothyLottes
+
+Memory maps aren't free. Simple writes to a file will easily outperform and cause less overhead, than naively implemented mmaped I/O. 3/

 **4/** @NOTimothyLottes

-@datenwolf BTW, I pre-fault my mapped files. Just like I pre-fault the binary and data segments too. But sure the pre-fault could go stale. And yes TLBs are a system perf issue, but atlas you need admin priv on Windows to play 2 MiB pages for data, so it's off the table
+@datenwolf
+
+BTW, I pre-fault my mapped files. Just like I pre-fault the binary and data segments too. But sure the pre-fault could go stale. And yes TLBs are a system perf issue, but atlas you need admin priv on Windows to play 2 MiB pages for data, so it's off the table

 **5/** @NOTimothyLottes

-@datenwolf Why cacheline aligned and sized on the CPU? In theory store the entire line in a short enough timeframe and your Read-Modify-Write becomes just a Write! CPU doesn't have byte-write-mask (I think). If SW+HW is good. And threads keeping to isolated lines means no false sharing. Etc
+@datenwolf
+
+Why cacheline aligned and sized on the CPU? In theory store the entire line in a short enough timeframe and your Read-Modify-Write becomes just a Write! CPU doesn't have byte-write-mask (I think). If SW+HW is good. And threads keeping to isolated lines means no false sharing. Etc

 **6/** @datenwolf

-@NOTimothyLottes (That cacheline remark was meant rhetorically; between cache misses and page faults, a page fault will largely overshadow a cache miss in performance overhead.
+@NOTimothyLottes
+
+(That cacheline remark was meant rhetorically; between cache misses and page faults, a page fault will largely overshadow a cache miss in performance overhead.
 But yes, if you prefault, then that problem is mitigated.)

 **7/** @NOTimothyLottes

-@datenwolf 'Smart' people keep trying to impose (aka force) their will on others through poor system APIs, like not being able to pre-pin pages. Good look buddy, I'll just run a background task that continuously touch walks the pages I want pinned anyway.
+@datenwolf
+
+'Smart' people keep trying to impose (aka force) their will on others through poor system APIs, like not being able to pre-pin pages. Good look buddy, I'll just run a background task that continuously touch walks the pages I want pinned anyway.

 ## Related

@@ -28,15 +28,21 @@ parent_post_id: "1857803914604618029"

 **1/** @static_assert_0

-@NOTimothyLottes This is super cool, but why map a file and not just stdout?
+@NOTimothyLottes
+
+This is super cool, but why map a file and not just stdout?

 **2/** @vodangkhoa873

-@static_assert_0 @NOTimothyLottes The writes can be done concurrently from many threads?
+@static_assert_0 @NOTimothyLottes
+
+The writes can be done concurrently from many threads?

 **3/** @NOTimothyLottes

-@vodangkhoa873 @static_assert_0 Yes, one 'atomicAdd(atomAdr,1)&65535' to get the line number (window of 65536 max lines) then write the line individually. Only contention is on that atomicAdd CPU instruction which is as minimal as possible.
+@vodangkhoa873 @static_assert_0
+
+Yes, one 'atomicAdd(atomAdr,1)&65535' to get the line number (window of 65536 max lines) then write the line individually. Only contention is on that atomicAdd CPU instruction which is as minimal as possible.

 I do the atomic add instruction using simple inline ASM (below)

@@ -44,11 +50,15 @@ I do the atomic add instruction using simple inline ASM (below)

 **4/** @static_assert_0

-@NOTimothyLottes @vodangkhoa873 I love this, but are you not able to get that codegen with intrinsics or just normal C?
+@NOTimothyLottes @vodangkhoa873
+
+I love this, but are you not able to get that codegen with intrinsics or just normal C?

 **5/** @NOTimothyLottes

-@static_assert_0 @vodangkhoa873 I've been hand rolling intrinsics CPU-side in GCC with inline asm since the dawn of support for that. So haven't kept up with the high-level-lang mess fire since.
+@static_assert_0 @vodangkhoa873
+
+I've been hand rolling intrinsics CPU-side in GCC with inline asm since the dawn of support for that. So haven't kept up with the high-level-lang mess fire since.

 ## Related

@@ -28,15 +28,21 @@ parent_post_id: "1857804669994565771"

 **1/** @HerrUppoHoppa

-@NOTimothyLottes Curious why you memory map the 32 bit counter to the file. Also why does it get half the file as opposed to just the end of the mapped region?
+@NOTimothyLottes
+
+Curious why you memory map the 32 bit counter to the file. Also why does it get half the file as opposed to just the end of the mapped region?

 **2/** @NOTimothyLottes

-@HerrUppoHoppa It's pow2 message lines so fixing wrap is AND(cnt,lines-1). Counter after that and needs to take a page minimum. So yes I could make the size slightly smaller, but just lazy. Counter in file because then multiple runs accumulate in the file for comparison.
+@HerrUppoHoppa
+
+It's pow2 message lines so fixing wrap is AND(cnt,lines-1). Counter after that and needs to take a page minimum. So yes I could make the size slightly smaller, but just lazy. Counter in file because then multiple runs accumulate in the file for comparison.

 **3/** @HerrUppoHoppa

-@NOTimothyLottes Ah I see, interesting solution!
+@NOTimothyLottes
+
+Ah I see, interesting solution!

 ## Related

@@ -28,35 +28,51 @@ parent_post_id: "1859369992355021246"

 **1/** @AgileJebrim

-@NOTimothyLottes How reliable in your experience in code like that is the compilation to avoid branches?
+@NOTimothyLottes
+
+How reliable in your experience in code like that is the compilation to avoid branches?

 **2/** @NOTimothyLottes

-@AgileJebrim Lots of stuff can get mapped by the compiler to V_CNDMASK_B32 instead of branching by using mix(a,b,bool) syntax. I rarely use branching because of how horrible the code generation is. No way to express that the common path stay code linear either, etc.
+@AgileJebrim
+
+Lots of stuff can get mapped by the compiler to V_CNDMASK_B32 instead of branching by using mix(a,b,bool) syntax. I rarely use branching because of how horrible the code generation is. No way to express that the common path stay code linear either, etc.

 **3/** @AgileJebrim

-@NOTimothyLottes I know in CUDA-land that it likes to create branches for ternaries if it contains more than 4 total instructions in a statement.
+@NOTimothyLottes
+
+I know in CUDA-land that it likes to create branches for ternaries if it contains more than 4 total instructions in a statement.

 **4/** @NOTimothyLottes

-@AgileJebrim But the real problem is lacking of explicit controls, and lacking implicit branch hints (wave-uniform/non-uniform, expected branch hit rate, etc). Better if we could just do explicit ASM style branch instructions and labels.
+@AgileJebrim
+
+But the real problem is lacking of explicit controls, and lacking implicit branch hints (wave-uniform/non-uniform, expected branch hit rate, etc). Better if we could just do explicit ASM style branch instructions and labels.

 **5/** @AgileJebrim

-@NOTimothyLottes Well I seek to ban branches entirely, so that’s the exact opposite of what I want.
+@NOTimothyLottes
+
+Well I seek to ban branches entirely, so that’s the exact opposite of what I want.

 **6/** @NOTimothyLottes

-@AgileJebrim If your shader I$ is say 32 KiB and your instructions average say 8-bytes. You have 4 K instructions before you are streaming the program not just the data. Code size is actually important. And while micro level unroll is needed, macro level duplication is a problem with tiny I$
+@AgileJebrim
+
+If your shader I$ is say 32 KiB and your instructions average say 8-bytes. You have 4 K instructions before you are streaming the program not just the data. Code size is actually important. And while micro level unroll is needed, macro level duplication is a problem with tiny I$

 **7/** @AgileJebrim

-@NOTimothyLottes I avoid the duplication of instruction patterns too. I feel it’s a failure to properly parallelize if you’re repeating the same instructions instead of data parallelizing further.
+@NOTimothyLottes
+
+I avoid the duplication of instruction patterns too. I feel it’s a failure to properly parallelize if you’re repeating the same instructions instead of data parallelizing further.

 **8/** @AgileJebrim

-@NOTimothyLottes One more reason why I avoid functions.
+@NOTimothyLottes
+
+One more reason why I avoid functions.

 ## Related

@@ -28,45 +28,65 @@ parent_post_id: "1859791162091110754"

 **1/** @AgileJebrim

-@NOTimothyLottes Shouldn’t uniform be a scalar?
+@NOTimothyLottes
+
+Shouldn’t uniform be a scalar?

 **2/** @NOTimothyLottes

-@AgileJebrim Well 'uniform' in GLSL is a storage qualifier, "Uniforms are so named because they DO NOT CHANGE from one shader invocation to the next within a particular rendering cal" so you probably want another term for SGPR to avoid aliasing qualifiers
+@AgileJebrim
+
+Well 'uniform' in GLSL is a storage qualifier, "Uniforms are so named because they DO NOT CHANGE from one shader invocation to the next within a particular rendering cal" so you probably want another term for SGPR to avoid aliasing qualifiers

 **3/** @AgileJebrim

-@NOTimothyLottes Within ISPC, uniform means scalar and varying means vector.
+@NOTimothyLottes
+
+Within ISPC, uniform means scalar and varying means vector.

 **4/** @AgileJebrim

-@NOTimothyLottes Looking deeper into the definition of SGPRs. They’re uniform just across each wavefront, rather than the entire dispatch yeah?
+@NOTimothyLottes
+
+Looking deeper into the definition of SGPRs. They’re uniform just across each wavefront, rather than the entire dispatch yeah?

 **5/** @NOTimothyLottes

-@AgileJebrim Yes it's a separate register file and logic unit that is per-wave instead of per-lane. Since it's introduction in Turing, NV calls them "URX for uniform registers" while AMD calls them SGPRs (scalar general purpose registers)
+@AgileJebrim
+
+Yes it's a separate register file and logic unit that is per-wave instead of per-lane. Since it's introduction in Turing, NV calls them "URX for uniform registers" while AMD calls them SGPRs (scalar general purpose registers)

 **6/** @AgileJebrim

-@NOTimothyLottes Almost sounding like we need an alternative IR to SPIR-V. One with predicated instructions and these wavefront-uniform registers/instructions. Maybe a PTX -> RDNA backend compiler?
+@NOTimothyLottes
+
+Almost sounding like we need an alternative IR to SPIR-V. One with predicated instructions and these wavefront-uniform registers/instructions. Maybe a PTX -> RDNA backend compiler?

 **7/** @NOTimothyLottes

-@AgileJebrim As history goes, most re-writes fall into nearly the same problem as before. I'd rather have the fixes be applied to the existing stuff first (fix SPIR-V and GLSL, etc)
+@AgileJebrim
+
+As history goes, most re-writes fall into nearly the same problem as before. I'd rather have the fixes be applied to the existing stuff first (fix SPIR-V and GLSL, etc)

 **8/** @AgileJebrim

-@NOTimothyLottes Perhaps. That existing PTX Vulkan extension does come to mind though.
+@NOTimothyLottes
+
+Perhaps. That existing PTX Vulkan extension does come to mind though.

 **9/** @CodePotrick

-@AgileJebrim @NOTimothyLottes Its kinda annoying to put sgpr like logic in an ir tho as they have very specific limitations on each platform.
+@AgileJebrim @NOTimothyLottes
+
+Its kinda annoying to put sgpr like logic in an ir tho as they have very specific limitations on each platform.

 Generalizing them in an ir might actually be a pessimisation.

 **10/** @CodePotrick

-@AgileJebrim @NOTimothyLottes Amd for example can't do float ops on sgprs, so when you would allow float ops in the ir, amd has to move them to a vgpr, perform float op, move them back to sgpr for each ir-sgpr float op.
+@AgileJebrim @NOTimothyLottes
+
+Amd for example can't do float ops on sgprs, so when you would allow float ops in the ir, amd has to move them to a vgpr, perform float op, move them back to sgpr for each ir-sgpr float op.

 There are other examples for this.

@@ -74,25 +94,35 @@ And nvidias have even other constrains.

 **11/** @AgileJebrim

-@CodePotrick @NOTimothyLottes And what’s the alternative right now? Just keep it all in a VGPR all the time?
+@CodePotrick @NOTimothyLottes
+
+And what’s the alternative right now? Just keep it all in a VGPR all the time?

 **12/** @CodePotrick

-@AgileJebrim @NOTimothyLottes Ideally you'd avoid any float ops as long as you can to keep things in sgprs if you need to save registers/want the uniformity.
+@AgileJebrim @NOTimothyLottes
+
+Ideally you'd avoid any float ops as long as you can to keep things in sgprs if you need to save registers/want the uniformity.

 If you need float ops on that var its probably best to keep it in vgprs if the alternative would be to transfer between sgpr and vgpr a lot

 **13/** @AgileJebrim

-@CodePotrick @NOTimothyLottes I wish I could work solely with integers all the time but if I did that on NV hardware, I’d be losing half the available ALUs.
+@CodePotrick @NOTimothyLottes
+
+I wish I could work solely with integers all the time but if I did that on NV hardware, I’d be losing half the available ALUs.

 **14/** @AgileJebrim

-@CodePotrick @NOTimothyLottes I haven’t looked closely at AMD hardware since I don’t work with it much.
+@CodePotrick @NOTimothyLottes
+
+I haven’t looked closely at AMD hardware since I don’t work with it much.

 **15/** @CodePotrick

-@AgileJebrim @NOTimothyLottes they have their actual isa public and inspectable which is really nice to know whats actually happening.
+@AgileJebrim @NOTimothyLottes
+
+they have their actual isa public and inspectable which is really nice to know whats actually happening.

 Rga is also really good. Feels like im more in control with amd compared to nvidia.

@@ -100,7 +130,9 @@ Maybe thats just the low level gremlin in my speaking tho ;).

 **16/** @AgileJebrim

-@CodePotrick @NOTimothyLottes I do have access to some of NVIDIA’s NDA documentation and tools…
+@CodePotrick @NOTimothyLottes
+
+I do have access to some of NVIDIA’s NDA documentation and tools…

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1868492851170205803"

 **1/** @axelgneiting

-@NOTimothyLottes @kechogarcia I'm well aware. It's really curious they still stick to this design after so many years.
+@NOTimothyLottes @kechogarcia
+
+I'm well aware. It's really curious they still stick to this design after so many years.

 ## Related

@@ -33,25 +33,35 @@ in_reply_to: ""

 **2/** @kechogarcia

-@NOTimothyLottes Dxc hlsl sm 6.5 lets you index into ResourceDescriptorHeap directly and cast to whatever resource type. That and mutable vulkan descriptors, you wouldn't need to go the buffer Zoo route.... But then dxc spirv ...
+@NOTimothyLottes
+
+Dxc hlsl sm 6.5 lets you index into ResourceDescriptorHeap directly and cast to whatever resource type. That and mutable vulkan descriptors, you wouldn't need to go the buffer Zoo route.... But then dxc spirv ...

 **3/** @NOTimothyLottes

-@kechogarcia Read<32,64,128>(uint64_t base, uint32_t offset, uint32_t immediate, uint32_t cacheControl, uint32_t format);
+@kechogarcia
+
+Read<32,64,128>(uint64_t base, uint32_t offset, uint32_t immediate, uint32_t cacheControl, uint32_t format);

 And be done with this stupid mess

 **4/** @axelgneiting

-@NOTimothyLottes @kechogarcia NVidia can't just do random format conversions without it being a texture descriptor I thought?
+@NOTimothyLottes @kechogarcia
+
+NVidia can't just do random format conversions without it being a texture descriptor I thought?

 **5/** @NOTimothyLottes

-@axelgneiting @kechogarcia Can get the non-conversion {signed/unsigned short/int/long and half/float/double, of {1-4} components}. Which is good enough to start the interface. Then yes for NV you'd need to alias via a storage_texel_buffer to get {10:11:11,10:10:10:2,<u/s>norm*}
+@axelgneiting @kechogarcia
+
+Can get the non-conversion {signed/unsigned short/int/long and half/float/double, of {1-4} components}. Which is good enough to start the interface. Then yes for NV you'd need to alias via a storage_texel_buffer to get {10:11:11,10:10:10:2,<u/s>norm*}

 **6/** @NOTimothyLottes

-@axelgneiting @kechogarcia Then there are rough edges to TEXEL_BUFFER
+@axelgneiting @kechogarcia
+
+Then there are rough edges to TEXEL_BUFFER

 9-bit shared 5-bit E -> read only NV, no AMD
 sRGB -> yes NV, no AMD
@@ -28,7 +28,9 @@ parent_post_id: "1868716773937414589"

 **1/** @AgileJebrim

-@NOTimothyLottes @GustavSterbrant Fair enough. Current compilers are a bloated mess anyways and you’d get much faster times with your own assembler.
+@NOTimothyLottes @GustavSterbrant
+
+Fair enough. Current compilers are a bloated mess anyways and you’d get much faster times with your own assembler.

 ## Related

@@ -27,18 +27,26 @@ in_reply_to: ""

 **1/** @NOTimothyLottes

-@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL
+@GustavSterbrant
+
+So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL

 **2/** @AgileJebrim

-@NOTimothyLottes @GustavSterbrant If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else?
+@NOTimothyLottes @GustavSterbrant
+
+If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else?

 **3/** @NOTimothyLottes

-@AgileJebrim @GustavSterbrant At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK
+@AgileJebrim @GustavSterbrant
+
+At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK

 **4/** @NOTimothyLottes

-@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.
+@AgileJebrim @GustavSterbrant
+
+Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.

 Branches: [[archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess]]
@@ -28,15 +28,21 @@ parent_post_id: "1870343645926224197"

 **1/** @AgileJebrim

-@NOTimothyLottes Have you tried using the Intel cache controls extension I shared earlier to see if they work on AMD?
+@NOTimothyLottes
+
+Have you tried using the Intel cache controls extension I shared earlier to see if they work on AMD?

 **2/** @NOTimothyLottes

-@AgileJebrim Not enough free time. Given that AMD's compiler has some serious correctness bugs ignoring memory qualifiers, I doubt they implemented the Intel extension.
+@AgileJebrim
+
+Not enough free time. Given that AMD's compiler has some serious correctness bugs ignoring memory qualifiers, I doubt they implemented the Intel extension.

 **3/** @NOTimothyLottes

-@AgileJebrim Will say though that if they ever implement a WMMA access extension (I don't know if they did or didn't yet), and they don't have streaming memory qualifier support they are just shooting their own AI stock$$$ gold rush foot off.
+@AgileJebrim
+
+Will say though that if they ever implement a WMMA access extension (I don't know if they did or didn't yet), and they don't have streaming memory qualifier support they are just shooting their own AI stock$$$ gold rush foot off.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1875589737282679108"

 **1/** @marc_b_reynolds

-@NOTimothyLottes It's pretty amazing how good the Hastings approximations still are.  I'd note that they are designed for minimizing absolute error which isn't what you'd want for general purpose usage but it's the right answer for "all angles are equally important" problems.
+@NOTimothyLottes
+
+It's pretty amazing how good the Hastings approximations still are.  I'd note that they are designed for minimizing absolute error which isn't what you'd want for general purpose usage but it's the right answer for "all angles are equally important" problems.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1875583660545732960"

 **1/** @JBrooksBSI

-@NOTimothyLottes Some optimization ideas:
+@NOTimothyLottes
+
+Some optimization ideas:

 1) For RDNA2 simd, insn-dependency stalls make it unlikely to achieve 100% VALU utilization. Try unrolling 2x or 4x

@@ -38,11 +40,15 @@ parent_post_id: "1875583660545732960"

 **2/** @NOTimothyLottes

-@JBrooksBSI Lack of ABS modifiers on V_PK ops basically kills FP16 benefit here unfortunately. I do unroll when not VGPR limited (favorite optimization). Wary though of SALU/VALU crossings due to latency + scheduling behavior (loss of operand cache, etc). VCC probably has special forwarding
+@JBrooksBSI
+
+Lack of ABS modifiers on V_PK ops basically kills FP16 benefit here unfortunately. I do unroll when not VGPR limited (favorite optimization). Wary though of SALU/VALU crossings due to latency + scheduling behavior (loss of operand cache, etc). VCC probably has special forwarding

 **3/** @JBrooksBSI

-@NOTimothyLottes I did an approx equal-area mapping to a 2D texture in 2018
+@NOTimothyLottes
+
+I did an approx equal-area mapping to a 2D texture in 2018

 Approach was to map sphere to Archimedean solid rhombicuboctahedron (triangles and squares) packed into a 2D texture

@@ -28,7 +28,9 @@ parent_post_id: "1875589737282679108"

 **1/** @pixelmager

-@NOTimothyLottes I was looking at a very similar problem for hemi-octahedrons recently. I definitely need to revisit in the context of this EAM paper, I ended up with a pretty slow polar-coordinate-remapping instead to move precision to the horizon https://www.shadertoy.com/view/wsBXzD
+@NOTimothyLottes
+
+I was looking at a very similar problem for hemi-octahedrons recently. I definitely need to revisit in the context of this EAM paper, I ended up with a pretty slow polar-coordinate-remapping instead to move precision to the horizon https://www.shadertoy.com/view/wsBXzD

 ## Related

@@ -28,15 +28,21 @@ parent_post_id: "1883580512171942335"

 **1/** @bmcnett

-@NOTimothyLottes My take is similar, but I also feel that a lot of processing is best done predictively in parallel across multiple future frames, one SIMD lane per future frame
+@NOTimothyLottes
+
+My take is similar, but I also feel that a lot of processing is best done predictively in parallel across multiple future frames, one SIMD lane per future frame

 **2/** @NOTimothyLottes

-@bmcnett Don't necessarily want to store all predictions raw though. One of the advantages of say simple things like baked directional lightmaps is that one keeps the data for multiple "frames" (or views) in a compressed form until just right before usage, and it's mis-predict safe
+@bmcnett
+
+Don't necessarily want to store all predictions raw though. One of the advantages of say simple things like baked directional lightmaps is that one keeps the data for multiple "frames" (or views) in a compressed form until just right before usage, and it's mis-predict safe

 **3/** @bmcnett

-@NOTimothyLottes Yeah, you need to store many prediction outputs in compressed form, with the time dimension being one over which you compress, in addition to whatever spatial dimensions are relevant
+@NOTimothyLottes
+
+Yeah, you need to store many prediction outputs in compressed form, with the time dimension being one over which you compress, in addition to whatever spatial dimensions are relevant

 Limited hw support for that, sadly

@@ -28,7 +28,9 @@ parent_post_id: "1883591956598845661"

 **1/** @noop_dev

-@NOTimothyLottes I thought framegen was just an offspring of mpeg2 motion prediction, at least how it was in TVs for 15 years.
+@NOTimothyLottes
+
+I thought framegen was just an offspring of mpeg2 motion prediction, at least how it was in TVs for 15 years.

 ## Related

@@ -28,29 +28,41 @@ parent_post_id: "1883569959286313322"

 **1/** @Varaquilex

-@NOTimothyLottes A visualization of said cold caches on a CS workload from Timothy's GDC 2018 Engine Optimization Hot Lap slides: https://gpuopen.com/wp-content/uploads/2018/05/gdc_2018_sponsored_engine_optimization_hot_lap.pptx
+@NOTimothyLottes
+
+A visualization of said cold caches on a CS workload from Timothy's GDC 2018 Engine Optimization Hot Lap slides: https://gpuopen.com/wp-content/uploads/2018/05/gdc_2018_sponsored_engine_optimization_hot_lap.pptx

 ![](https://pbs.twimg.com/media/GiVPBdfbAAAhqJ8?format=jpg&name=orig)

 **2/** @NOTimothyLottes

-@Varaquilex Amazingly unfortunate that AMD still doesn't release the tool that those instruction trace captures had been visualized on. It's the best and most useful tool period I've ever seen at any company in the industry.
+@Varaquilex
+
+Amazingly unfortunate that AMD still doesn't release the tool that those instruction trace captures had been visualized on. It's the best and most useful tool period I've ever seen at any company in the industry.

 **3/** @NOTimothyLottes

-@Varaquilex If they did choose to release it, I'd teach the world how to use it well, for free. For hardcore optimization it is close to ideal. RGP doesn't start to really show you what you need to know to make good hardcore engineering decisions on AMD hardware.
+@Varaquilex
+
+If they did choose to release it, I'd teach the world how to use it well, for free. For hardcore optimization it is close to ideal. RGP doesn't start to really show you what you need to know to make good hardcore engineering decisions on AMD hardware.

 **4/** @NOTimothyLottes

-@Varaquilex This is a hint for someone like Valve who could take their RADV SQTT (https://www.phoronix.com/news/RADV-SQTT-Profiling-Support) interface and build something truly transformative for GPU shader engineering
+@Varaquilex
+
+This is a hint for someone like Valve who could take their RADV SQTT (https://www.phoronix.com/news/RADV-SQTT-Profiling-Support) interface and build something truly transformative for GPU shader engineering

 **5/** @NOTimothyLottes

-@Varaquilex Mix that kind of visualization tool with a good shader compiler (and HW intrinsics) and basically it's the kind of crack a serious GPU shader dev cannot say no too
+@Varaquilex
+
+Mix that kind of visualization tool with a good shader compiler (and HW intrinsics) and basically it's the kind of crack a serious GPU shader dev cannot say no too

 **6/** @Varaquilex

-@NOTimothyLottes That tool was one of the most insightful tools I have ever used. I do miss it. It would really be awesome to see it released to the public.
+@NOTimothyLottes
+
+That tool was one of the most insightful tools I have ever used. I do miss it. It would really be awesome to see it released to the public.

 ## Related

@@ -59,17 +59,23 @@ Note one can inline something like CAS/RCAS (what I did at AMD) into the custom

 **6/** @dankbaker

-@NOTimothyLottes Is there an example shader that does that custom resolve?
+@NOTimothyLottes
+
+Is there an example shader that does that custom resolve?

 **7/** @NOTimothyLottes

-@dankbaker Probably not in the config you are interested in (I'm assuming spatial with no scaling?) Feel free to DM me. Most of these things need adaption specific to the config. Last one I did was huge spatial scaling for a CRT-styled scalar using this kernel,
+@dankbaker
+
+Probably not in the config you are interested in (I'm assuming spatial with no scaling?) Feel free to DM me. Most of these things need adaption specific to the config. Last one I did was huge spatial scaling for a CRT-styled scalar using this kernel,

 ![](https://pbs.twimg.com/media/GiZv5SFWYAAyv2W?format=jpg&name=orig)

 **8/** @NOTimothyLottes

-@dankbaker My project is monochome so the kernel blending logic is single channel, and the content is designed to handle a huge amount of negative lobe well so I don't constrain ringing (BLUE, replace with 'm.y*RINGING'), and everything in linear of course ... but it should provide an idea
+@dankbaker
+
+My project is monochome so the kernel blending logic is single channel, and the content is designed to handle a huge amount of negative lobe well so I don't constrain ringing (BLUE, replace with 'm.y*RINGING'), and everything in linear of course ... but it should provide an idea

 ![](https://pbs.twimg.com/media/GiZxt_6X0AARcFR?format=png&name=orig)

@@ -28,11 +28,15 @@ parent_post_id: "1884360689093091618"

 **1/** @NOTimothyLottes

-@MichalDrobot My mindset is more tuned towards rendering without minSampleShading and using the temporal component to get the shading resolution up since base frame rate will be high anyway. So no soft VRS in my line of thinking either (other than whatever falls out of 8xMSAA render)
+@MichalDrobot
+
+My mindset is more tuned towards rendering without minSampleShading and using the temporal component to get the shading resolution up since base frame rate will be high anyway. So no soft VRS in my line of thinking either (other than whatever falls out of 8xMSAA render)

 **2/** @MichalDrobot

-@NOTimothyLottes That’s pretty much exactly the mindset and what ended up shipping in Killzone Shadow Fall (4xMSAA -> 2x scaling + TAA) and in FarCry4 8xMSAA FMask only + analytical resolve + TAA
+@NOTimothyLottes
+
+That’s pretty much exactly the mindset and what ended up shipping in Killzone Shadow Fall (4xMSAA -> 2x scaling + TAA) and in FarCry4 8xMSAA FMask only + analytical resolve + TAA
 Doing sub samples in FC4 was challenging due to all that AT foliage.

 ## Related
@@ -33,57 +33,81 @@ Branches: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really

 **2/** @MichalDrobot

-@NOTimothyLottes Hey that’s literally what our VRS is doing with all those tricks and more. We just don’t call it an upsampler ; )
+@NOTimothyLottes
+
+Hey that’s literally what our VRS is doing with all those tricks and more. We just don’t call it an upsampler ; )
 On PC we resolve MSAA to texture2DArray to retain plane separation benefits for bandwidth and coherency

 **3/** @NOTimothyLottes

-@MichalDrobot Larger differences are
+@MichalDrobot
+
+Larger differences are
 (1.) Your VRS is PSL'ing to a regular grid? (need the actual 8x pattern for what I'm suggesting)
 (2.) Sounds like you are getting benefit from FMASK due to the soft VRS, but for what I'm suggesting the NV flat+DCC layout is way better

 **4/** @MichalDrobot

-@NOTimothyLottes 1) it’s 4xMSAA but we DRS only on X axis which is matching your case I believe. Similar how it was done it Killzone Shadowfall.
+@NOTimothyLottes
+
+1) it’s 4xMSAA but we DRS only on X axis which is matching your case I believe. Similar how it was done it Killzone Shadowfall.
 8xMSAA we could explore XY scaling
 2) depends. On PC it’s flat /w DCC. On gen8 it’s fmask packed. Gen9 is FMask with DCC plane0/1

 **5/** @MichalDrobot

-@NOTimothyLottes But sure I agree that 8x is the way to go for 4K. Our challenge is that we still have gen8 with 1k target and at those resolutions 8x scales really sub linear due to quad occupancy
+@NOTimothyLottes
+
+But sure I agree that 8x is the way to go for 4K. Our challenge is that we still have gen8 with 1k target and at those resolutions 8x scales really sub linear due to quad occupancy

 **6/** @NOTimothyLottes

-@MichalDrobot I guess the question then is if you implement variable spatial scaling in the custom resolve, is the 8xMSAA loss something that can easily be covered by increased spatial scale on the low end HW? 8x area scaling at 8xMSAA is still likely good for 3xAA on edges at spatial-only
+@MichalDrobot
+
+I guess the question then is if you implement variable spatial scaling in the custom resolve, is the 8xMSAA loss something that can easily be covered by increased spatial scale on the low end HW? 8x area scaling at 8xMSAA is still likely good for 3xAA on edges at spatial-only

 Branches: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering]]

 **7/** @MichalDrobot

-@NOTimothyLottes If low end hw is decent with MSAA AND you can control triangle density effectively to combat quad occupancy loss (we can’t) - that’s the best there is imo.
+@NOTimothyLottes
+
+If low end hw is decent with MSAA AND you can control triangle density effectively to combat quad occupancy loss (we can’t) - that’s the best there is imo.
 FWIW that’s why we use stencil even for geo edges for MSAA - because we get too many interior edges that don’t do anything

 **8/** @NOTimothyLottes

-@MichalDrobot I see, yes once authoring pushes tri/pix density then what makes sense changes. I was thinking more of the way things had been authored in the relief mapping era.
+@MichalDrobot
+
+I see, yes once authoring pushes tri/pix density then what makes sense changes. I was thinking more of the way things had been authored in the relief mapping era.

 **9/** @MichalDrobot

-@NOTimothyLottes Then you need invest heavily into visbuffer for “simple draws” and pay setup price to compensate those deficiencies.  involved pipeline that is not portable
+@NOTimothyLottes
+
+Then you need invest heavily into visbuffer for “simple draws” and pay setup price to compensate those deficiencies.  involved pipeline that is not portable
 I can totally see your plan working for specific art styles or more retro gaming. There is a huge Indy market for this

 **10/** @NOTimothyLottes

-@MichalDrobot If tri/pix density is high, even if there are some huge triangles left, without substantially good multi-scale LOD (meaning cluster count scaling), I think soft culling alone falls off the !/$ curve for scaling - hints perhaps past the crossover for non-triangle rendering
+@MichalDrobot
+
+If tri/pix density is high, even if there are some huge triangles left, without substantially good multi-scale LOD (meaning cluster count scaling), I think soft culling alone falls off the !/$ curve for scaling - hints perhaps past the crossover for non-triangle rendering

 **11/** @NOTimothyLottes

-@MichalDrobot At that stage I'd have transitioned to direct final view reconstruction from object space domain. Walking object space, atomicMin(MSB{z,ref}LSB) at some good enough density into the final projected space, then use a neighborhood of 'refs' to get back to object space neighborhoods
+@MichalDrobot
+
+At that stage I'd have transitioned to direct final view reconstruction from object space domain. Walking object space, atomicMin(MSB{z,ref}LSB) at some good enough density into the final projected space, then use a neighborhood of 'refs' to get back to object space neighborhoods

 **12/** @NOTimothyLottes

-@MichalDrobot ... for the filtering. One can effectively cancel atomics per lane based on local projected screen-space density to deal with domain stretch (skinning), so it gets to be highly scalable.
+@MichalDrobot
+
+... for the filtering. One can effectively cancel atomics per lane based on local projected screen-space density to deal with domain stretch (skinning), so it gets to be highly scalable.

 **13/** @NOTimothyLottes

-@MichalDrobot The TAA reconstructions all crossed that threshold of cost where it's easy to swap in reconstruction from something other than screen-space. And with no disocclusion trouble, object space is much less of a challenge to go from.
+@MichalDrobot
+
+The TAA reconstructions all crossed that threshold of cost where it's easy to swap in reconstruction from something other than screen-space. And with no disocclusion trouble, object space is much less of a challenge to go from.
@@ -130,8 +130,12 @@ I think ultimately those in the industry who don't like the current status quo,

 **17/** @0xpatrickhan

-@NOTimothyLottes What are some problem areas you think need to be tackled? I’ve read some of what you’ve written in response to some of the gripes of modern day temporal supersampling/AA. What else? Anything that IHVs would be uniquely positioned to do?
+@NOTimothyLottes
+
+What are some problem areas you think need to be tackled? I’ve read some of what you’ve written in response to some of the gripes of modern day temporal supersampling/AA. What else? Anything that IHVs would be uniquely positioned to do?

 **18/** @NOTimothyLottes

-@0xpatrickhan There is a laundry list of things IHVs dont expose or expose very poorly for basic compute shaders, making it quite difficult or impossible to get a compiler to do the right thing. Fix those and devs like myself could easily build better than AI tech options
+@0xpatrickhan
+
+There is a laundry list of things IHVs dont expose or expose very poorly for basic compute shaders, making it quite difficult or impossible to get a compiler to do the right thing. Fix those and devs like myself could easily build better than AI tech options
@@ -28,11 +28,15 @@ parent_post_id: "1912477061467304351"

 **1/** @BoganBits

-@NOTimothyLottes Could a shader compiler not do this?  i.e. detect such inefficient code, and "re-vectorise" it, so to speak i.e. have each shader instance do 2 at once, interleaved
+@NOTimothyLottes
+
+Could a shader compiler not do this?  i.e. detect such inefficient code, and "re-vectorise" it, so to speak i.e. have each shader instance do 2 at once, interleaved

 **2/** @NOTimothyLottes

-@BoganBits This is something to be done at the dispatch level, not something a compiler knows about
+@BoganBits
+
+This is something to be done at the dispatch level, not something a compiler knows about

 ## Related

@@ -28,12 +28,16 @@ parent_post_id: "1912477061467304351"

 **1/** @BoganBits

-@NOTimothyLottes I would be interested to see a concrete example of this
+@NOTimothyLottes
+
+I would be interested to see a concrete example of this
 ideally with a benchmark to show the improvement

 **2/** @NOTimothyLottes

-@BoganBits Early STP had a mode to pipeline the dependent passes, that was back when it was being developed out of Unity. That mode was way faster. But later it was removed because Unity wouldn't allow resources bound for read+write at the same time = fail.
+@BoganBits
+
+Early STP had a mode to pipeline the dependent passes, that was back when it was being developed out of Unity. That mode was way faster. But later it was removed because Unity wouldn't allow resources bound for read+write at the same time = fail.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1912484261321392231"

 **1/** @DjMolehill

-@NOTimothyLottes branching, cache locality, and memory handling are key 🔥
+@NOTimothyLottes
+
+branching, cache locality, and memory handling are key 🔥

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1912483968563269946"

 **1/** @JBrooksBSI

-@NOTimothyLottes I'd add:
+@NOTimothyLottes
+
+I'd add:

 Standardized, documented ISA that enables compatibility across multiple GPU generations (& max 256 VGPRs).

@@ -36,25 +38,35 @@ WGP (WorkGroup Processor) mode which doubles the # of SIMD units executing a sin

 **2/** @NOTimothyLottes

-@JBrooksBSI Personally I still don't like the WGP+wave32 stuff. Limited dual issue instructions with less operand flexibility (wave64 back to back issue IMO is better, just HW dual pipe transcendentals). WGP's two L0 cache and related resource split issues.
+@JBrooksBSI
+
+Personally I still don't like the WGP+wave32 stuff. Limited dual issue instructions with less operand flexibility (wave64 back to back issue IMO is better, just HW dual pipe transcendentals). WGP's two L0 cache and related resource split issues.

 **3/** @JBrooksBSI

-@NOTimothyLottes WGP mode and wave32 are separate features. WGP mode schedules waves within a threadgroup across both CUs (4x SIMDs) in each WGP instead of limiting waves to a single CU (2x SIMD).
+@NOTimothyLottes
+
+WGP mode and wave32 are separate features. WGP mode schedules waves within a threadgroup across both CUs (4x SIMDs) in each WGP instead of limiting waves to a single CU (2x SIMD).

 **4/** @NOTimothyLottes

-@JBrooksBSI Yeah so it's more the wave32 that I don't like
+@JBrooksBSI
+
+Yeah so it's more the wave32 that I don't like

 **5/** @JBrooksBSI

-@NOTimothyLottes I'd like to discuss this in more detail, as I have found wave32 to be faster than wave64 for everything except some vertex shaders.
+@NOTimothyLottes
+
+I'd like to discuss this in more detail, as I have found wave32 to be faster than wave64 for everything except some vertex shaders.

 I think the reason wave64 can be faster for vertex shaders is that only half the VS waves get launched, so more occupancy for PS/CS waves per WGP.

 **6/** @JBrooksBSI

-@NOTimothyLottes The reasons Wave64 has been slower for me:
+@NOTimothyLottes
+
+The reasons Wave64 has been slower for me:
 1) More VGPR pressure = less occupancy
 2) More GL0/LDS pressure = more stalls
 3) 64-lane scalar logic is slower than scalar 32
@@ -64,7 +76,9 @@ I spot-unroll 2x-4x for more intra-wave parallelism as needed.

 **7/** @NOTimothyLottes

-@JBrooksBSI Re
+@JBrooksBSI
+
+Re
 1) With what I do, high occupancy is often slower
 2) I rarely use LDS
 3) It's half the K$ loads for wave64
@@ -72,7 +86,9 @@ I spot-unroll 2x-4x for more intra-wave parallelism as needed.

 **8/** @JBrooksBSI

-@NOTimothyLottes Wow, that is wildly different from what I do.
+@NOTimothyLottes
+
+Wow, that is wildly different from what I do.

 Why is high occupancy slower? (VGPR pressure? Cache pressure?)

@@ -28,17 +28,23 @@ parent_post_id: "1917652589358858332"

 **1/** @onatt0

-@NOTimothyLottes holy truthnuke - and people think C is the optimal state of possible runtimes when it's a very limited runtime to have state mixed call/data-stacks
+@NOTimothyLottes
+
+holy truthnuke - and people think C is the optimal state of possible runtimes when it's a very limited runtime to have state mixed call/data-stacks

 not only you have to keep the whole stack around with replicated state, it limits to serialized execution instead of parallel

 **2/** @NOTimothyLottes

-@onatt0 I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.
+@onatt0
+
+I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.

 **3/** @onatt0

-@NOTimothyLottes when C became *the* execution model, it restricted all future hardware, HW gets built with how the C compiler will compile to it instead of what's ultimately a good design and a malleable macro-lang to map to HW
+@NOTimothyLottes
+
+when C became *the* execution model, it restricted all future hardware, HW gets built with how the C compiler will compile to it instead of what's ultimately a good design and a malleable macro-lang to map to HW

 ofc a lot of people want portability so we went the boring route

@@ -28,17 +28,23 @@ parent_post_id: "1917646466417381426"

 **1/** @onatt0

-@NOTimothyLottes IMO code compilation is inherently sequential+ "execution contextual", dynamic logic execution to get the binary as the essence vs a static lang
+@NOTimothyLottes
+
+IMO code compilation is inherently sequential+ "execution contextual", dynamic logic execution to get the binary as the essence vs a static lang

 codegen with execution on GPU could work as 2-items(vreg)/stack and 32K cells per lane for AI to map code to data instead of weights?

 **2/** @NOTimothyLottes

-@onatt0 So for x86 I've many times written code gen with extra nop-prefix padding to fix all instructions to a multiple of known 32-bits. Which means you know in advance sizing of everything, then you can easily do parallel code generation. So need not necessarily all be serial
+@onatt0
+
+So for x86 I've many times written code gen with extra nop-prefix padding to fix all instructions to a multiple of known 32-bits. Which means you know in advance sizing of everything, then you can easily do parallel code generation. So need not necessarily all be serial

 **3/** @NOTimothyLottes

-@onatt0 However I'm often building then instantly using code while generating a baked binary to use later, so that regard much is inherently serially dependent. This bootstrapping technique is perhaps one the great things to learn from things like color forth IMO.
+@onatt0
+
+However I'm often building then instantly using code while generating a baked binary to use later, so that regard much is inherently serially dependent. This bootstrapping technique is perhaps one the great things to learn from things like color forth IMO.

 ## Related

@@ -28,7 +28,9 @@ parent_post_id: "1917653265329594372"

 **1/** @onatt0

-@NOTimothyLottes simply brilliant!
+@NOTimothyLottes
+
+simply brilliant!

 ## Related

@@ -27,17 +27,23 @@ in_reply_to: ""

 **1/** @NOTimothyLottes

-@onatt0 [3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding "complexity", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)
+@onatt0
+
+[3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding "complexity", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)

 Branches: [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-imo-code-compilation-is-inherently-sequential]]

 **2/** @NOTimothyLottes

-@onatt0 [4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.
+@onatt0
+
+[4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.

 **3/** @NOTimothyLottes

-@onatt0 [5] Can do this instead,
+@onatt0
+
+[5] Can do this instead,
 a. Track a "top" register (number)
 b. Use symbols to override top register
 c. Have push (store) just advance top to next reg (in circular queue)
@@ -45,20 +51,28 @@ Gets to easy unnamed arguments

 **4/** @NOTimothyLottes

-@onatt0 [6] You mentioned VK is most "form filling" which I think is an accurate description. For most "C" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...
+@onatt0
+
+[6] You mentioned VK is most "form filling" which I think is an accurate description. For most "C" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...

 **5/** @NOTimothyLottes

-@onatt0 [7] They key concept here is that "common" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.
+@onatt0
+
+[7] They key concept here is that "common" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.

 **6/** @NOTimothyLottes

-@onatt0 [8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.
+@onatt0
+
+[8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.

 Branches: [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-holy-truthnuke-and-people-think-c-is-the-optimal]]

 **7/** @NOTimothyLottes

-@onatt0 [9] Could just pre-layout call arguments in order of usage, leverage data compression at init-time to unpack into memory before run-time. No more code to shuffle arguments, or set registers to immediates, etc. Just a common (cached) pre-call to consume args from the "tape"
+@onatt0
+
+[9] Could just pre-layout call arguments in order of usage, leverage data compression at init-time to unpack into memory before run-time. No more code to shuffle arguments, or set registers to immediates, etc. Just a common (cached) pre-call to consume args from the "tape"

 Branches: [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-simply-brilliant]]
@@ -28,28 +28,40 @@ parent_post_id: "1917613300902146419"

 **1/** @NOTimothyLottes

-@onatt0 Related thoughts/
+@onatt0
+
+Related thoughts/
 [0] Having a low upper bound on the maximum complexity allowed in a program enables so much simplification. One can always move complexity into data, while keeping tight codebases.

 **2/** @NOTimothyLottes

-@onatt0 [1] Seems like you group symbols into pages where each page can have a string (shared with all symbols in the page), which when pared with limited fixed maximum symbol string size, is an elegant way of effectively supporting larger naming [I'll probably steal that idea next time]
+@onatt0
+
+[1] Seems like you group symbols into pages where each page can have a string (shared with all symbols in the page), which when pared with limited fixed maximum symbol string size, is an elegant way of effectively supporting larger naming [I'll probably steal that idea next time]

 **3/** @NOTimothyLottes

-@onatt0 [2] I'm also a big fan of how you used 16:9 aspect to auto render all the debug info, symbol tables, disassembly, etc, alongside the source. I think many people are probably lost in the speed at which you can manipulate and test ideas while working on the source
+@onatt0
+
+[2] I'm also a big fan of how you used 16:9 aspect to auto render all the debug info, symbol tables, disassembly, etc, alongside the source. I think many people are probably lost in the speed at which you can manipulate and test ideas while working on the source

 **4/** @NOTimothyLottes

-@onatt0 [3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding "complexity", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)
+@onatt0
+
+[3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding "complexity", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)

 **5/** @NOTimothyLottes

-@onatt0 [4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.
+@onatt0
+
+[4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.

 **6/** @NOTimothyLottes

-@onatt0 [5] Can do this instead,
+@onatt0
+
+[5] Can do this instead,
 a. Track a "top" register (number)
 b. Use symbols to override top register
 c. Have push (store) just advance top to next reg (in circular queue)
@@ -57,15 +69,21 @@ Gets to easy unnamed arguments

 **7/** @NOTimothyLottes

-@onatt0 [6] You mentioned VK is most "form filling" which I think is an accurate description. For most "C" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...
+@onatt0
+
+[6] You mentioned VK is most "form filling" which I think is an accurate description. For most "C" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...

 **8/** @NOTimothyLottes

-@onatt0 [7] They key concept here is that "common" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.
+@onatt0
+
+[7] They key concept here is that "common" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.

 **9/** @NOTimothyLottes

-@onatt0 [8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.
+@onatt0
+
+[8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.

 ## Related

@@ -27,4 +27,6 @@ in_reply_to: "1917653631651729876"

 **1/** @NOTimothyLottes

-@onatt0 I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.
+@onatt0
+
+I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.
@@ -28,7 +28,9 @@ parent_post_id: "1948009807161721332"

 **1/** @Karyuutensei

-@NOTimothyLottes Where does the restart number come from? I assume this is how many times you exited the code and started again automatically using your batch script?
+@NOTimothyLottes
+
+Where does the restart number come from? I assume this is how many times you exited the code and started again automatically using your batch script?

 **2/**