metal release 1.0: create limits/parameters api

tenstorrent / tt-metal

:metal: TT-NN operator library, and TT-Metalium low level kernel programming model.

Apache License 2.0

396 stars 49 forks source link

metal release 1.0: create limits/parameters api #10425

Open pgkeller opened 1 month ago

pgkeller commented 1 month ago

We need a new API to query runtime/device limits:

queryable limits will be enumerated in a global enum space. the enum specifies an attribute
limit will be returned

First task is to enumerate the list of limits and their types (are all integers?) and then decide if we need more than one API. A start is:

METAL_MAX_UNIQUE_RUNTIME_ARGS
METAL_MAX_COMMON_RUNTIME_ARGS
METAL_MAX_CIRCULAR_BUFFERS
METAL_MAX_SEMAPHORES
METAL_MAX_DATA_MOVEMENT_PROCESSORS
METAL_MAX_COMPUTE_PROCESSORS
METAL_MAX_PROGRAMMABLE_CORE_TYPES (do we wnat this? eg, tensix/eth)
METAL_MAX_NOCS

There may also be limits that will require a parameter, eg, memory by core type. Todo to fully specify.

kmabeeTT commented 3 weeks ago

Hello - thanks for creating issue. From talking to Paul, was suggested I donate some API requests here.

tt-mlir compiler would like to request the/an API to export up the "Supported Data Formats" and "Supported Tile Sizes" for the device (https://github.com/tenstorrent/tt-mlir/issues/433) please. Something like (feel free to adjust):

METAL_SUPPORTED_DATA_FORMATS
METAL_SUPPORTED_TILE_SIZES (ie. 32x32, blah)

In addition, tt-mlir would like to request the following device specific params be queryable (https://github.com/tenstorrent/tt-mlir/issues/300), somehow (maybe also a list like METAL_SUPPORTED with a single value, or something else) so we can remove hardcoded values.

L1_ALIGNMENT
PCIE_ALIGNMENT
DRAM_ALIGNMENT

nsmithtt commented 3 weeks ago

We also need:

L1_UNRESERVED_BASE
ERISC_L1_UNRESERVED_BASE
DRAM_UNRESERVED_BASE

pgkeller commented 3 weeks ago

We also need:

L1_UNRESERVED_BASE

ERISC_L1_UNRESERVED_BASE

DRAM_UNRESERVED_BASE

curious: why? (note: these are all moving into the hal and will go away ~soon as consts, could still be queryable though)

nsmithtt commented 3 weeks ago

We also need:

L1_UNRESERVED_BASE

ERISC_L1_UNRESERVED_BASE

DRAM_UNRESERVED_BASE

curious: why? (note: these are all moving into the hal and will go away ~soon as consts, could still be queryable though)

We are experimenting in the compiler with autogenerated kernels and going direct to metal which means the compiler will have its own allocator for CBs & tensors. It'll need to know what address range is legal to use.