search for: tile

[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 instruction that access tile register. On the other side, the ldtilecfg should post-dominated the instruction that define the tile...

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 configuration while any of the tile registers are live, performance is going to be terrible. We need to handle this case for correctness, but users of this programmin...

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't know what register class to fit tile shape as it is only known in runtime. 3. The tile configure is to configure physical tile register, so we need to allocate register and then we know the shape of each physical tile register and configure the tile register. I think your suggestion is helpful to reduce the complexity if we onl...

...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 runtime and in compile time the shape is unknown. Take below code as an example, the %row and %col are variable instead of constant. Compiler recognizes llvm.x86.tileloadd64 and deduce the shape of %0 is %row x %col. %0 = tail call <256 x i32> @llvm.x86.tileloadd64(i16 %row, i16 %col, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @buf, i64 0, i64 0), i64 32) From: Hal Finkel <hfinkel at anl.gov> Sent: Wednesday, August 19, 2020 4:58 PM To: L...

The width and height can be runtime values that we would just copy into 64 byte configuration block we pass to ldtilecfg. So the code doesn't need to be multiversioned. The user code would also use those values to update pointers in the loops they write using the tiles. If we can't determine that two tiles were defined with the same width and height we need to assume the shape is different and try to avoid...

> 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 16x16 (i.e., conservatively assume the largest size)? I think what will happen is that the regis...

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 supported: palette 0 represents the initialized state and palette 1 consists of 8 tile registers of up to...

On 8/20/20 2:47 PM, Topper, Craig wrote: > > I think I’m still missing something here. The configuration is per > tile. The multiply instructions take a MxK tile and multiply it by a > KxN tile and accumulate into an MxN tile. So the configuration needs > to know how many of each size of tile it needs to avoid a spill. > Wouldn’t the register allocator then need to know which physical tiles > have b...

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 v...

Hi Philip, Your idea make sense to me in my first thought. Thank you for the idea. I will take more time to think it over to see it can help to reduce the complexity of tile register allocation. Yuanke From: Philip Reames <listmail at philipreames.com> Sent: Saturday, August 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 <...

...ngjiu <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, and accelerators able to operate on tiles. Capability of Intel AMX implementation is enumerated by palettes. Two palettes are supported: palette 0 represents the initialized state and palette 1 consists of 8 tile registers of up to...

(adding virtualization mailing list) On Thursday 19 May 2011, Chris Metcalf wrote: > On 5/19/2011 9:41 AM, Arnd Bergmann wrote: > >> /proc/tile/hvconfig > >> Detailed configuration description of the hypervisor config > > I'm concerned about moving this one out of /proc, since it's just (copious) > free text. An "hvconfig" (hypervisor config) file describes hypervisor > driver "dedicated tile...

(adding virtualization mailing list) On Thursday 19 May 2011, Chris Metcalf wrote: > On 5/19/2011 9:41 AM, Arnd Bergmann wrote: > >> /proc/tile/hvconfig > >> Detailed configuration description of the hypervisor config > > I'm concerned about moving this one out of /proc, since it's just (copious) > free text. An "hvconfig" (hypervisor config) file describes hypervisor > driver "dedicated tile...

Hi, Yuanke, Thanks for writing this up. Let me back up a bit because the scheme I proposed last week doesn't work without further modification: within a particular "configuration region" (i.e., the code in between the LDTILECFG and the TILERELEASE (or next LDTILECFG)), each tile register can only be used with one shape, and in addition, no register can have its shape changed without zeroing out all of the tile registers. Thus, just using different register classes for the different shapes, as I had suggested, isn...

On 9/4/20 3:37 AM, Luo, Yuanke wrote: > > Hi Hal, > > Thank you for the ideas that help us to improve the design, and sorry > for replying late. There is something I am not able to figure out and > there some special trait for tile RA. > You're quite welcome. > 1.X86RegisterInfo::getRegAllocationHints can tell RA which physical > register is preferred, but it can’t force RA to just allocate the > hinted register. If the hinted register is not meet, RA would allocate > other register. > I addressed...

...ndrew <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 schemes first, or you would like to review the left part of the AMX programmin...

In the help for scale_fill_identity, it is written ## Not run: colour <- c("red","green","blue","yellow") qplot(1:4, 1:4, fill=colour, geom="tile") qplot(1:4, 1:4, fill=colour, geom="tile") + scale_fill_identity() # To get a legend, you also need to supply the labels to # be used on the legend, and the grob to draw them: # grob_tile, grob_line, or grob_point qplot(1:4, 1:4...

Please ignore the tegra diff on the bottom of this. I never fail to find a way to mess up git-send-email. -James On 12/11/19 12:59 PM, James Jones wrote: > This series modifies the NV5x+ nouveau display backends to advertise > appropriate format modifiers on their display planes in atomic mode > setting blobs. > > Corresponding modifications to Mesa/userspace are available

...|") voro = deldir(points$x,points$y,digits=10,frac=0.000000000000001,rw=c(min(points$x)-abs(min(points$x)-max(points$x)),max(points$x)+abs(min(points$x)-max(points$x)),min(points$y)-abs(min(points$y)-max(points$y)),max(points$y)+abs(min(points$y)-max(points$y)))) # generate voronoi edges tiles = tile.list(voro) # combine edges into polygons sink("voronoi.sql") # redirect output to file for (i in 1:length(tiles)) { # write out polygons tile = tiles[[i]] cat("insert into mytable (the_geom) values(geomfromtext('POLYGON((")...

I just checkout release_38 branches of llvm, clang and polly and built it on and x86 Ubuntu with cmake: CMAKE_BUILD_TYPE="Debug" CMAKE_INSTALL_PREFIX="$HOME/toolchain/install/llvm-3.8" LLVM_TARGETS_TO_BUILD="X86" cmake -G "Unix Makefiles" \ -DBUILD_SHARED_LIBS="ON" \ -DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE \