2015年3月30日月曜日

Intel Israelの特許紹介 その2

[特許] Generating and performing dependency controlled flow comprising multiple micro-operation (uops)
http://www.google.st/patents/US20090327657

RS(reservation station)が、特定のclockに基づいたdispatchの枠組みを持つ、複数のuop達から構成される依存制御型のflowを生成・処理しうるprocessor。

RSは2つ以上のuopを1つのRS entryへ結合するか、もしくは2つ以上のRS entryの直結を作ることができる。RSは3つ以上のsource値を単一のRS entryに連想付けすることができる。1つ以上の実行unit達が、先のuop達によって定義されている機能を実行する。実行unit達はある時点において3つ以上のsource達を受け取り、2つ以上の結果をそれぞれ異なるportへ生成する。

/* 途中の説明にもあるように、FMA3もこれで安泰(?)。Agner氏の最適化manualの内容を振り返ると、既にHaswellでやってる感。他と比べて若干古い特許だし。 */


[特許] Method and apparatus for cutting senior store latency using store prefetching
http://www.google.com/patents/WO2013101213A1

Storeについて、store-bufferからcacheへstore dataをretireするより前(この時点では実際に使う正しいstore dataかどうかわからない)に書き込み先のcache-lineのprefetchを行う。


[特許] Apparatus and method for memory-mapped register caching
https://www.google.com/patents/US20140189191

architectural register fileが、register fileとL1内architectural register領域の組み合わせとして物理的に実装されているprocessor。architectural registerの物理的な所在を割り出すことは、DLT(data location table)を引くことで達成される。

Intel Israelの特許紹介 その1

IDF2015 Shenzhen(http://www.intel.com/content/www/us/en/intel-developer-forum-idf/shenzhen/2015/idf-2015-shenzhen.html)の直前ながらIntel Isaelの特許紹介。Skylakeで実施されるかどうかはわかりません。

[特許] Performing Local Power Gating In A Processor
実行unitpower gateするlocal power gate回路が実行unit毎のpower gateを行う。
/* 現行のprocessorcore単位のpower gateをしているが、実行unit単位であり、粒度が細かいという話。 */

[特許] Power reduction by using on-demand reservation station size 
Reservation stationの電力削減に関する特許。

Reservation stationを複数のentry から成る複数のbundleと呼ぶ単位に分ける。個々のbundle達はwriteが可能な'open'状態と、writeが不可能な'close'状態を持っていて、その状態を切り替え可能。closeのときはpower controllerによってswitchoffされる。

2014年8月25日月曜日

Intel IsraelがAcceleratorの特許を出願している (本編)

前置きはこちら(http://intelfanboyblog.blogspot.com/2014/08/intel-israelaccelerator.html)

これまでの流れを総合すると、IntelはSkylakeについてGPU側の機能をCPU方面へ持ってくるよりも、CPU側の既存の機能をGPGPUっぽい方面へ拡大して性能を稼ぐ道を選択をしたように思われます。しかしながら、SkylakeではiGPUとCPUとの統合も依然として強化されることが予想されるわけで、iGPUとAVX-512の住み分け、あるいは協調について今後の展開がさらに注目になりそうです。

そんなわけでIntelの特許を漁っていたところ、さらに事態がよくわからなくなる下記の特許がIntel Israelから出願されていました。

[US Patent] Apparatus and method for low-latency invocation of accelerators

Acceeleratorの低latencyな呼び出し(invoke)を提供するための装置と方法が説明される。例えば、ある実施例のprocessorは、 実行すべきcommandを判別するためのcommand dataを格納をするためにcommand registerを含み、commandの実行結果もしくはそのcommandが実行できなかった理由を示すdataを格納するためにresult registerを含み、1つ以上のacceleratorを呼び出しする命令を含む多くの命令たちを実行するために実行論理を含み、command registerからのcommand dataを読み出してcommand dataによって指定されたcommandの実行を反応良く試みるために1つ以上のacceleratorを含む。


[US Patent] Apparatus and method for task-switchable synchronous hardware accelerators
http://www.google.com/patents/US20140189333
Accelerator commandを呼び出し(invoke)するためのaccelerator呼び出し命令を含んだthreadを実行するための実行論理と、memory内のapplication領域にaccelerator threadに関連する state dataを格納し、accelerator commandに応じてaccelerator threadを実行するacceleratorと、それでかつ、accelerator threadの実行に先立ってacceleratorが例外を阻止するために関連するTLB(translation lookaside buffer)内のentryたちをlockするようなprocessorの構成


これら特許のからは、Intelが何らかのacceleratorを、processorへ統合しようと模索していることが伺えます。


[雑感]
この特許(出願)は、GPU等で使われているdriver interfaceを介した方式は高latencyであるという問題と、一度呼び出しをすると呼び出し元のCPUに対して非同期(=処理の進捗のやりとりが殆どない)な動作になり、CPU側で割り込みや例外が発生した場合に都合が悪いという問題に対する解決策として提案されています。

単刀直入に言うと、XCALL命令と呼ばれる命令が追加されます。XCALL命令は、acceleratorを呼び出し(invoke)するための新しいx86命令で、library関数の呼び出しの感覚で、accelerator threadを起動し、acceleratorの機能を利用できる、と説明されています。

もしかしたらSkylake世代ではacceleratorと、このXCALLが提供されるのかもしれません。

もしそうなった場合に疑問なのは、XCALL自体は非常に一般的なinterfaceとして設計されていますが、具体的にどんなhardware(AVX-512, iGPU, etc.)がXCALLの対象acceleratorとしてSkylakeでは想定されているのかです。

一応、acceleratorの例としては、本文中ではloop acceleratorやsort acceleratorのようなprogrammableなもの(これまたAVX-512と被りそう、あるいはAVX-512の一応用かもしれない)、あるいはFFTやTexture Samplingといった固定機能のものなどが挙げられています。しかしながら、実際の製品で具体的に何が行われるかは、隅々まで読んでも推し量れないように避けられています。

ちなみに、本文中や図中で、AVX-512を使用したcoreやEVEXな命令formatの説明が出てきますが、これらは最近のIntelの特許ではテンプレに相当する部分です。この明細書を読む場合には特に重要な箇所ではありません。

"Accelerator"が具体的にどんなhardwareを想定しているのかについては、いくらでも解釈ができます。敢えて大きく分けると、典型的には次の5つの説になるでしょう:

(1) Acceleratorとは、AVX-512の実装のことで、同一CPU core内に実装される機能unit群のことである説
(2) Acceleratorとは、AVX-512の実装のことで、AVX-512に特化した別coreが提供される説
(3) Acceleratorとは、x86 ISAとは無関係な、新しい特殊用途のacceleratorのことで、CPU core内に実装される機能unit群である説
(4) Acceleratorとは、x86 ISAとは無関係な、新しい特殊用途のacceleratorのことで、別coreとして実装される説
(5) Acceleratorとは、iGPUのことである説

(1) Acceleratorとは、AVX-512の実装のことで、同一CPU core内に実装される機能unit群のことである説
最も保守的な説。Haswellで256-bitだったSIMD unitが、Skylakeではそのまま倍化されたような実装になる。既に公開されている通り、Skylake XeonはAVX-512をnativeに利用でき、consumer向けのSkylakeも実装上は同等になる。ただし、consumerではAVX-512が無効化されて提供されないか、もしくは、制限が加わりXCALLを介さないと利用できない。このXCALLを介したAVX-512 unitたちのことをacceleratorと呼んでいる。

(2) Acceleratorとは、AVX-512の実装のことで、AVX-512に特化した別coreが提供される説
AVX-512は、実は汎用CPU core内に実装されるのではなく、別のAVX-512に特化した小規模のcore、あるいは大規模なAVX-512 cluster core上に実装される。そして、これらのcoreたちがXCALLによって、汎用CPU coreから呼び出される。consumer版のSkylakeの全てまたは大部分では、このAVX-512に特化したcoreが実装されていない。ただし、この説は、実際のところ(1)の実装に匹敵する性能を出すために、AVX-512 coreへ投資がかなり大きくなってしまう。

(3) Acceleratorとは、x86 ISAとは無関係な、新しい特殊用途のacceleratorのことで、CPU core内に実装される機能unit群である説
Skylakeは、AVX-512以外に、実は未発表の特長として特殊用途のacceleratorがある。例えば、Skylake XeonはAVX-512とcore数に注力するが、consumer版のSkylakeはAVX-512よりもacceleratorに注力する。acceleratorが提供する機能は、consumerの需要に合わせたものになり、従来はiGPUのmedia機能として提供されていたものも含まれるかもしれない。極端な場合、Skylake Xeonとconsumer版Skylakeのcoreとでは、実装が異なるかもしれない。前者はAVX-512を実装するかわりにacceleratorを実装しない。後者はacceleratorを実装する代わりに、AVX-512を実装しない。ただ、これだと設計が大変なので、いつもどおり有効/無効化で対処してくるかもしれない。どっちみち設計上の無駄は多くなる。無理がありそうな説であるものの、Intelの特許の図では実際にCPU coreと同じcore内にaccelerator群が描かれていたりするから侮れない。

(4) Acceleratorとは、x86 ISAとは無関係な、新しい特殊用途のacceleratorのことで、別coreとして実装される説
(3)と同様に、Skylake XeonはAVX-512とcore数に注力するが、consumer版のSkylakeはAVX-512よりもacceleratorに注力する。acceleratorが提供する機能は、consumerの需要に合わせたものになり、従来はiGPUのmedia機能として提供されていたものも含まれるかもしれない。(3)と違って、AVX-512はともかく、少なくともacceleratorは、汎用CPU coreとは別のcoreとして提供される。例えば、consumer版のSkylakeではAVX-512が有効にされない代わりに、accelerator cluster coreが提供される。逆に、Skylake Xeonはconsumer向けのaccelerator cluster coreを欠いている。

(5) Acceleratorとは、iGPUのことである説
XCALL命令はSkylakeでは基本的にiGPU内の機能をCPUから呼び出すものである。利用可能な機能の候補としては例えば、programmableなEU, graphics関係の固定機能, HW encoder/decoder等のmedia機能が挙げられる。あるいは、XCALLの追加に合わせて、iGPU内へ新しいacceleratorが追加され、iGPUはSkylake以降accelerator cluster core的な位置づけへと変容していく。

--------------

AVX-512の実装は、汎用CPU coreの内部でscalar性能と両立していくことが、AVX2以前よりも難しくなりそうです。そのため、AVX-512よりも用途を更に絞ったacceleratorを追加していく方が、特に今後は電力効率面で優れているかもしれません。もしXCALLが(3), (4), (5)のようなAVX-512以外の非x86なacceleratorを強く意識した拡張であれば、なんだか登場前にしてAVX-512はもう古臭く感じられてきます。

やや長期的には、AVX-512のようなx86-basedなものと、Gen Graphicsや新規acceleratorのような非x86なものとをひっくるめてXCALL命令に集約していくつもり、というのもありそうです。Intel的にはSkylakeでCPU-GPU間の仮想memory空間のhardware水準の共有化が完成されて以降、様々なacceleratorを共有memory上に載っけいていく腹づもりなのかもしれません。もしそうであれば、hardwareによって高い互換性を担保してきたx86も、一つのISAに仕様をまとめあげることは諦め、softwareによる支援を交えた互換性の集約の方向に舵をきることになるかもしれません。あるいは、既にAVX-512のsupport範囲にXeon-Xeon Phi間で違いがあることが判明していますが、このようなx86 ISA内でのSKU毎の非互換に対してもsoftware infraを活用して吸収、という展開もあるかもしれません。



以上、これらのことは、特許が大前提ですのでいつも通り話半分以下です。もしSkylakeで実施されるとしたら、2014年9月9日に開催されるIDFで何らかの情報公開があるかもしれません。


[要約]

・背景
acceleratorの呼び出し(invoke)は、現在はdriver interfaceを介することが必要になっている。階層保護(hierarchical protection) domainが使用されているsystemでは、このことはring 0への切り替えと、異なるaddress空間へのdataのcopyを意味する。従って、相当な時間と資源が消費される。このようなaccelerator interfaceは、高latencyであるが故に生来的に非同期なものになる。Programmableなacceleratorでは独自のISAでのcodeの実装も要求される。

現在の一部のprocessor architectureでは、これらの懸念の一部を解決しようと試みているが、taskの要求からそのtaskの実行までの時間が高latencyであり、粗粒度な非同期の仕組みしか提供できていない。さらに、非x86なISAを使用する現行architectureは、accelerator上のtaskを生成してx86のmain programと統合するのに、[x86とは]異なるtoolchainを必要としている。

さらに、現在の非同期型hardware accelerator(例えばGPU)は、accelerator上のtaskに関して、それをtriggerした元のapplication threadとは無関係な実行を許してしまっている。このことは元のapplication threadが例外をhandleするような状況が発生しても、accelerator側のtaskがそれを関知しないことを許すことになるし、さらには元のapplication threadを処理しているcoreが別のcoreへ移行(migration)することになっても、accelerator側のtaskがそれを関知しないことすら許してしまっている。

現在の同期型hardware acceleratorには、割り込み, 例外, context切り替え, coreの移行について、機能的に正しく、かつこれから先の処理の進行を確約する(ensure forward progress)ことが要求されている。このことは、(1)全ての割り込みがacceleratorの処理が完了するまで待てるように、acceleratorの処理が十分に短く、かついかなる例外も引き起こさない, もしくは(2)architectural register内でacceleratorのこれから先の進行(forward progress)を維持・管理する, もしくは(3)acceleratorのstatusを保持するための新しいarchitectural register達を定義してXSAVE/XRESTOREへそれらを加える, のいずれかによって達成される。

・詳細
[Apparatus and Method for Efficiently Invoking Accelerators]
本発明では、同期型accelerator(例えばco-processorや機能unit群)の低latencyな呼出用に、"XCALL"と呼ぶ一般的で拡張性のある命令(x86)を提供する。

XCALL命令の形式は:
XCALL 〈result-register〉, 〈command-register〉, 〈param-register〉
である。result-registerはXCALL実行後の結果の格納用である。command-registerは、acceleratorで実行されるべき特定の命令および関連情報の格納用である。parameter(=引数) registerは、parameter(=引数)格納用である。

[
実際には、これらresult-register, command-register, param-registerは、既存のx86 ISAの汎用registerを使いまわす算段っぽい。
]

ある実施例では、accelerator cluster上にあるacceleratorたちは、特殊なdata処理向けのco-processorや機能unit群である(例えば、vector/SIMD操作, graphics操作, sortやloop操作等)。

processor(=汎用processor) clusterとaccelerator clusterは、同じcoreや同じchip内でもよいし、そうでなくてもよい。

command registerの64 bitのうちの上位16-bitは、以下のようなdata fieldを持っている。
Reserved: 2 bit
Continue: 1 bit
Tickle: 1 bit
Private: 1 bit
Id: 11 bit
Idは呼び出し(invoke)すべきacceleratorを一意に識別する。

Private bitは、当該acceleratorが既知のacceleratorの特定のgroupに属しているかどうかを示す。例えば、もしPrivate bitが0へ設定されていれば、そのIdは全てのcomputer system/processorに渡って共通のaccelerator全体の集合を識別していることが考えられる。もし1であれば、そのIdはproprietaryないしSKUに特定的なacceleratorを識別している。

command registerの下位48 bitと、全てのparameter registerは呼び出しされる当該accelerator毎に定義されているapplication-specificなdataを格納する。

ある実施例では、XCALL命令はEFLAGS内のZ-bitをsetする。EFLAGSはx86の現在の状態を格納するstatus registerである。もし要求されたacceleratorの実行が完了すれば、Z-bitは1へsetされる。このとき、Tickle bitが1にsetされていると、result registerは更新されず、実質的に何の作業もしないことになる。Tickle bitが0にsetされていると、result registerにはaccelerator-specificな値がsetされる。XCALLが何の作業もしなければZ bitは0へsetされる。この実施例ではZ-bitはXCALL命令が成功したかどうかを示すのに用いられているが、他のbitで同じ使われ方も考えられる。

result registerは以下のようなdata fieldを持っている。
Reserved: 2bit (本実施例では常に0へsetされる)
Permanent: 1 bit
Private: 1bit
Failure Details: 60 bit

ある実施例では、permanent bitは同じXCALLを再び続けて呼び出す場合に成功しそうかどうかを示す。例えば、将来の同じXCALLへのcallが成功するかもしれない場合(例えば、当該acceleratorが他のHW threadへservice中であったとき)、permanent bitは0へsetされる。同じXCALLの再試に成功の見込みがない場合(例えば、現在のSKUで当該acceleratorが存在しないときや指定のcommandかつまたは要求された引数の組み合わせが当該acceleratorでsupportされていないとき)、permanent bitは1へsetされる。

ある実施例ではresult registerの下位60 bitには、XCALLが失敗した理由のついての追加のdataがsetされる。

ある実施例では、もしresult registerのprivate bitが1へsetされていたとき、これらの詳細dataはaccelerator-specificな形式である。もしprivate bitが0へsetされていたとき、これらのdataは予め定義された一般的な形式である(例えば、Intelが定義)。

典型的な失敗したresult codeの例は、
Reserved bitが0になっていませんでした(Reserved bit in command register were not 0)
Acceleratorが存在しませんでした(Accelerator does not exist)
Acceleratorが別のthreadのservice中です(Accelerator is busy serving another thread)
である。

flowchartによって説明されている、本発明の一連の操作は―
XCALL命令がdecodeされる。その結果、acceleratorで実行されるべき当該commandに関連するdataはcommand registerに送られ、全ての必要なparameterがparameter registerへと送られる。private bitは、当該acceleratorが既知のacceleratorのgroupに属しているか、それともproprietaryなacceleratorに属しているかに拠って、command register内でsetされる。さらに、ID codeは当該commandを実行することになる特定のacceleratorを識別すべくcommand register内で更新される。
―である。

認識されたacceleratorはXCALLによって指定されているcommandを受信し、それが実行可能かどうかを判断する。例えば、当該acceleratorは別のHW threadのservice中で現在はbusyで、そのcommandを実行できないかもしれない。さらには、要求されたcommandかつまたはparameterの組み合わせが当該acceleratorでsupportされていない場合には、当該commandは実行できないことになる。

当該commandがうまく実行されると、commandの実行が成功したことを示すためにEFLAGSのZ-bitは0へsetされる。Tickle bitが事前に1へsetされていた場合には、result registerは更新されないままになる。Tickle bitが事前に0へsetされていた場合には、result registerはaccelerator-specificな値へsetされる。

XCALLによって指定されたcommandがacceleratorによってうまく実行されなかった場合、EFLAGSのZ bitは(実行の失敗を示すため)1へsetされる。もし将来の同じXCALL命令の実行の試みについて成功が予期される場合には、result registerのpermanent bitは0へsetされる。失敗の理由のを詳述する追加のdataもresult registerのfailure detail fieldへsetされることも考えられる。

もし将来のXCALL命令について成功しないことが予期される場合には、permanent bitは1へsetされ、失敗に付随した追加の情報が先のfailure detail fieldへsetされる。上述のどちらの場合であっても、failure detail fieldの情報が根本の原因を解析するのに使用されたり、当該命令の実行を改新することで対策することに使用されることが考えられる。

先述の通り、control registerかつまたはparameter registerがXCALL命令によって更新されることもあり得る。さらに、通常の関数呼び出しのように、XCALL命令はstack areaを消費することも考えられる。ある実施例では、XCALLの実行中に、RSP(64-bit stack pointer)はstackの使用量に拠って更新される。retire時には、stack領域の開放を受けて、RSP registerは元の値に復帰される。使用されるstackの量は、実際に使用されるaccelerator次第で異なる。

ある実施例では、これまで説明してきたacceleratorたちは下記の一連の規則に従うよう設計されている。

(1) もしXCALLの動作中に割込と例外が許可されているならば、continue bitは1へsetされ、当該handlerが完了した後にXCALLは再発行され、実行の継続がなされる。

(2) acceleratorは、割込や例外が存在する場合であっても、これから先の進行の確約(ensure forward progress)ができなければならない。

(3) 割込や例外が存在する中で、acceleratorが進行の確約を実装するために要求される全ての状態は、document化されているacceleratorに固有な指定の位置で更新されることが考えられ、具体的な位置としては1つ以上の(a) command registerかつまたはparameter register (b)他のarchitectural register (c)stack area (d)追加のmemory位置などが考えられる。これら全ての場合について、このstateはcontext切替え(例えば、XSAVE命令/context-switch/XRESTORE命令)の動作に対して生存できるものでなければならない。

(4) acceleratorは、'invalid(=無効)'なcommand registerやparameter register(例えば、未supportなfeature, hardwareの制約を超える値など)が与えられた時には、永遠に呼び出し(invocation)を拒否することを選び得る。

(5) user codeを呼び出しするprogrammableなacceleratorについては、programmabilityがacceleratorに固有な方法に限定されていることがある。例えば、"sort" acceleratorは、比較関数を呼び出しするかもしれないし、"loop" acceleratorはloopの本体(body)を呼び出しするかもれない。もし当該user codeが予期される[acceleratorに固有の]制約に従っていない場合(例えば、ring-basedな階層保護domainが既に使用済みのときにring 0に入ることを試みた場合)には、acceleratorは、通常通りそのstateを保存(save)し、例外(特にUD)をtriggerすることになる。

(6) 例外handlerは (a) 部分的に評価がなされたaccelerator[のcode]を非acceleratedなsoftware内で完遂する (b) 未supportな命令をemulateし、XCALL命令を再発行する(未supportな命令がretireしないようなsave済みstateの変更調整が必要になる) (c)実行を打ち切る、のいずれかを選択し得る。

ここに説明された本発明の実施例は標準的な機構を提供しており、これらはacceleratorを呼び出す(invoke)目的でx86のようなISAへ組み込まれることが考えられる。冒頭の背景で述べた技法と比較して、ここに述べたacceleratorの呼び出し(invocation)技法は、memory変換, register群, cacheその他に代表される各coreの資源の多くが共有されている(もしくは殆ど共有されていない)細粒度な低latency同期acceleratorを生来的に可能にする。Programmableな XCALL acceleratorは、userに対して通常のx86 code(例えばloopやsort)をaccelerateすることを可能にし、これはx86のmain programに一体な一部分であり、個別のtoolchainを必要としないものである。

さらに、現行のaccelerator interfaceは特定のaccelerator向けに設計されているが、ここに説明された本発明の実施例は広範さのあるもので、特定の市場に向けた特定のacceleratorの供給の合理化を可能にすると同時に、全ての市場をまたぐ"universal"なacceleratorも可能にする。Acceleratorの呼び出しは低latencyに行われ、data copyのoverheadがないので、これまで提供が非現実的であった機能もこれらのacceleratorの生態系がまかなえるようになる。また、既存のx86 ISAとの密な統合を維持しながらも、特定市場(組み込みsystem, 画像処理, HPC server, その他)に向けたaccelerator付きのSKUをあつらえることも可能になる。

ここに説明されたXCALL interfaceは、これまではCPUのISAやそのtoolchainから逸脱しなければ実現できなかった機能を提供するために、CPU拡張の能力を新たに開放するものでもある。例えば、programmable loop accelerator(SKMD[=single kernel multiple devices])やsort acceleratorのようなprogrammableなacceleratorが提供されることが考えられる。また、FFT(fast-Fourier transform), texture sampling, その他の機能を実施するような固定機能のacceleratorも考えられる。


・Fast Failure Handling of Complex ISA Instructions
[XCALLのfailure(=失敗)を通知するためのISA拡張について言及があるが面倒なので省略。]


・請求項
[Apparatus and method for low-latency invocation of acceleratorsの方]
実行すべきcommandを識別するためのcommand dataを格納をするためにcommand registerを含み、commandの実行結果もしくはそのcommandが実行できなかった理由を示すdataを格納するためにresult registerを含み、1つ以上のacceleratorを呼び出しする命令を含む多くの命令たちを実行するために実行論理を含み、command registerからのcommand dataを読み出してcommand dataによって指定されたcommandの実行を反応良く試みる1つ以上のacceleratorを含む構成のprocessor。それでかつ、もし1つ以上のacceleratorが実行に成功したらresult registerに当該commandの実行結果を構成することでresult dataを格納する、そして、もしacceleratorがcommandの実行に失敗したら、commandの実行ができなかった理由を示すresult dataを格納する、それでかつ、その実行論理はacceleratorが実行を完了するか、割り込みされるまで一時的に実行を停止でき、それでかつ、acceleratorは割り込み発生時に後で実行を継続(再開)できるように当該stateをstoreさせるための論理を持っているprocessor〈1〉。

それでかつ、先のcommand registerとresult registerは、processor coreのGPR(汎用register) fileの範囲内の汎用register達である〈2〉。

それでかつ、実行論理はx86の実行論理から構成される〈3〉。

それでかつ、実行論理と1つ以上のacceleratorが同一processor coreの範囲内にある〈4〉。

それでかつ、1つ以上のacceleratorがcommandの実行をできなかったとき、1つ以上のacceleratorが同じcommandの実行を続けて試みた場合に、そのcommandが成功することになるかどうかを示すresult dataをstoreする〈5〉。それでかつ、result dataにあるbitがあって、そのbitの1つ目の値が同一commandの実行を後に続けて試みた場合に成功の見込みがないことを示すもので、2つ目の値が逆に成功の見込みがあることを示す〈6〉。それでかつ、後続の命令が、このbitを読んで、同commandの実行を試みるかどうかを判断する〈7〉。

〈6〉でかつ、当該result dataはcommandの実行に失敗した特定の理由を示すresult codeを含む〈8〉。

〈1〉でさらに、当該commandに関連するparameter(=引数)を格納するためのparameter registerと当該commandを実行するためにそのparameterを読み出しする1つ以上のacceleratorから構成されるprocessor〈9〉。

〈1〉でかつ、少なくとも1つのacceleratorが固定機能のacceleratorを構成として含む〈10〉。

〈1〉でかつ、少なくとも1つのacceleratorがprogrammable機能のacceleratorを構成として含む〈11〉。

〈1〉でかつ、command registerが、commandを実行する際にacceleratorの1つのを識別するための識別(identification) codeを格納する〈12〉。

[Apparatus and method for task-switchable synchronous hardware acceleratorsの方]
Accelerator commandを呼び出し(invoke)するためのaccelerator呼び出し命令を含んだthreadを実行するための実行論理と、memory内のapplication領域にaccelerator threadに関連する state dataを格納し、accelerator commandに応じてaccelerator threadを実行するacceleratorと、それでかつ、accelerator threadの実行に先立ってacceleratorが例外を阻止するために関連するTLB(translation lookaside buffer)内のentryたちをlockするようなprocessorの構成〈1〉。

memory内のapplication領域がuser stack上にあって、SP(stack pointer)はuser stackの保存領域の下の位置へと調整(=書き換え更新)される〈2〉。

検出された例外条件(exception condition)に応じて実行論理で実行される例外handlerがあって、それでかつ、例外handlerの実行に先立って、acceleratorがTLBをunlockし、application領域内へ現在の状態をsaveする〈3〉。それでかつ、論理回路が例外state情報をmemory内の第二の別のstack領域へ格納し、例外handlerの実行に先立って、その第二stack領域へとstack pointerが調整される〈4〉。それでかつ、例外handlerの完了後にstack pointerが最初のstack領域を指すように調整され、acceleratorはaccelerator threadの実行を続けることができる〈5〉。それでかつ、accelerator threadが実行を続けるために、acceleratorはaccelerator threadに関連するstate dataをmemory領域から読み出す〈6〉。それでかつ、accelerator threadの完了の後に、stack上に先のsave領域がある場合は、acceleratorがaccelerator threadの実行を開始した時点で指していたstack上の位置に、stack pointerを調整する〈7〉。

acceleratorはeventに応じてaccelerator threadの実行を一時停止(pause)する〈8〉。それでかつ、その後に第二の別のacceleratorが、application領域内に格納されている先のstate dataを利用してaccelerator threadの実行を再開(resume)する〈9〉。それでかつ、その第二の別のacceleratorがacceleratorとは別のprocessor core上にある〈10〉。それでかつ、先のapplication領域は、第一のacceleratorと第二のacceleratorとで共有されたmemory内に格納されている〈11〉。それでかつ、先のmemoryが共有型cacheから成る〈12〉。

Intel IsraelがAcceleratorの特許を出願している (前置き)

以前、旧blogで、Intelの特許を元ネタにした:

[旧blog] Skylake Microarchitectureの方向性?
http://microboy.seesaa.net/article/358592842.html

という記事を書きました。

上の記事では、SkylakeはGPUとCPUの一体化を推し進める方向性であることに注目しました。そして、Intel (Israel)から特許として、CPU core内にvertex processing unitとpixel processing unitが統合された構成例のものが出願されていることついて触れました。この記事は、いま見れば古いですが、当時はAVX3/-512が未発表でした。SkylakeがGPUとCPUとの統合を強化する方向性であるとの認識も世間にはあまり浸透していませんでしたので、当時としては早い記事です。

とは言うものの、記事を書いてわずか2ヶ月も経たない2013年6月末くらいに、Intelの512-bit SIMD拡張の計画が独経由のleakにより明らかになりました。これは当時AVX3と呼ばれていてました。もっと細かく言うと、Knights LandingがAVX3.1、SkylakeがAVX3.2に対応するという話です。このときのleakでは、Haswellが16 DP/cycleであるのに対して、Skylake XeonがAVX3により32DP/cycleになり、2倍のDP throughputを達成するとされていました。
http://abload.de/img/einleitunghezdo.png

AVX3は、そのすぐ後の2013年7月23日にIntelから「AVX-512」として正式に発表され、documentも公開されました。

AVX-512の実装は大規模な投資ですし、(GP)GPUと高速化の手法や思想がかなり似ており、機能面で被る部分も多い技術です。そんなわけで、AVX-512という拡張がSkylake CPUに搭載されることが発覚した、この時点で、元々GPUの特長だった機能がCPU core内に取り込まれる可能性は殆どあり得ない、というのが常識的な見解となったわけです。


現在では、さらにSkylakeに関して、iGPUの編成についても下記のsite等から非公式な情報がある程度もたらされています。これらを見るかぎりでは、SkylakeのiGPUは既存のGen Graphicsを元に拡張したものと捉えるのが普通でしょう。また、AVX-512がsupportされるからといって、CPUと既存iGPUの統合化の路線も辞めるという様子では無く、共有仮想memoryのがsupportされると言われています。

[CPU World] More details on Skylake processors
http://www.cpu-world.com/news_2014/2014062601_More_details_on_Skylake_processors.html

[CPU World] Some features of Skylake graphics architecture
http://www.cpu-world.com/news_2014/2014060901_Some_features_of_Skylake_graphics_architecture.html

2014年7月18日には、AVX-512について更なる拡張(主にSkylake Xeon向け, 要するにAVX3.2)が発表されました。Intelの公式siteや下記の資料から、Kinghts LandingとSkylake XeonとでAVX-512のsupport範囲に違いがあることも明らかになりました。

[GCC] Intel Advanced Vector Extensions 2015/2016 Support in GNU Compiler Collection
https://gcc.gnu.org/wiki/cauldron2014?action=AttachFile&do=get&target=Cauldron14_AVX-512_Vector_ISA_Kirill_Yukhin_20140711.pdf

ちなみに、Skylakeについては、Skylake Xeon(略してSKX)についてのみAVX-512のsupportが言及されています。consumer向けのSkylake製品については、AVX-512をsupportするのか否か未だに公式の言及が無いので、謎の1つになっています。

これまでの情報だけから考えるとSkylakeのおよその目玉は、
(1) AVX-512の追加 (Xeonのみ?)
(2) CPUとGPUの統合化が一段階進み、仮想address空間は共有化される
であると考えられます。


次回の記事は(本編: http://intelfanboyblog.blogspot.com/2014/08/intel-israelaccelerator_25.html)、Skylakeの目玉は本当にそれだけなのかということに関わってきます。

以上、前置きが長くなりましたが、ここまでが前回の記事(約1年3ヶ月前)からのおおよその経過でした。