4 ms·

What about https://www.digitaltrends.com/computing/apple-dynamic-caching-explained/ https://www.digitaltrends.com/computing/apple-dynamic-cachin...?

tedunangst 3y ago
Even after reading that, I'm still uncertain how it lets more blocks/waves/whatev execute. Could really use an example with some fictitious numbers.
- reroute22 3y ago
  A pretty detailed hypothesis showed up recently: https://forums.macrumors.com/threads/3d-rendering-on-apple-silicon-cpu-gpu.2269416/page-85?post=32694869#post-32694869 https://forums.macrumors.com/threads/3d-rendering-on-apple-s...
kimixa 3y ago
Yeah, vague terms like "local memory" aren't helpful - there's lots of different memories that are local to the shader unit that are a shared resource so can affect occupancy (the LDS, register file, TBDR stuff like the tile buffer, and probably any number of other things). Which of these is it referring to? They are separate things in some architectures, but maybe not in all? There's the linked patent itself [0] - but that specifically seems to refer to using the MMU as the part that's doing this dynamic allocation and translation - but the majority of those resources above are "before" address translation, with the MMU often being more at the L2 cache level rather than embedded within the shader clusters themselves. Maybe this isn't the "normal" MMU and instead a simpler address translator specifically for those resources that has been added of for this? Or is it something like the parameter buffer (The block of memory used to store the intermediate data between the tiling & rasterization state, and the pixel shaders). That has been "dynamically allocated" in a similar way since Apple were just taking PowerVR cores directly. And then what is the cost of this re-allocation? If there's a cost to performance to allocating new pages, or (like worse) running out of spare pages, it might mean the (graphics API) user still has to be aware of their resource usage in scheduling shaders, so less of the promise of "Just throw things at the hardware and it'll do things optimally" than people might hope. [0] https://patents.google.com/patent/US20210271606A1/en https://patents.google.com/patent/US20210271606A1/en

tedunangst 3y ago

Even after reading that, I'm still uncertain how it lets more blocks/waves/whatev execute. Could really use an example with some fictitious numbers.

reroute22 3y ago
A pretty detailed hypothesis showed up recently: https://forums.macrumors.com/threads/3d-rendering-on-apple-silicon-cpu-gpu.2269416/page-85?post=32694869#post-32694869 https://forums.macrumors.com/threads/3d-rendering-on-apple-s...

kimixa 3y ago

Yeah, vague terms like "local memory" aren't helpful - there's lots of different memories that are local to the shader unit that are a shared resource so can affect occupancy (the LDS, register file, TBDR stuff like the tile buffer, and probably any number of other things). Which of these is it referring to? They are separate things in some architectures, but maybe not in all? There's the linked patent itself [0] - but that specifically seems to refer to using the MMU as the part that's doing this dynamic allocation and translation - but the majority of those resources above are "before" address translation, with the MMU often being more at the L2 cache level rather than embedded within the shader clusters themselves. Maybe this isn't the "normal" MMU and instead a simpler address translator specifically for those resources that has been added of for this? Or is it something like the parameter buffer (The block of memory used to store the intermediate data between the tiling & rasterization state, and the pixel shaders). That has been "dynamically allocated" in a similar way since Apple were just taking PowerVR cores directly. And then what is the cost of this re-allocation? If there's a cost to performance to allocating new pages, or (like worse) running out of spare pages, it might mean the (graphics API) user still has to be aware of their resource usage in scheduling shaders, so less of the promise of "Just throw things at the hardware and it'll do things optimally" than people might hope. [0] https://patents.google.com/patent/US20210271606A1/en https://patents.google.com/patent/US20210271606A1/en