Post by @GDCPresoReviews@mastodon.gamedev.place

@GDCPresoReviews@mastodon.gamedev.place

2026-04-23 06:27 UTC

- Their feedback about barriers was that their performance characteristics on different GPUs was *wildly* different. It was difficult to make the barriers correct, but it was *really* difficult to find a sequence of barriers that was semi-optimal on all devices. They went so far as to say essentially the only way to do this well would be to test on every GPU, and then flat out said that doing so would be completely impractical for their company. 4/10

Replies (2)

@GDCPresoReviews@mastodon.gamedev.place 2026-04-23 06:30

- Regarding memory management and residency, they made the point that doing this on PC is way harder than doing this on console. They point they made was that D3D11 drivers were tuned for Windows's memory manager over many years, but D3D12 drivers can't really be tuned for every individual app's memory manager, now that each app is doing its own memory management. This is a place they said their company hasn't yet (as of 2017) gotten to parity with D3D11. 5/10

Open ##2698064
@GDCPresoReviews@mastodon.gamedev.place 2026-04-23 17:12

Another interesting thing they said about barriers I forgot to mention: if you’re recording command lists in parallel, but executing them serially, it’s difficult to issue correct barriers because you don’t know at recording time what state a resource will be in. They tried the approach where you add tiny fixup command lists between your real command lists, and found it really complicated to implement. And they tried not allowing threads to issue *any* barriers, but it wasn’t flexible enough.

Open ##2698070