Apple (PowerVR) TBDR GPU-architecture speculation thread

Unrelated question incoming ...

Is there a reason why you need to specify the texture type including it's dimension and MSAA state when using argument buffers in Metal ?

 

That's news to me. Where did you see that?

Multisampled textures do have a different data type from regular textures, I would speculate because their layout is hardware-dependent. Same for depth textures. But that's about it?

 

Yes, according to https://developer.apple.com/documentation/metal/buffers/about_argument_buffers that doesn't seem to be the case. Could you clarify, Lurkmass?

 

Before using the setTexture method, you create an MTLTexture object to encode one of it's parameters. MTLTexture objects can be created with MTLTextureDescriptor but you need to specify the variable MTLTextureType upfront for this, am I correct ? When encoding textures to argument buffers is Metal API somehow relying on this information ? People are actually trying to work around this limitation with Metal ...

 

Well, duh, if you want to bind (encode) a resource, you have to create the resource first. And to create a resource, you need to know it's size and type. I don't understand why you would call it a limitation, sounds to me like a logical way to design a binding API? Is there any API out there that would allows you to bind a resource that doesn't exist yet?

I don't know the context of the issue you have linked, so I can't really comment on the problems they are having. Sounds to me like this is about mapping binding descriptor semantics between SPIR-V and Metal shading language.

 

On D3D12, the "texture type" can be unknown and I don't imagine that Vulkan has this limitation as well ?

 

Forgive my confusion, but how can you create a texture with an "unknown" type? What does it even mean?

Edit: I looked up DXGI_FORMAT_UNKNOWN. It appears to be just a badly chosen name for something like "choose a default format for me". It still chooses a concrete format according to a documentation I have seen.

 

On D3D12, we specify the layout of our root argument or more commonly known as the root signature and we don't have to provide information about our texture type to this root signature when binding our SRVs.

On Metal, we can create our argument buffer via MTLArgumentDescriptor. Not only do we need to provide information about the texture type to the MTLTexture objects but you have to do this as well for MTLArgumentDescriptor which I believe explains the work around that I showed earlier.

 

Ah, now I understand what you mean. Yes, Metal argument buffers are typed aggregate objects and require more precise type declaration of their components. Vulkan/DX12 use weaker type bindings, possibly to support a wider hardware range and more flexible descriptor table juggling. There is indeed a major design difference here. I can certainly see that it can create a challenge for automated tools that map from one binding style to another one.

It would be interesting to know the tradeoffs for both design approaches. E.g. can Apple achieve a more compact descriptor table encoding since they have less type erasure? What about binding validation etc.?

 

The Apple GPU and the Impossible Bug
13 May 2022
https://rosenzweig.io/blog/asahi-gpu-part-5.html
And related, this excellent Twitter thread:


And a good comment on the problem:

 

"32 MB TLB" is seriously wrong terminology.

Each TLB entry takes something like 8 bytes, so 32 MB TLB would have about 4 million entries.

With 16 kiB page size, those 4 million entries would mean TLB that can hold the address translation for 64 gigabytes of memory. Which is insanely lot.


So, they probably mean a TLB which can hold only 2048 entries (assuming 16 kiB page size), not TLB whose size is 32 MB.



And the "good comment" does not even understand the difference between CPU and GPU, uses term "CPU" for a GPU.

So, there is quite bad signal-to-noise ratio in that twitter thread.

 

That thread and the TLB topic is complete nonsensical idiotic horseshit. The CPUs (each of them) have 3072pages/48MB of coverage which fully covers the M1 Max SLC optimally. The matter on the GPU side is completely irrelevant and we don't even know how large the structures are there.