5 ms·

From the article: "Meanwhile, unlike the CPU side of this transition to Apple Silicon, the higher-level nature of graphics programming means that Apple isn’t ne

From the article: "Meanwhile, unlike the CPU side of this transition to Apple Silicon, the higher-level nature of graphics programming means that Apple isn’t nearly as reliant on devs to immediately prepare universal applications to take advantage of Apple’s GPU. To be sure, native CPU code is still going to produce better results since a workload that’s purely GPU-limited is almost unheard of, but the fact that existing Metal (and even OpenGL) code can be run on top of Apple’s GPU today means that it immediately benefits all games and other GPU-bound workloads." https://developer.apple.com/documentation/metal/setting_resource_storage_modes/choosing_a_resource_storage_mode_in_macos https://developer.apple.com/documentation/metal/setting_reso... https://developer.apple.com/documentation/metal/synchronizing_a_managed_resource https://developer.apple.com/documentation/metal/synchronizin... "Note In a discrete memory model, synchronization speed is constrained by PCIe bandwidth. In a unified memory model, Metal may ignore synchronization calls completely because it only creates a single memory allocation for the resource. For more information about macOS memory models and managed resources, see Choosing a Resource Storage Mode in macOS." I am not trying to minimize the other engineering improvements, however I do believe there may be less credit being given to the UMA than deserved due to past lackluster UMA offerings. As I said it will be interesting to see how far Apple can scale UMA I am not sure they can catch discrete graphics but I am starting to think they are going to try.

kllrnohj 5y ago
To leverage shared memory in Metal you have to target Metal. Otherwise take for example glTexImage2D: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexImage2D.xhtml https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl... Apple can't just hang onto that void* that's passed in as the developer is free to re-use for something else after the call. It must copy, even on a UMA system. And even if it was adjusted such that glTexImage2D took ownership of the pointer instead, there'd still be an internal copy anyway to swizzle it as linear RGBA buffers are not friendly to typical GPU workloads. This is why for example per Apple's docs above when it gets to the texture section it's like "yeah just copy & use private." So even though in theory Metal's UMA exposure would be great for games that stream textures, it still isn't because you still do a copy anyway to convert it to the GPU's internal optimal layout. Similarly the benefits of UMA only help if transfering data is actually a significant part of the workload, which is not true for the vast majority of games. For things like gfxbench it may help speedup the load time, but during the benchmark loop all the big objects are only used on the GPU (like textures & models)
- SigmundA 5y ago
  I believe most of the benchmarks where Metal based in the Anand article, also PBO have been around for quiet a while in OpenGL: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/opengl_texturedata.html https://developer.apple.com/library/archive/documentation/Gr... Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. This is the same model from iOS so just about anyone doing metal will already be optimizing for it same with any other mobile development. It doesn't seem like a minor architectural difference to me: "Comparing the two GPU architectures, TBDR has the following advantages: It drastically saves on memory bandwidth because of the unified memory architecture. Blending happens in-register facilitated by tile processing. Color, depth and stencil buffers don’t need to be re-fetched." https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.html https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.ht...
  - kllrnohj 5y ago
    > I believe most of the benchmarks where Metal based in the Anand article But that doesn't tell you anything. Being Metal-based doesn't mean they were designed nor benefit from UMA. Especially since, again, Apple's own recommendation on big data (read: textures) is to copy it. > Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. Yes, but games & gfxbench don't do this which is what I keep trying to get across. There are workloads out there that will benefit from this, but the games & benchmarks that were run & being discussed aren't them. It's like claiming the sunspider results are from wifi 6 improvements. There are web experiences that will benefit from faster wifi, but sunspider ain't one of them. Things like GPGPU compute can benefit tremendously here, for example. > also PBO have been around for quiet a while in OpenGL: PBO's reduce the number of copies from 2 to 1 in some cases, not from 1 to 0. You still copy from the PBO to your texture target, but it can potentially avoid a CPU to CPU copy first. When you call glTexImage2D it doesn't necessarily do the transfer right then, it instead may copy to a different CPU buffer to later be copied to the GPU. > "Comparing the two GPU architectures, TBDR has the following advantages: > It drastically saves on memory bandwidth because of the unified memory architecture. Blending happens in-register facilitated by tile processing. Color, depth and stencil buffers don’t need to be re-fetched." > https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.ht https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.ht... Uh, that blogger seems rather confused. TBDR has nothing to do with UMA, nor is Nvidia or AMD immediate mode anymore. Heck, Mali was doing TBDR long before it was ever used on a UMA SoC.

kllrnohj 5y ago

To leverage shared memory in Metal you have to target Metal. Otherwise take for example glTexImage2D: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexImage2D.xhtml https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl... Apple can't just hang onto that void* that's passed in as the developer is free to re-use for something else after the call. It must copy, even on a UMA system. And even if it was adjusted such that glTexImage2D took ownership of the pointer instead, there'd still be an internal copy anyway to swizzle it as linear RGBA buffers are not friendly to typical GPU workloads. This is why for example per Apple's docs above when it gets to the texture section it's like "yeah just copy & use private." So even though in theory Metal's UMA exposure would be great for games that stream textures, it still isn't because you still do a copy anyway to convert it to the GPU's internal optimal layout. Similarly the benefits of UMA only help if transfering data is actually a significant part of the workload, which is not true for the vast majority of games. For things like gfxbench it may help speedup the load time, but during the benchmark loop all the big objects are only used on the GPU (like textures & models)

SigmundA 5y ago
I believe most of the benchmarks where Metal based in the Anand article, also PBO have been around for quiet a while in OpenGL: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/opengl_texturedata.html https://developer.apple.com/library/archive/documentation/Gr... Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. This is the same model from iOS so just about anyone doing metal will already be optimizing for it same with any other mobile development. It doesn't seem like a minor architectural difference to me: "Comparing the two GPU architectures, TBDR has the following advantages: It drastically saves on memory bandwidth because of the unified memory architecture. Blending happens in-register facilitated by tile processing. Color, depth and stencil buffers don’t need to be re-fetched." https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.html https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.ht...
- kllrnohj 5y ago
  > I believe most of the benchmarks where Metal based in the Anand article But that doesn't tell you anything. Being Metal-based doesn't mean they were designed nor benefit from UMA. Especially since, again, Apple's own recommendation on big data (read: textures) is to copy it. > Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. Yes, but games & gfxbench don't do this which is what I keep trying to get across. There are workloads out there that will benefit from this, but the games & benchmarks that were run & being discussed aren't them. It's like claiming the sunspider results are from wifi 6 improvements. There are web experiences that will benefit from faster wifi, but sunspider ain't one of them. Things like GPGPU compute can benefit tremendously here, for example. > also PBO have been around for quiet a while in OpenGL: PBO's reduce the number of copies from 2 to 1 in some cases, not from 1 to 0. You still copy from the PBO to your texture target, but it can potentially avoid a CPU to CPU copy first. When you call glTexImage2D it doesn't necessarily do the transfer right then, it instead may copy to a different CPU buffer to later be copied to the GPU. > "Comparing the two GPU architectures, TBDR has the following advantages: > It drastically saves on memory bandwidth because of the unified memory architecture. Blending happens in-register facilitated by tile processing. Color, depth and stencil buffers don’t need to be re-fetched." > https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.ht https://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.ht... Uh, that blogger seems rather confused. TBDR has nothing to do with UMA, nor is Nvidia or AMD immediate mode anymore. Heck, Mali was doing TBDR long before it was ever used on a UMA SoC.