1912475720103649326, 1905523331496828964
This commit is contained in:
1 parent
b9eb0f3657
commit
c1aed52bd3
9 files changed
+448
No files matched your search
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "@NOTimothyLottes Could a shader compiler not do this? i.e."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/BoganBits/status/1912556384572653833"
|
||||
author: "0xbogan"
|
||||
handle: BoganBits
|
||||
post_id: "1912556384572653833"
|
||||
date: 2025-04-16
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes Could a shader compiler not do this? i.e."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1912477061467304351"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/BoganBits/status/1912556384572653833
|
||||
- Author: 0xbogan (@BoganBits)
|
||||
- Posted: 2025-04-16 17:19:10
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@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/**
|
||||
|
||||
@BoganBits This is something to be done at the dispatch level, not something a compiler knows about
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping]]
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "@NOTimothyLottes I would be interested to see a concrete example of this"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/BoganBits/status/1912555483317313711"
|
||||
author: "0xbogan"
|
||||
handle: BoganBits
|
||||
post_id: "1912555483317313711"
|
||||
date: 2025-04-16
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes I would be interested to see a concrete example of this"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1912477061467304351"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/BoganBits/status/1912555483317313711
|
||||
- Author: 0xbogan (@BoganBits)
|
||||
- Posted: 2025-04-16 17:15:35
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@NOTimothyLottes I would be interested to see a concrete example of this
|
||||
ideally with a benchmark to show the improvement
|
||||
|
||||
**2/**
|
||||
|
||||
@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
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping]]
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "@NOTimothyLottes branching, cache locality, and memory handling are key 🔥"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/DjMolehill/status/1912507659494035701"
|
||||
author: "DJ Molehill"
|
||||
handle: DjMolehill
|
||||
post_id: "1912507659494035701"
|
||||
date: 2025-04-16
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes branching, cache locality, and memory handling are key 🔥"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1912484261321392231"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/DjMolehill/status/1912507659494035701
|
||||
- Author: DJ Molehill (@DjMolehill)
|
||||
- Posted: 2025-04-16 14:05:33
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@NOTimothyLottes branching, cache locality, and memory handling are key 🔥
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping]]
|
||||
+87
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: "@NOTimothyLottes I'd add:"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/JBrooksBSI/status/1912487286190797257"
|
||||
author: "John Brooks"
|
||||
handle: JBrooksBSI
|
||||
post_id: "1912487286190797257"
|
||||
date: 2025-04-16
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes I'd add:"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1912483968563269946"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/JBrooksBSI/status/1912487286190797257
|
||||
- Author: John Brooks (@JBrooksBSI)
|
||||
- Posted: 2025-04-16 12:44:35
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@NOTimothyLottes I'd add:
|
||||
|
||||
Standardized, documented ISA that enables compatibility across multiple GPU generations (& max 256 VGPRs).
|
||||
|
||||
WGP (WorkGroup Processor) mode which doubles the # of SIMD units executing a single threadgroup, halving latency for bottleneck operations.
|
||||
|
||||
**2/**
|
||||
|
||||
@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/**
|
||||
|
||||
@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/**
|
||||
|
||||
@JBrooksBSI Yeah so it's more the wave32 that I don't like
|
||||
|
||||
**5/**
|
||||
|
||||
@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/**
|
||||
|
||||
@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
|
||||
4) Cross-lane ops only support 32 lanes
|
||||
|
||||
I spot-unroll 2x-4x for more intra-wave parallelism as needed.
|
||||
|
||||
**7/**
|
||||
|
||||
@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
|
||||
4) I use DPP16 at most (no dynamic shuffle)
|
||||
|
||||
**8/**
|
||||
|
||||
@NOTimothyLottes Wow, that is wildly different from what I do.
|
||||
|
||||
Why is high occupancy slower? (VGPR pressure? Cache pressure?)
|
||||
|
||||
Why not use LDS? I design my algorithms from the ground up around LDS.
|
||||
|
||||
K$ is rarely used for me as the focus is on SIMD32 vectors & LDS.
|
||||
|
||||
I shuffle to keep lanes full.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping]]
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: "__/ CS OPTIMIZATION BRAIN DUMPING \\__"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1912475720103649326"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1912475720103649326"
|
||||
date: 2025-04-16
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "__/ CS OPTIMIZATION BRAIN DUMPING \\__"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1912475720103649326
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-04-16 11:58:38
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
__/ CS OPTIMIZATION BRAIN DUMPING \__
|
||||
(1.) Sometimes branching can disrupt otherwise regular execution flow leading to a performance regression,
|
||||
while it might be counter intuitive to always do more work, it can sometimes be faster too ->
|
||||
|
||||
**2/**
|
||||
|
||||
WHY> Branching can cause: I$ misses, branch delays, wave switches that kill operand cache, poor register allocation, extra VALU overheads on the rejoin to move VGPRs, and most importantly poor VMEM behavior (not able to hoist out a speculative load earlier)
|
||||
|
||||
**3/**
|
||||
|
||||
(2.) Time a shader in isolation, tend to see 3 regions of execution: {cold-start, warm-cache, drain} regions.
|
||||
Early waves are missing through {I$,K$,L0$}, warm-cache waves have lower runtime.
|
||||
|
||||
For this reason it is very important to pipeline (overlap) workloads.
|
||||
|
||||
**4/**
|
||||
|
||||
Serially dependent workloads should be broken up spatially and pipelined!
|
||||
|
||||
I've never seen a dev do this correctly (look at their serially dependent post passes)! Split those into a few independent pieces.
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-i-would-be-interested-to-see-a-concrete-example]], [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-could-a-shader-compiler-not-do-this-i-e-detect]]
|
||||
|
||||
**5/**
|
||||
|
||||
(3.) If a shader is only going to run a small number of waves on say one CU (like a material used on a few pixels) then budget bandwidth for it's full {shader and constants} (which might be more costly than the textures themselves).
|
||||
|
||||
**6/**
|
||||
|
||||
(4.) Back to {cold,warm,drain} -> for small workloads or large 'cold/drain-region' workloads, it is better to force that onto one CU and loop through work (semi or full) persistent waves, to ensure high cache locality and reuse.
|
||||
|
||||
**7/**
|
||||
|
||||
... Note, might want to use large CU filling workgroups, because single-wave workgroups might get tossed on different low-level caches.
|
||||
|
||||
**8/**
|
||||
|
||||
(5.) For what should be VALU bound stuff, usually the problem on AMD is locally clustered VMEM caused by oldest first scheduling, causing memory bubbles. What you really want is steady VMEM keeping memory working well in parallel with execution ...
|
||||
|
||||
**9/**
|
||||
|
||||
... This can be very hard to fix. Sometimes you need to use more VALU to decode better compressed data to go faster (counter intuitive), or even reduce the waves running in parallel (for better cache/wave ratio) [also counter intuitive] ...
|
||||
|
||||
**10/**
|
||||
|
||||
There are shader source level transforms which can help too. Meaning you might see a difference batching say by groups of 2x2 (part kernel) instead of say the full kernel size. Yes sometimes the shader compiler will radically re-order, other times not (depends on VGPR pressure)
|
||||
|
||||
**11/**
|
||||
|
||||
(6.) The two most important things AMD ever did IMO to their architecture
|
||||
(a.) Packed 16-bit (with double rate)
|
||||
(b.) Bumping up VGPR capacity/wave (64 to 96 with good occupancy)
|
||||
...
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-JBrooksBSI-id-add-standardized-documented-isa-that-enables]]
|
||||
|
||||
**12/**
|
||||
|
||||
... The reasons being that it becomes possible to reduce round trips through memory by pass merging and other techniques -> resulting in shaders with massive state fitting in VGPRs without spilling
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-DjMolehill-branching-cache-locality-and-memory-handling-are]]
|
||||
@@ -36,6 +36,7 @@ tags:
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-16-then-there-are-rough-edges-to-texel-buffer]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-21-not-sure-if-this-is-the-end-of-this-story-yet-but]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-06-29-many-of-my-forth-like-languages-worked-via-nested]]
|
||||
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
---
|
||||
title: "@SebAaltonen Any tips or existing solutions on achieving something similar in Unity? (in terms of indoor lighting)"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/VoxelBoy/status/1905551799790006590"
|
||||
author: "Yilmaz Kiymaz"
|
||||
handle: VoxelBoy
|
||||
post_id: "1905551799790006590"
|
||||
date: 2025-03-28
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- SebAaltonen
|
||||
description: "@SebAaltonen Any tips or existing solutions on achieving something similar in Unity? (in terms of indoor lighting)"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1905523331496828964"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/VoxelBoy/status/1905551799790006590
|
||||
- Author: Yilmaz Kiymaz (@VoxelBoy)
|
||||
- Posted: 2025-03-28 09:25:27
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@SebAaltonen Any tips or existing solutions on achieving something similar in Unity? (in terms of indoor lighting)
|
||||
|
||||
**2/**
|
||||
|
||||
@VoxelBoy @SebAaltonen In Unity I do it this way: Custom EnvProbe component, capture gbuffer albedo normal and depth into cubemap on load. Pick 1 probe per frame and relight similar to deferred lighting using current sun/sky etc. Convolve to SH for diffuse and GGX for spec. Combine during deferred pass
|
||||
|
||||
**3/**
|
||||
|
||||
@VoxelBoy @SebAaltonen This is a custom pipeline though. You'll need a decent amount of graphics code/shaders to get it working, will be very hard to retrofit into HDRP, might be feasible in URP/BiRP. I'm still working on it, may switch to octmaps instead of cubemaps. Unity is still very behind with GI
|
||||
|
||||
**4/**
|
||||
|
||||
@BenSimsTech @SebAaltonen Also, with your custom render pipeline, how easy would you say it is to exceed URP performance if what’s being used are the most basic features such as Lit shader + lightmaps? Is there a lot of cruft in URP that causes overhead in your opinion?
|
||||
|
||||
**5/**
|
||||
|
||||
@VoxelBoy @SebAaltonen URP is reasonably lightweight, depends what you're targeting though. For low-end mobile/mobile VR there's a few uneccessary copies/blits etc for things like color grading, depth reads, MSAA resolves etc. Lights are only culled on per-object basis which can waste performance too.
|
||||
|
||||
**6/**
|
||||
|
||||
@BenSimsTech @VoxelBoy @SebAaltonen I don’t think msaa is worth it on TBDR. Too much bandwidth shuffling tiles on/off. And avoiding swapping out say depth is tough.
|
||||
|
||||
**7/**
|
||||
|
||||
@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen MSAA+tiler makes sense if no post, assuming one does inline 4 sample tonemap before box summation (HW resolve). Have to super sample alpha test and set coverage mask, and super-sample depth for soft particle blend. Neither should require depth export if HW is good
|
||||
|
||||
**8/**
|
||||
|
||||
@NOTimothyLottes @BenSimsTech @VoxelBoy @SebAaltonen Gpu occlusion needs hierZ. Just not worth it IMHO.
|
||||
|
||||
**9/**
|
||||
|
||||
@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen Good HW in theory with wave ops on a full-screen triangle could read the MSAA depth and do an inline down-sample for the wave tile without ever needing to export MSAA depth, hierZ done with last frame's reduced depth and speculation should work for HZB occlusion
|
||||
|
||||
**10/**
|
||||
|
||||
@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen On a tiler you don't do mid-frame readback feeding any kind of geometry because the tiler geo passes are too latent (do all VS for the view for tile chunking, then PS)
|
||||
|
||||
**11/**
|
||||
|
||||
@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen The MSAA alternative I was pushing for at Unity for "general purpose" deferred g-buffer stuff was 1:2x2 nearest scaling mixed with 8x area STP (scaling-TAA), and hopefully eventually CS based index culling (to keep triangle, and thus chucker DRAM round trip bandwidth low)
|
||||
|
||||
**12/**
|
||||
|
||||
@NOTimothyLottes @BenSimsTech @VoxelBoy @SebAaltonen Still a lot of limitations on depth/stencil and color msaa resolves and iOS. Hw only has it all around A13. Nice sample shaders for tonemap prior to resolve. Still think TAA is the most flexible/affordable. Plus msaa lowers tile size from 32x32@1x to 16x16@4x.
|
||||
|
||||
**13/**
|
||||
|
||||
@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen MSAA/TAA doesn't change the problem with mid-frame CPU read back. Id still probably go with a mix of vintage precomputed clustered visibility (ratchet and clank style) and model LOD for the static geo of a tri based mobile engine
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look]]
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: "Indoor scenes in HypeHype are starting to look acceptable."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/SebAaltonen/status/1905523331496828964"
|
||||
author: "Sebastian Aaltonen"
|
||||
handle: SebAaltonen
|
||||
post_id: "1905523331496828964"
|
||||
date: 2025-03-28
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- SebAaltonen
|
||||
description: "Indoor scenes in HypeHype are starting to look acceptable."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/SebAaltonen/status/1905523331496828964
|
||||
- Author: Sebastian Aaltonen (@SebAaltonen)
|
||||
- Posted: 2025-03-28 07:32:19
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
Indoor scenes in HypeHype are starting to look acceptable. This has no baked lighting. Only a single oct-map (conv.mips) for indirect specular and diffuse, masked with screen space AO (GTAO). No sunlight and no local lights (local lights are coming in a few months).
|
||||
|
||||
Game by Allu
|
||||
|
||||
<video controls src="https://video.twimg.com/ext_tw_video/1905521263075885056/pu/vid/avc1/720x1560/LEz0QMbFyKdz0Ph9.mp4?tag=12"></video>
|
||||
|
||||
Branches: [[archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/2025-03-28-VoxelBoy-any-tips-or-existing-solutions-on-achieving]]
|
||||
|
||||
**2/**
|
||||
|
||||
We just shipped textures. This game is using older "pixart" assets only, which allows you to put diffuse-only textures in sprites. The ground and walls are 3d sprites in this game. The new material system allows full PBR texture sets (diffuse, normal, roughness, metallic, AO).
|
||||
|
||||
**3/**
|
||||
|
||||
Local light system is shipping before summer. This will be a big improvement for indoor game visual quality. Direct lighting is important, especially when you can't bake lightmaps. Our local lights also have shadows. One big texture atlas caches all local light shadow maps.
|
||||
|
||||
**4/**
|
||||
|
||||
Example of a game textured with the new PBR material system:
|
||||
https://x.com/JohannesVuorine/status/1903305450969526504
|
||||
|
||||
Both games are running smoothly on dirt cheap <$99 phones with all the tech running.
|
||||
|
||||
Game by @DanielPalmiArt
|
||||
|
||||
**5/**
|
||||
|
||||
@DanielPalmiArt Old HypeHype indoor pictures before we landed screen space AO (GTAO) and oct-map indirect lighting. Old version had gradient based indirect lighting. Gradient is bad for indoors, since all wall normals face to horizon direction == same gradient color. And shadow masks sun out.
|
||||
|
||||

|
||||

|
||||

|
||||
|
||||
**6/**
|
||||
|
||||
@DanielPalmiArt Exactly one-year-old build versus the latest build. Quite a massive improvement in one year in visuals.
|
||||
|
||||
Still runs smoothly on the same devices.
|
||||
|
||||
Of course we are not happy with the current state either. It's going to look much better next year with all the new tech :)
|
||||
|
||||

|
||||

|
||||
@@ -11,3 +11,4 @@ tags:
|
||||
|
||||
- [[archive/threads/SebAaltonen/2024-04-04-this-is-how-slow-code-feels-like]]
|
||||
- [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without]]
|
||||
- [[archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look]]
|
||||
Reference in new issue
Block a user