1870329223455334599, 1870179026213515352
This commit is contained in:
ed committed
1 parent
93a01bef27
commit
1c816af61e
6 files changed
+354
No files matched your search
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@NOTimothyLottes now you're talking!"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/mcnabbd/status/1870254417368494158"
|
||||
author: "Doug McNabb"
|
||||
handle: mcnabbd
|
||||
post_id: "1870254417368494158"
|
||||
date: 2024-12-20
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes now you're talking!"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1870179026213515352"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/mcnabbd/status/1870254417368494158
|
||||
- Author: Doug McNabb (@mcnabbd)
|
||||
- Posted: 2024-12-20 23:46:15
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** **@mcnabbd** ^1870254417368494158
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
now you're talking!
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2024-12-20-raytastic-friday]]
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: "__/ Raytastic Friday \\__"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1870179026213515352"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1870179026213515352"
|
||||
date: 2024-12-20
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "__/ Raytastic Friday \\__"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1870179026213515352
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2024-12-20 18:46:40
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** **@NOTimothyLottes** ^1870179026213515352
|
||||
|
||||
__/ Raytastic Friday \__
|
||||
Thinking out of the AABB-ox ...
|
||||
Rather lets press the full on crazy button
|
||||
"You don't need to shade or render in screen space at all!"
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2024-12-20-raytastic-friday/2024-12-20-mcnabbd-now-youre-talking]]
|
||||
|
||||
**2/** **@NOTimothyLottes** ^1870179245797802441
|
||||
|
||||
Start with scaling-TAAs (ML or not)
|
||||
16 fetches to do good reprojection (seriously)
|
||||
4 in local neighborhood & matching 4 from reprojection
|
||||
+lot more to do good spatial filtering
|
||||
|
||||
With so much work, perhaps it would be better to reconstruct from a different domain?
|
||||
|
||||
**3/** **@NOTimothyLottes** ^1870179864025665854
|
||||
|
||||
How about reconstructing the player's view
|
||||
directly from the environment probe shade cache
|
||||
|
||||
Assuming it has good enough density, and shading is impulse (not integrated over probe pixel ... aka aliased, like screen space would be with infinite negative mip bias)
|
||||
|
||||
**4/** **@NOTimothyLottes** ^1870180312623305104
|
||||
|
||||
All env probes must be in one atlas for this to work!
|
||||
Note probes can have empty space (holes)
|
||||
|
||||
And if a probe only contains objects sharing the same rigid transform, one can reuse the probe without requiring re-shading even if it moves, so it really can be a cache if desired
|
||||
|
||||
**5/** **@NOTimothyLottes** ^1870180763842277576
|
||||
|
||||
Each probe pixel computes and stores projected screen position in INT16x2 (subpixel resolution of 17 steps at 4K)
|
||||
More than good enough for AA reconstruction
|
||||
|
||||
So note AA quality is thus decoupled from shading rate and frame rate
|
||||
|
||||
**6/** **@NOTimothyLottes** ^1870181116797432129
|
||||
|
||||
Each probe pixel packs 64-bit MSBs{f(z), probe pixel atlas coord}LSBs, computes projected screen position does atomicMax()
|
||||
|
||||
Do some pixel-jitter on projected screen position
|
||||
So any probe collisions get filtered out spatially as grain
|
||||
(aka no temporal filtering in reconstruction)
|
||||
|
||||
**7/** **@NOTimothyLottes** ^1870181434704498917
|
||||
|
||||
For screen reconstruction of a pixel
|
||||
Grab the neighborhood of atomic values (can be holes)
|
||||
Those point back to probes
|
||||
Grab a N sample neighborhood from the probes
|
||||
Do reconstruction
|
||||
[costs like a scaling TAA but NOT from screen-space]
|
||||
+61
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "@NOTimothyLottes I like select instructions for this purpose since all sides are guaranteed to execute."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/AgileJebrim/status/1870336609322934725"
|
||||
author: "Jebrim"
|
||||
handle: AgileJebrim
|
||||
post_id: "1870336609322934725"
|
||||
date: 2024-12-21
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes I like select instructions for this purpose since all sides are guaranteed to execute."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1870334592411922580"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/AgileJebrim/status/1870336609322934725
|
||||
- Author: Jebrim (@AgileJebrim)
|
||||
- Posted: 2024-12-21 05:12:51
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** **@AgileJebrim** ^1870336609322934725
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
I like select instructions for this purpose since all sides are guaranteed to execute. Still not sure about this whole negative indexing bit though. I may still want to just do a redundant thing like atomicAdd(0) for those other lanes to prevent leveraging undefined behavior.
|
||||
|
||||
**2/** **@NOTimothyLottes** ^1870337466630029780
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
You certainly don't want atomicAdd(adr,0), esp if the zero is dynamic generated. Because the HW has to loop through 64 requests on wave64 (say AMD's HW). You'd stall out your vector memory pipeline completely.
|
||||
|
||||
**3/** **@NOTimothyLottes** ^1870338068739207619
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
In the slim chance the out-of-bounds disable is done during the HW loop instead of before the loop (aka bad vs good HW design), there is a second workaround ...
|
||||
|
||||
**4/** **@NOTimothyLottes** ^1870338498445897775
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
You make the atomicAdd(adr,0) where adr is incrementing by 4-bytes (for a 32-bit atomic) and they all stay on the same cacheline (assuming wave32 and systems that have 128-bit cachelines like NV+AMD) ...
|
||||
|
||||
**5/** **@NOTimothyLottes** ^1870338840319398031
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
This is not as good because the atomics will be sent (take time/power), but the atomic units do all 32-bit words on one line in parallel (on good AMD/NV HW) so it won't be as bad as 32|64 atomics to the same address (which get serialized in request and execution)
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2024-12-21-how-to-unbreak-atomicadd-on-amd-pc]]
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "@NOTimothyLottes I will never ever understand how a company literally spends hundreds of millions on hardware R&D and tapeouts and then squanders half the performance with its absymal compiler."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/axelgneiting/status/1870567002127179929"
|
||||
author: "Axel Gneiting"
|
||||
handle: axelgneiting
|
||||
post_id: "1870567002127179929"
|
||||
date: 2024-12-21
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes I will never ever understand how a company literally spends hundreds of millions on hardware R&D and tapeouts and then squanders half the performance with its absymal compiler."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1870329223455334599"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/axelgneiting/status/1870567002127179929
|
||||
- Author: Axel Gneiting (@axelgneiting)
|
||||
- Posted: 2024-12-21 20:28:21
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** **@axelgneiting** ^1870567002127179929
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
I will never ever understand how a company literally spends hundreds of millions on hardware R&D and tapeouts and then squanders half the performance with its absymal compiler. This has been going on for at least a decade.
|
||||
|
||||
**2/** **@DaveAirlie** ^1870567643197149531
|
||||
|
||||
**@axelgneiting** **@NOTimothyLottes**
|
||||
|
||||
Even worse when another company writes a replacement compiler and they don't adopt it :-)
|
||||
|
||||
**3/** **@b_nieuwen** ^1870568658470355181
|
||||
|
||||
**@DaveAirlie** **@axelgneiting** **@NOTimothyLottes**
|
||||
|
||||
tbh this problem is also kinda messy. Like as a compiler introducing the subgroupElect on uniform addresses makes sense in general. Detecting all the myriad ways in which the app could be doing the same already is the hard part. I'm pretty sure we'd be missing some in ACO.
|
||||
|
||||
**4/** **@NOTimothyLottes** ^1870594133880103116
|
||||
|
||||
**@b_nieuwen** **@DaveAirlie** **@axelgneiting**
|
||||
|
||||
Having a "[preoptimized]" that one places in the source to disable these compiler workarounds for bad programmer behavior, that would be a good start.
|
||||
|
||||
**5/** **@olson_dan** ^1870719552247550362
|
||||
|
||||
**@axelgneiting** **@NOTimothyLottes**
|
||||
|
||||
I don't think this is the only case, either.
|
||||
|
||||
**6/** **@NOTimothyLottes** ^1870841084265496647
|
||||
|
||||
**@olson_dan** **@axelgneiting**
|
||||
|
||||
It isn't the worst compiler. They are just brave enough to have a public {disassembly extension and compiler+disassembly analysis tool}, paired with an audience who actually uses it.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2024-12-21-how-to-unbreak-atomicadd-on-amd-pc]]
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: "__/ How to Unbreak AtomicAdd on AMD PC \\__"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1870329223455334599"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1870329223455334599"
|
||||
date: 2024-12-21
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "__/ How to Unbreak AtomicAdd on AMD PC \\__"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1870329223455334599
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2024-12-21 04:43:30
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** **@NOTimothyLottes** ^1870329223455334599
|
||||
|
||||
__/ How to Unbreak AtomicAdd on AMD PC \__
|
||||
This thread is brought to you by @AgileJebrim who solved the problem despite not working on it!
|
||||
|
||||
Added another chapter to the AMD PC Compiler bugs section in the "Fixing the GPU" shared doc
|
||||
|
||||
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2024-12-21-how-to-unbreak-atomicadd-on-amd-pc/2024-12-21-axelgneiting-i-will-never-ever-understand-how-a-company]]
|
||||
|
||||
**2/** **@NOTimothyLottes** ^1870329811815550995
|
||||
|
||||
Related bugs and workarounds
|
||||
(1.) Use gl_LocalInvocationID.x and 1D dispatches
|
||||
Because that value is in a VGPR at dispatch
|
||||
(2.) Don't use gl_SubgroupInvocationID because that invokes 2 instructions to compute the lane
|
||||
...
|
||||
|
||||
**3/** **@NOTimothyLottes** ^1870330281162371404
|
||||
|
||||
(3.) Don't use subgroupElect() ever
|
||||
Because even at the beginning of the shader while the compiler knows all lanes are active, it won't just pick lane 0, instead it will do many instructions to figure out the lane count and which lane is first and branch!
|
||||
|
||||
|
||||
|
||||
**4/** **@NOTimothyLottes** ^1870330797107851446
|
||||
|
||||
Those are the easy ones, now lets look at what the compiler does if you know what you are doing and predicate an atomicAdd to the first lane ... you get this monstrosity!
|
||||
|
||||
|
||||
|
||||
**5/** **@NOTimothyLottes** ^1870331538526601233
|
||||
|
||||
The compiler injects it's (anti-)"perf strategy" without doing any checks if it should be used or not
|
||||
|
||||
So the question is, how to robustly work around this bad behavior?
|
||||
|
||||
**6/** **@NOTimothyLottes** ^1870332249448587503
|
||||
|
||||
Workaround seems to be to take a page from @AgileJebrim 's playbook and just stop branching. Instead of predicating the atomic to one lane, set the address of the atomic dynamically to an out of bounds value for all lanes but the first lane.
|
||||
|
||||
|
||||
|
||||
**7/** **@NOTimothyLottes** ^1870332859614953959
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
Some important points
|
||||
(a.) I don't know if this works for an SSBO, if it might not get HW bounds checking, it won't work
|
||||
(b.) This will NEVER work for general 64-bit pointers
|
||||
(c.) Effectively you need to use STORAGE_TEXEL_BUFFERs
|
||||
|
||||
**8/** **@NOTimothyLottes** ^1870333184933581014
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
This bad compiler behavior and it's associated workaround is yet another reason moving to 64-bit pointers is Dead on Arrival.
|
||||
|
||||
**9/** **@NOTimothyLottes** ^1870333747893047506
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
So for imageStores it's a no-brainer to never predicate the store, just rely on the cacheline per clock store address coalescing behavior. At a minimum it reduces all same address stores to one store, and that store is disabled by the out-of-bounds address ...
|
||||
|
||||
**10/** **@NOTimothyLottes** ^1870334100550144274
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
For atomics this relies on the HW to efficiently throw out bad address requests early before doing the same-address request replay (these are atomics), this is something I still need to profile to know for sure what HW this works well on
|
||||
|
||||
**11/** **@NOTimothyLottes** ^1870334592411922580
|
||||
|
||||
**@AgileJebrim**
|
||||
|
||||
If this is a robust workaround, it likely means I'd never do any lane predication at all in any shader moving forward. Strict wave-coherent execution.
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2024-12-21-how-to-unbreak-atomicadd-on-amd-pc/2024-12-21-AgileJebrim-i-like-select-instructions-for-this-purpose-since]]
|
||||
@@ -38,7 +38,9 @@ tags:
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-15-the-real-buffer-zoo-problem-with-vulkan-is]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-20-raytastic-friday]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-21-how-to-unbreak-atomicadd-on-amd-pc]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic]]
|
||||
|
||||
Reference in new issue
Block a user