Re: x86 AMX/ACE with >8 tiles

On 27.07.2026 18:08, Christian Ludloff wrote:
> Results
> -------
> 
> The new COLSB and ROWS fields in TILECFG have been
> added here -- in the existing 64 bytes (TMM8...15)
> and in the newly added 64 bytes (TMM16...31):
> 
>   https://www.sandpile.org/x86/tile.htm

Of course this re-sizing is wasteful for ACE's palette 2. On that page
you may actually want to note that the shown layout is only for palette 1.

> Recommendations
> ---------------
> 
> Don't assume 8 tiles. Use CPUID instead.
> 
> Don't assume TILEDATA = 8 KiB. Use CPUID.
> 
> Don't assume TILECFG = 64-byte. Use CPUID.

Using CPUID at start of a program is certainly expected. However, moving
a running program to more capable hardware (e.g. by migrating a VM it's
running in) is going to be problematic. Do the TILE_CTRL bits imply
effects on XSTATE component size (and hence on CPUID output)? I.e. can
they be used to safely perform such migration?

Talking of TILE_CTRL, does setting bit 0 imply / require also setting
bit 1? How is one to find out its MSR index?

> Don't hard-code {LD,ST}TILECFG mem ops as 64-byte.

This one is rather harder, as generally you want to be able to use
compile-time-known operands / sizes.

> Prepare for EVEX-encoded AMX, needed for 32 tiles.

I assume the extension to ACE insns is pretty natural then, as everything
that's needed can be encoded there. Remains merely the question of whether
a wider operand to LDTILECFG is really needed there. Perhaps for STTILECFG
that's unavoidable, as you won't know what's to be stored.

Jan