4 ms·
This. In the announcement they stated "transparent to developers" but I really need to see some specifications, benchmarks, introspection tooling, and details.
by The-0xAlex 3y ago
This. In the announcement they stated "transparent to developers" but I really need to see some specifications, benchmarks, introspection tooling, and details. This is one of those things that sounds great in theory but is likely not quite possible to do without some compromises somewhere.
Also seems like this would have to be something "opt in" or else what stops someone from just using GL/Vulkan/Metal to allocate and lock a giant buffer every frame anyway?
I'm optimistic, but I am really eager to see the documentation.
- 1123581321 3y agoI heard a good lay explanation on the most recent Upgrade podcast (around 30:00.) The explanation was provided by an anonymous Apple employee. Dynamic caching is about setting the allocated memory per GPU thread. Historically, threads received fixed allocations. These had tradeoffs since overallocation caused performance bottlenecks and right-sized allocation underutilized the RAM. Dynamic cacheing adjusts per-thread allocations so the memory per utilized thread adds up to the max available amount more often. Developers do not need to change any code to benefit. If all that is true, it sounds like a good improvement. And it sounds plausible that Apple was the first since it would require the whole system to work in synch without introducing latency in rendering, a good use of an SoC. I’d still like to see benchmarks and understand potential failure/bottleneck scenarios.