Apple (PowerVR) TBDR GPU-architecture speculation thread

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

Tags:
  1. Lurkmass

    Regular Newcomer

    Joined:
    Mar 3, 2020
    Messages:
    309
    Likes Received:
    348
    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,331
    Likes Received:
    158
    Location:
    On the path to wisdom
  4. Lurkmass

    Regular Newcomer

    Joined:
    Mar 3, 2020
    Messages:
    309
    Likes Received:
    348
    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 Newcomer

    Joined:
    Mar 3, 2020
    Messages:
    309
    Likes Received:
    348
    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 Newcomer

    Joined:
    Mar 3, 2020
    Messages:
    309
    Likes Received:
    348
    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.?
     
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...