3 ms·

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/lib

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.
- SigmundA 5y ago
  First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much? TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth. The M1 is just an evolution of Apples mobile designs and PowerVR before that. Mali GPU's are UMA and alway have been AFAIK https://community.arm.com/developer/tools-software/graphics/b/blog/posts/memory-management-on-embedded-graphics-processors https://community.arm.com/developer/tools-software/graphics/...
  - kllrnohj 5y ago
    > First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much? No, they don't, so no, I didn't move the goal posts at all. PBOs are a transfer object. You cannot sample from them on the GPU. The only thing you can do with PBOs is copy them to something you can use on the GPU. As such, PBOs do not let you take advantage of UMA. In fact, their primary benefit is for non-UMA in the first place. UMA systems have no issues blocking glTexImage2D until the copy to GPU memory is done, but non-UMA ones do. And non-UMA ones are what gave us PBOs. > TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth. Support that with a theory or evidence of literally any kind. There's nothing at all in TBDR's sequence of events that has any apparent benefit from UMA. Here: https://developer.arm.com/solutions/graphics-and-gaming/developer-guides/learn-the-basics/tile-based-rendering/tile-based-gpus https://developer.arm.com/solutions/graphics-and-gaming/deve... Look at that the sequence of steps. ARM doesn't even bother including a CPU in there, so which step would UMA be helping with? What UMA can do here is improve the power efficiency by reducing the cost of sending the command buffers to the GPU, but that's not going to get you a performance improvement as those command buffers are not very big. If sending data from the CPU to GPU was such a severe bottleneck then you'd see the impact of things like reducing the PCI-E bandwidth on discreet GPUs, but you don't.

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.
SigmundA 5y ago
First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much? TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth. The M1 is just an evolution of Apples mobile designs and PowerVR before that. Mali GPU's are UMA and alway have been AFAIK https://community.arm.com/developer/tools-software/graphics/b/blog/posts/memory-management-on-embedded-graphics-processors https://community.arm.com/developer/tools-software/graphics/...
- kllrnohj 5y ago
  > First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much? No, they don't, so no, I didn't move the goal posts at all. PBOs are a transfer object. You cannot sample from them on the GPU. The only thing you can do with PBOs is copy them to something you can use on the GPU. As such, PBOs do not let you take advantage of UMA. In fact, their primary benefit is for non-UMA in the first place. UMA systems have no issues blocking glTexImage2D until the copy to GPU memory is done, but non-UMA ones do. And non-UMA ones are what gave us PBOs. > TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth. Support that with a theory or evidence of literally any kind. There's nothing at all in TBDR's sequence of events that has any apparent benefit from UMA. Here: https://developer.arm.com/solutions/graphics-and-gaming/developer-guides/learn-the-basics/tile-based-rendering/tile-based-gpus https://developer.arm.com/solutions/graphics-and-gaming/deve... Look at that the sequence of steps. ARM doesn't even bother including a CPU in there, so which step would UMA be helping with? What UMA can do here is improve the power efficiency by reducing the cost of sending the command buffers to the GPU, but that's not going to get you a performance improvement as those command buffers are not very big. If sending data from the CPU to GPU was such a severe bottleneck then you'd see the impact of things like reducing the PCI-E bandwidth on discreet GPUs, but you don't.