search for: amx

Hi, Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm consisting of two components: a set of 2-dimensional registers (tiles) representing sub-arrays from a larger 2-dimensional memory image, and accelerators able to operate on tiles. Capability of Intel AMX implementation is enumerated by palettes. Two palettes are suppo...

Hi, Several months ago, we have some discussion for Intel AMX programming model in llvm-dev. H.J. post the AMX ABI at [1], and I sent the design for the programming model at [2]. Thank Hal, Philip for the time to review the design and provide good ideas to improve the design. After that I implemented the patch [4] and it is reviewed in LLVM community. The pat...

[Yuanke] AMX register is special. It needs to be configured before use and the config instruction is expensive. To avoid unnecessary tile configure, we collect the tile shape information as much as possible and combine them into one ldtilecfg instruction. The ldtilecfg instruction should dominate any AMX instru...

The AMX registers are complicated. The single configuration register (which is mostly used implicitly, similar to MXCSR for floating point) controls the shape of all the tile registers, and if you change the tile configuration every single tile register is cleared. In practice, if we have to change the the...

...ust 15, 2020 11:29 AM To: Luo, Yuanke <yuanke.luo at intel.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Kaylor, Andrew <andrew.kaylor at intel.com>; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. I find your answer unconvincing. I'm not going to debate it as I don't wish to take the time to build the appropriate context, but my initial response is skepticism. Philip On 8/14/20 4:49 PM, Luo, Yuanke wrote: [Yuanke] AMX register is special. It needs to...

...ust 14, 2020 11:27 PM To: Luo, Yuanke <yuanke.luo at intel.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Kaylor, Andrew <andrew.kaylor at intel.com>; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. On 8/14/20 8:27 AM, Luo, Yuanke via llvm-dev wrote: Hi, Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm consisting of two components: a set of 2-dimensional registers (tiles) representing sub-arrays from a larger 2-dimensional memory image...

...kaylor at intel.com>; Philip Reames <listmail at philipreames.com>; Luo, Yuanke <yuanke.luo at intel.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. Hi, Andy, I don't quite understand everything that's going on here. Could we model this as: 1. Define a collection of register classes, one for 2x4 tiles, one for 4x2 tiles, etc. each populated with a set of tile registers. Registers can have aliasing rela...

...at intel.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. On 8/19/20 2:21 AM, Luo, Yuanke wrote: Hi Hal, There is 3 aspect to be solved. 1. The HW support max shape 16x16, so there are many register classes from 1x1 to 16x16. We need 256 register classes. 2. We want to support variable shape, so compiler don...

...at intel.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. On 8/19/20 5:34 AM, Luo, Yuanke wrote: There is no problem to have 256 register classes. Just a lot of register classes to me. We don't assume the shape of each physical register be 16x16, it is defined by user. For variable shape, I mean the shape is known in r...

...kaylor at intel.com>; Luo, Yuanke <yuanke.luo at intel.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. On 8/19/20 10:24 AM, Kaylor, Andrew wrote: > When the tile shape is unknown at compile time, how do you plan to do the register allocation of the tiles? My question is: do you do the allocation for this case in the same way as you would if you knew the size was...

...raig should have a look and approve before landing, as this is a major change in the x86 back-end. cheers, --renato On Thu, 19 Nov 2020 at 02:29, Luo, Yuanke via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > Several months ago, we have some discussion for Intel AMX programming > model in llvm-dev. H.J. post the AMX ABI at [1], and I sent the design for > the programming model at [2]. Thank Hal, Philip for the time to review the > design and provide good ideas to improve the design. After that I > implemented the patch [4] and it is reviewed in LLV...

Hi Hal, The proposal is attractive to me, but there is something I still can't figure out. Let's take below MIR as an example. We assume we have 256 register classes (vtile1x1, vtile1x2, ..., tile16x16). 1. After instruction selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as register class. Let's assume %13 is constant 3, %10 is constant 4 and %14 is variable. %1:vtile = PTILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, %18:gr64_nosp, 0,...

...s comes down to what you mean by "avoid a spill." We still might spill, and I assume that the infrastructure always needs to deal with that. We should continue to do instruction scheduling in order to minimize register pressure. Once we assign the right virtual register classes to the AMX instructions, shouldn't this automatically happen? If we do spill, since none of the original live ranges cross the ldtilecfg, then there shouldn't be any fundamental issue with using a regular load/store spill implementation. I'm definitely not an expert in this instruction set, so...

..., Craig > <craig.topper at intel.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; > Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; > florian_hahn at apple.com; Lu, Hongjiu <hongjiu.lu at intel.com> > *Subject:* RE: [llvm-dev] Intel AMX programming model discussion. > > Hi Hal, > > The proposal is attractive to me, but there is something I still can’t > figure out. Let’s take below MIR as an example. We assume we have 256 > register classes (vtile1x1, vtile1x2, …, tile16x16). > > 1.After instruction selec...

...t; If there is no easy way to take the advantage of current RA > infrastructure, there are some pros to have a separate RA for tile > register. > > 1.We can limit the risk to break RA for general register on each arch. > If there are some bugs on tile RA, only application that use AMX is > affected. > That's true. But I also worry about that. Any time you need to write non-trivial code that will be used relatively rarely, it's likely to have bugs that take a long time to show up. If you can plug into the generic infrastructure, you benefit from the fact that i...

...el at anl.gov>; Topper, Craig <craig.topper at intel.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: RE: [llvm-dev] Intel AMX programming model discussion. Hi Hal, Generally, your proposal to adapt tile RA to Greedy RA looks good to me. Thank you! I plan to do some prototype for the proposal. Since there is 3 RA in LLVM infrastructure, we need 3 schemes to adapt tile RA to each existing RA. Do you like to finalize the 3...

We're a dealer in Europe selling commercial phone & building management systems, some residential too. All the new office buildings have an EIB bus to manage the lights, clima, security access, etc. The big companies also have Crestron or AMX automation and media servers for the boardroom. Asterisk is an awesome phone solution, but if we could offer a solution that tied it all together it would be the first product of its kind. My colleague has been talking about another Linux-based open source project, plutohome.org, which is geared...

...on 8/4/05, peter webier wrote: >We're a dealer in Europe selling commercial phone & >building management systems, some residential too. >All the new office buildings have an EIB bus to manage >the lights, clima, security access, etc. The big >companies also have Crestron or AMX automation and >media servers for the boardroom. Asterisk is an >awesome phone solution, but if we could offer a >solution that tied it all together it would be the >first product of its kind. My colleague has been >talking about another Linux-based open source project, >plutoho...

...lid) and CDR(src). Could you tell me how to set the Callerid to cdr from an Originate call? I use Originate directly in the dialplan not AMI, so i can't set the callerid property like AMI use OriginateAction. my dialplan is : [test] exten => 123,1,NoCDR() exten => 123,n(me),MeetMe(123,AMX,123) exten => 0,1,Read(DEST,dial,,i) exten => 0,n,ResetCDR() exten => 0,n,Originate(SIP/${DEST},exten,test,s,1) exten => 0,n,Goto(123,me) exten => s,1,MeetMe(123,M,123) -- Thanks & Regards Sucan

* Premachandra Mallappa: > [AMD Public Use] > > Hi Floarian, > >> I'm including a proposal for the levels below. I use single letters for them, but I expect that the concrete implementation of this proposal will use >> names like “x86-100”, “x86-101”, like in the glibc patch referenced above. (But we can discuss other approaches.) > > Personally I am not a big