[spec] Add dtype and layout arguments to ttl.block.fill

[phizalev-TT]

No description provided.

[FConstantinos]

Since this is a change in the signature of fill and it is not an optional argument, I expect all instances of fill will have to be changed throughout this document?

[brnorris03]

Yes, that's true -- and not just the document, but examples, too; I can do that in the still-open #599 -- or you @FConstantinos feel free to commit sim changes there directly (if we agree to merge the spec change first before 599 lands).

[brnorris03]

Actually, 599 is already too big, so ignore the above. We can just do the dtype addition separately in subsequent PRs. I'll have to change the compiler's fill implementation anyway since currently dtype is optional (and last).

[vtsilytskyiTT]

This feels like a language gap. value is always float and we separately pass the type to cast to.
In perfect case fill should accept various value types and rely on that type.
Do we use something like ttnn.DataType(0) as the first argument?

[brnorris03]

This feels like a language gap. value is always float and we separately pass the type to cast to. In perfect case fill should accept various value types and rely on that type. Do we use something like ttnn.DataType(0) as the first argument?

I think the problem is that there is no concise way to create a correctly-typed constant host scalar in Python. Users would have to call something like fill(val = ttnn.full([], 0.5, dtype=ttnn.bfloat16), shape=some_shape). I think that's much more awkward and less clean than a simple dtype arg, but that's just my opinion. The compiler will be able support any valid python scalar without a dtype arg eventually (so just float val and shape args) after type inference is implemented.

[FConstantinos]

Do we want to add a version row?

[FConstantinos]

re value: float no problem with that, but are we sure we won't support types with greater than 32 bit floats?

I also understand that we never deal with tensors of integers, is that accurate?

[FConstantinos]

Also, should we consider a default for dtype? (e.g float32) or do we need to make this non-optional?

[FConstantinos]

is ttnn.DataType defined anywhere?

[brnorris03]

I don't think the spec needs to define ttnn entities, that's up to the ttnn docs

[phizalev-TT]

We rely on ttnn.Tensor in the same way. It is defined by TT=NN.

[FConstantinos]

I guess an important question is, how do we know the layout of the fill (TILE_LAYOUT vs ROW_MAJOR_LAYOUT)? Perhaps we need to add more arguments that specify this? Or perhaps say that fill always produces a tiled block?

[brnorris03]

The sim supports multiple layouts, so this does seem necessary, perhaps make it an optional arg with a default TILE_LAYOUT?

[FConstantinos]

Yes, should be good

[phizalev-TT]

Added.

[brnorris03]

Also, should we consider a default for dtype? (e.g float32) or do we need to make this non-optional?

I also think optional with some reasonable default is good. I think bf16 is WAY more common though (and f32 has quite a few bugs in the llks, hardware), so I think having it be the default doesn't actually help the compiler much since that means we have to explicitly have dtype=ttnn.bf16 in most of the code.

[phizalev-TT]

re value: float no problem with that, but are we sure we won't support types with greater than 32 bit floats?

I also understand that we never deal with tensors of integers, is that accurate?

We can create integer by using corresponding dtype, which will truncate float constant. Same goes for any other type.

[phizalev-TT]

Do we want to add a version row?

This is minor change and with default dtype is fully backward compatible, so no version.