4 ms·

What does he mean by a 32MB TLB? Certainly there isn't an actual 32MB of on-chip memory dedicated to a TLB. So does it refer to the coverable amount of virtual

What does he mean by a 32MB TLB? Certainly there isn't an actual 32MB of on-chip memory dedicated to a TLB. So does it refer to the coverable amount of virtual memory? But that can't be true either, given huge pages. All in all, very disappointing thread. Does anybody have real references to what he's talking about?

jazzyjackson 5y ago
I don't know anything about TLBs but the M1 is a system on a chip, you can get up to 64GB of RAM shared between CPU and GPU all on the same die.
- __init 5y ago
  More specifically, it's a system on a _package_. A TLB lives on the _die_, though, with one in each core.
- heavyset_go 5y ago
  TLB cache isn't the same thing as the unified memory on the M1.
kimixa 5y ago
I think it's a confusion of similar terms - there's the TLB (translation lookaside buffer) of the MMU, which is an extremely small fast buffer of recent MMU translations - there's no chance that is anywhere near 32mb. This is often designed to be hit within a single cycle, so has tighter restrictions than even the l1 caches of modern CPUs. Then there's also the GPU tile buffer (which they may also be calling a "TLB" here?) - which I think is what he's referring to here - on a TBDR system there's an advantage if it can calculate multiple passes on the image while keeping all needed info in the on-chip tile buffer (Think stuff like depth and color data when rendering a large scene), as if the intermediate results aren't actually needed (such as a partially drawn scene where more objects will be drawn on top of some of the pixels, or an intermediate output before some post-processing pass) it may never actually touch the main memory so has the ability to save a lot of bandwidth. I'm pretty sure it's the second the OP is referring to here, as if you blow past this buffer size you can hit a performance cliff, and methods to optimise it's use (such as rendering tiles of multiple passes instead of doing each pass on the full screen view separately) doesn't really make any difference to immediate renderers, so is something "new" developers need to take into account for deferred tiler architectures.
- deadalnix 5y ago
  Modern machine can do TLB and L1 lookup in parallel. Here is how it works on a traditional CPU (it is different on M1). The page size is 4kb. This means the lower 12 bits of an address is the same between logical and physical addresses. The cache line is 64 bytes. The lower 6 bits of the address are indexing within a cache line. The L1 is 8 way associative so the other 6 bits addresses 8 cache lines in the L1. This makes 64*8 cache lines of 64 bytes => 32k of L1 cache. The CPU does a lookup in TLB and a lookup in L1 in parallel, and gets 8 cache lines from the L1, which are filtered by the results in the TLB to hopefully get a hit. Now you'll note that, while most CPU have 32k of L1, the M1 has 128k, which means it needs 2 extra bits to match between physical and logical addresses to pull the same trick. And what do you know, M1 has 16k pages! What a coincidence (not!).
- msk-lywenn 5y ago
  Fourth tweet states that he does mean translation lookaside buffer. If it’s true, it’s indeed insanely big.
  - kimixa 5y ago
    I'm pretty sure that's false, as translation lookaside buffers simply cannot be of that size while hitting the performance requirements. I suspect they've seen someone refer to a TLB (Translation Lookaside Buffer) and TLB (TiLe Buffer) and conflated the two.
  - deleted 5y ago
    [deleted]
  - microtherion 5y ago
    They also refer to it as a "Transaction Lookaside Buffer", which reinforces the impression given off by the overall twitter thread that this was secondhand information relayed by somebody who has a very weak grasp of the technical details involved.
    - randyrand 5y ago
      Vadim is a smart guy but not a programmer. So you’re right he may not mean Transaction Lookaside Buffer.
ip26 5y ago
It must be the coverable amount. At 16kB pages, it would be 2048 entries, a reasonable TLB size. The CPU is said to have 3072 L2TLB entries, so that's not quite a match. Perhaps this "32MB TLB" is a GPU-only TLB; perhaps it does not support variable page sizes.
- kimixa 5y ago
  But the same limits are true on any GPU that does virtual memory - it's nothing special about that and doesn't interact really with the TBDR vs Immediate rendering the thread seems to suggest. If anything, a TBDR implementation may put less pressure on the MMU TLB, as the tile buffer contents are statically allocated based on the pipeline so may not even have a backing mapping, while on an intermediate mode renderer would have to have an intermediate buffer somewhere for stuff like the color and depth values of an ongoing render, which is likely translated through the MMU. Which is why I believe they've confused the TLB (Translation Lookaside buffer of the MMU) with the Tile Buffer of a TBDR renderer (IE the on-chip working buffer for in-tile intermediate results of shading).

jazzyjackson 5y ago

I don't know anything about TLBs but the M1 is a system on a chip, you can get up to 64GB of RAM shared between CPU and GPU all on the same die.

__init 5y ago
More specifically, it's a system on a _package_. A TLB lives on the _die_, though, with one in each core.
heavyset_go 5y ago
TLB cache isn't the same thing as the unified memory on the M1.

kimixa 5y ago

I think it's a confusion of similar terms - there's the TLB (translation lookaside buffer) of the MMU, which is an extremely small fast buffer of recent MMU translations - there's no chance that is anywhere near 32mb. This is often designed to be hit within a single cycle, so has tighter restrictions than even the l1 caches of modern CPUs. Then there's also the GPU tile buffer (which they may also be calling a "TLB" here?) - which I think is what he's referring to here - on a TBDR system there's an advantage if it can calculate multiple passes on the image while keeping all needed info in the on-chip tile buffer (Think stuff like depth and color data when rendering a large scene), as if the intermediate results aren't actually needed (such as a partially drawn scene where more objects will be drawn on top of some of the pixels, or an intermediate output before some post-processing pass) it may never actually touch the main memory so has the ability to save a lot of bandwidth. I'm pretty sure it's the second the OP is referring to here, as if you blow past this buffer size you can hit a performance cliff, and methods to optimise it's use (such as rendering tiles of multiple passes instead of doing each pass on the full screen view separately) doesn't really make any difference to immediate renderers, so is something "new" developers need to take into account for deferred tiler architectures.

deadalnix 5y ago
Modern machine can do TLB and L1 lookup in parallel. Here is how it works on a traditional CPU (it is different on M1). The page size is 4kb. This means the lower 12 bits of an address is the same between logical and physical addresses. The cache line is 64 bytes. The lower 6 bits of the address are indexing within a cache line. The L1 is 8 way associative so the other 6 bits addresses 8 cache lines in the L1. This makes 64*8 cache lines of 64 bytes => 32k of L1 cache. The CPU does a lookup in TLB and a lookup in L1 in parallel, and gets 8 cache lines from the L1, which are filtered by the results in the TLB to hopefully get a hit. Now you'll note that, while most CPU have 32k of L1, the M1 has 128k, which means it needs 2 extra bits to match between physical and logical addresses to pull the same trick. And what do you know, M1 has 16k pages! What a coincidence (not!).
msk-lywenn 5y ago
Fourth tweet states that he does mean translation lookaside buffer. If it’s true, it’s indeed insanely big.
- kimixa 5y ago
  I'm pretty sure that's false, as translation lookaside buffers simply cannot be of that size while hitting the performance requirements. I suspect they've seen someone refer to a TLB (Translation Lookaside Buffer) and TLB (TiLe Buffer) and conflated the two.
- deleted 5y ago
  [deleted]
- microtherion 5y ago
  They also refer to it as a "Transaction Lookaside Buffer", which reinforces the impression given off by the overall twitter thread that this was secondhand information relayed by somebody who has a very weak grasp of the technical details involved.
  - randyrand 5y ago
    Vadim is a smart guy but not a programmer. So you’re right he may not mean Transaction Lookaside Buffer.

ip26 5y ago

It must be the coverable amount. At 16kB pages, it would be 2048 entries, a reasonable TLB size. The CPU is said to have 3072 L2TLB entries, so that's not quite a match. Perhaps this "32MB TLB" is a GPU-only TLB; perhaps it does not support variable page sizes.

kimixa 5y ago
But the same limits are true on any GPU that does virtual memory - it's nothing special about that and doesn't interact really with the TBDR vs Immediate rendering the thread seems to suggest. If anything, a TBDR implementation may put less pressure on the MMU TLB, as the tile buffer contents are statically allocated based on the pipeline so may not even have a backing mapping, while on an intermediate mode renderer would have to have an intermediate buffer somewhere for stuff like the color and depth values of an ongoing render, which is likely translated through the MMU. Which is why I believe they've confused the TLB (Translation Lookaside buffer of the MMU) with the Tile Buffer of a TBDR renderer (IE the on-chip working buffer for in-tile intermediate results of shading).