Source
- URL: https://x.com/ISzlachtycz/status/2001201742650716164
- Author: Ihor_Szlachtycz 🇺🇦 (@ISzlachtycz)
- Posted: 2025-12-17 08:04:10
Branch
1/ @ISzlachtycz
@SebAaltonen
This was a great post! I agree with almost everything you wrote. One thing that really frustrates me about the industry is how everyone has to write their own basic debugging features, most of which suck. 1/n
2/ @ISzlachtycz
@SebAaltonen
As a starter, DX13 needs shader printfs. Ideally, you could choose a target memory address to write to, or use an exposed default backing buffer created by the driver that persists even after device reset. 2/n
3/ @ISzlachtycz
@SebAaltonen
I believe that in DX12 you can allocate pages such that writing to a GPU buffer automatically writes to a file on disk. This is essential for any real logging framework. Breadcrumbs in my mind arent enough 3/n
4/ @ISzlachtycz
@SebAaltonen
It would also be nice to finally have some level of debugger support, even if it requires having a second gpu to avoid TDR issues. This ties in with forward progress guarantees, but ill start with debugging. For me, there are 3 classes of gpu problems we want to debug: 4/n
5/ @ISzlachtycz
@SebAaltonen
- Single thread debugging: we mainly care about debugging the logic of a single thread thats not interacting in a direct way with other threads. This i think covers 80% of debugging needs. 5/n
6/ @ISzlachtycz
@SebAaltonen
- thread group level sync problems: this is for problems were your shader writes to lds or does some wave ops. In this case, you need to simulate or run a whole thread group and you want to provide the user with its state to understand how its syncing/executing. 6/n
7/ @ISzlachtycz
@SebAaltonen
- Gpu wide sync problems: this is for problems where youre using global atomics to sync across all or many thread groups. In this case, you need your entire workload frozen, in order to debug correctly. This can cause nasty TDR/freezing issues but is not very common a problem7/n
8/ @ISzlachtycz
@SebAaltonen
For 1 and 2, you can pin those workloads onto the gpu, and as long as you have WGP/CU level forward progress guarantees, this wont hang your system and other processes can keep executing and finishing work. 8/n
9/ @ISzlachtycz
@SebAaltonen
For 3, you would need something like on CPUs where waves/warps can be saved to memory, and restored later when you step or F5. I dont think anyone supports that now, so youd probably need a second gpu for that kind of workload. 9/n
10/ @ISzlachtycz
@SebAaltonen
Right now, writing a spin lock is undefined behavior in hlsl. With forward progress, thats not a problem, and you can even add a intrinsic to sleep the wave in a lock, to let other waves do work. 10/n
11/ @ISzlachtycz
@SebAaltonen
With proper debugger support, you can traps for asserts that arent weird hacks but just part of the api and detected correctly by debuggers. 11/n
12/ @ISzlachtycz
@SebAaltonen
For 3), if we have proper logging in the apis by default (or atleast supported on a lang level), that can already give you traces to debug if youre on a single gpu setup, which at least gives you some feedback. 12/n
13/ @ISzlachtycz
@SebAaltonen
Its just crucial these buffers exist after the gpu TDRs in whatever way, so you dont lose all the data. End of rant 13/13. Again, great post, was a pleasent read :)
14/ @SebAaltonen
@ISzlachtycz
Yeah, debugging should indeed be improved. Hopefully somebody else has the time and energy to write a blog post about that topic. The shader framework also needs a big discussion.