Apple (PowerVR) TBDR GPU-architecture speculation thread

Discussion in 'Architecture and Products' started by Kaotik, Jul 7, 2020.

Tags:
  1. Lurkmass

    Regular

    Joined:
    Mar 3, 2020
    Messages:
    567
    Likes Received:
    712
    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 ?
     
  2. rikrak

    Newcomer

    Joined:
    Sep 16, 2020
    Messages:
    30
    Likes Received:
    16
    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?
     
  3. Xmas

    Xmas Porous
    Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    3,344
    Likes Received:
    176
    Location:
    On the path to wisdom
  4. Lurkmass

    Regular

    Joined:
    Mar 3, 2020
    Messages:
    567
    Likes Received:
    712
    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 ...
     
  5. rikrak

    Newcomer

    Joined:
    Sep 16, 2020
    Messages:
    30
    Likes Received:
    16
    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.
     
  6. Lurkmass

    Regular

    Joined:
    Mar 3, 2020
    Messages:
    567
    Likes Received:
    712
    On D3D12, the "texture type" can be unknown and I don't imagine that Vulkan has this limitation as well ?
     
  7. rikrak

    Newcomer

    Joined:
    Sep 16, 2020
    Messages:
    30
    Likes Received:
    16
    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.
     
  8. Lurkmass

    Regular

    Joined:
    Mar 3, 2020
    Messages:
    567
    Likes Received:
    712
    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.
     
  9. rikrak

    Newcomer

    Joined:
    Sep 16, 2020
    Messages:
    30
    Likes Received:
    16
    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.?
     
  10. xpea

    Regular

    Joined:
    Jun 4, 2013
    Messages:
    555
    Likes Received:
    797
    Location:
    EU-China
    Jensen Krage and PSman1700 like this.
  11. hkultala

    Regular

    Joined:
    May 22, 2002
    Messages:
    297
    Likes Received:
    38
    Location:
    Herwood, Tampere, Finland
    "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.
     
    #171 hkultala, May 14, 2022
    Last edited: May 14, 2022
  12. Nebuchadnezzar

    Legend

    Joined:
    Feb 10, 2002
    Messages:
    1,061
    Likes Received:
    330
    Location:
    Luxembourg
    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.
     
    Pressure and Laurent06 like this.
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...