2 ms·

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/

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.
  - astrange 5y ago
    The modern approach to textures is to precompile them, so you can hand the data straight over. It's not as common to have to convert a linear to swizzled texture, though it can happen. Also, the Apple advice for OpenGL textures was always focused on avoiding unnecessary copies. (for instance, there's another one that could happen CPU side if your data wasn't aligned enough to get DMA'd) One reason M1 textures use less memory is the prior systems had AMD/Intel graphic switching and so you needed to keep another copy of everything in case you switched GPUs.
  - 5y ago

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.
- astrange 5y ago
  The modern approach to textures is to precompile them, so you can hand the data straight over. It's not as common to have to convert a linear to swizzled texture, though it can happen. Also, the Apple advice for OpenGL textures was always focused on avoiding unnecessary copies. (for instance, there's another one that could happen CPU side if your data wasn't aligned enough to get DMA'd) One reason M1 textures use less memory is the prior systems had AMD/Intel graphic switching and so you needed to keep another copy of everything in case you switched GPUs.
- 5y ago