AMD、CPUとGPUが同じメモリ空間を共有可能になる新技術「hUMA」を発表 85
ストーリー by hylom
CPUとGPUの統合が近づく 部門より
CPUとGPUの統合が近づく 部門より
あるAnonymous Coward 曰く、
4月30日、AMDは同社が提唱するGPUコンピューティングフレームワーク「HSA」（Heterogeneous System Architecture）のキーテクノロジーといえる「hUMA」（heterogeneous Uniform Memory Access」を発表した（4Gamer、PC Watch）。
HSAは次世代APU「Kaveri」のフレームワークで「CPUとGPUのコードを別々に記述する煩雑さや複雑さ」をなくそうことを考えているらしい。主題の「hUMA」は複数のプロセッサが論理的に単一のメモリ空間を共有する「Uniform Memory Access」と「heterogeneous」を掛け合わせた造語で、hUMAは詰まるところCPUとGPUがソフトウェア的にメモリ空間を共有する技術だという。
4gamer記事によれば、次世代APUで実現されるhUMAでは、CPUとGPUがアクセスするメモリ内のデータの一貫性が保たれるようになる、GPUがページフォルトを扱えるようになる、GPUがメモリ空間の全域にアクセスできるようといったことができるようだ。
星飛雄馬 (スコア:2, おもしろおかしい)
言ってみただけ。ごめん。
Re:星飛雄馬 (スコア:2, おもしろおかしい)
Re:星飛雄馬 (スコア:3)
Re:星飛雄馬 (スコア:1)
マシン系も捨てがたい!!
Re:星飛雄馬 (スコア:1)
ゾンビがマイブームです
FPA再来 (スコア:2)
思いついたこと (スコア:1)
この仕組の穴をついてGPUの並列処理機能を活用したクラッキング。
あるいは、CPU側プロセスのメモリ領域を覗けたりとか……
マルウェアを送り込めたらマシン上でのブルートフォースがはかどってしまうとか？
まぁマルウェア送り込まれた段階で、十分ダメな状況なので
単にクラッカーのプログラミングの手間が省けるとかなのかな
# アプリケーション側からは、アーキテクチャの違うマルチCPUマシンって見える
# としたら……TeraDriveみたいなものなのかな？
Re:思いついたこと (スコア:2)
こういう事だから、問題無いね。
Re:思いついたこと (スコア:2)
その話と元コメントのセキュリティ上の懸念はあまり関係ないかと。
たとえば、CPUの特権レベルの枠外でGPUが動作しているならGPUが
悪さをすることができるのではないか、という懸念ですね。
これは私も考えました。
たとえば特権レベルとは無関係にGPUが物理メモリページをマップできるとかだと、
コンピュータのセキュリティ上はかなり問題があるわけですが、GPUというのは
実行できるコードにかなりの制約があるので、おそらくはGPU側からページテーブルを
弄るといったことはできないようにしているとは思います。
そもそもGPUコードをキックスタートさせるのはCPUからだけになると思うので、
そういった意味ではセキュリティは保ちやすいような気がします。
いまのところAMDはGPUと特権レベルの関係について、これといった
コメントは述べていなかったと思うので、詳細は実像が明らかになってみないとわかりません。
いずれにしてもGPUがOSを落とせるといったことが可能だとセキュリティ上の
問題になるので、そう出来ない仕組みは入ってると思います。
# 聞いてみりゃ良かったが後から思いついたので、機会があれば聞いてみましょう。
ところで、後藤さんの記事からですが
>ストレージ上にあるメモリ内容を物理メモリに書き戻す。
とありますが、ページフォルトはスワップアウトされたメモリページだけで発生するわけでは
ないので、その点は要注意ですね。
Re:思いついたこと (スコア:2)
CPUに繋がるメモリと並列に別のCPUとしてGPUが繋がってればCPUの扱うコードをいじることが当然できそうですが、それは今のマルチコアCPUでも同じことで、現実の脅威にはなってなさそうですね。AMDは少し前にARMのライセンスを取ってCPU内部にセキュリティプロセッサとして組み込むって言ってたので、CPUとGPUで認識を共通化させる役割を持たせるとかもあるのかも。
Re:思いついたこと (スコア:5, 参考になる)
>今のマルチコアCPUでも同じことで、現実の脅威にはなってなさそう
それは当然ですね。
CPUのコード実行はOSの管理下で、CPUコアがいくつあろうとも
OSにプロテクトされた領域をユーザーモードからあれこれしたりは
できないようになってます。CPUには特権モードがあるからで、そのおかげで
ユーザーランドからカーネルランドにちょっかいは出せませんし、
他のプロセスを妨害することもできません。
しかし、既存のOSにはGPUのコード実行を管理する仕組みはないので、
つまりGPUのはOSの管理外にあるCPUコアのようなもの、になります。
従来はGPUはローカルメモリにしかアクセスできない、いわば檻の中の
虎のようなものだったのでGPUがシステムのセキュリティを脅かすことは
なかったわけです。
しかしhUMAによって仮想アドレス空間全域にアクセス可能に
なるわけですから、OSから管理されない虎が野に放たれる形になります。
なので、ユーザーモードから実行されたGPUコードが悪さをしようとした時、
たとえば仮想アドレス空間中のカーネル領域にちょっかいを出そうとした時には
例外を投げてコードの実行が中断される、というような仕組みが
必要でしょう。そのためにはGPUが特権モードを持っている（GPUもCPUの特権モードに
したがって動いている）必要があろうかと思うのです。
ただ、CPUの例外は例外処理に、つまりOSのカーネルに実行が飛ぶわけですけど
GPUが例外はどうなんだ？ みたいなことを考えると、hUMAのような仕組みを持つGPUは
OSレベルでのサポートが必要な気がします。
けど、AMDはとりあえず既存のOSでも問題ないといってるので、どうなってるかは
気になるところです。
Re:思いついたこと (スコア:2)
AMDはメモリコントローラ統合の次にCPUとGPU統合を進めていて、APUのGPUというのはCPUと同じダイに焼かれてオンダイのメモリコントローラを通して外部のSDRAMに繋がるわけですけど、そこでページが書けるかどうかもチェックしないGPUをCPUとなんの連携もせずに載っけちゃうってことがどのくらいありえるんでしょう…
GPUの起こした例外はとりあえずそのプログラムを投げたプロセスの例外でいいのでは…
Re:思いついたこと (スコア:1)
でもビデオドライバ(など)のクラックでDMA経由でカーネルを汚染する手法はあるからなぁ...
# この場合はユーザーモードドライバとかなのかな?
気をつけないとですね。
M-FalconSky (暑いか寒い)
Re:思いついたこと (スコア:1)
Re:思いついたこと (スコア:1)
細粒度で切り替えるコンテクストスイッチが実装されていないとは書かれていますが、コンテクストスイッチを伴わない走り出したら終了までコンテクストスイッチをしないコンピュテーションには触れられていませんよね?
それほんとに新技術なの？？ (スコア:1)
メインメモリをVRAMとして使えるなんて10年以上前から当たり前にやってることなんじゃないの？
＃GPUをVRAMにアクセスさせる時に自動的にメインメモリに置き換えるだけのラッパーだったら笑いますがｗ
Re:それほんとに新技術なの？？ (スコア:2)
それは物理アドレス＝アプリケーションが使用しているアドレスだったX68kとか、x86上の
MS-DOSまでですね。
8ビット時代だと、CPUのスタックポインタにVRAMをマップして、ドットがムニョムニョ動くのを
見て「スタックが可視化できたyo! すっげー最高」などと遊べたものです。まあ目で見てデバッグ
とかほとんど無理なんですけど。
VRAMはCPUの物理アドレス空間にマップされてるので、CPUからVRAMを参照することは
これまでもやろうと思えば可能でしたが、GPUがプロセスのページテーブルを参照
できない等で、GPUからプロセスの仮想アドレス空間を参照できないという形でした。
GPUは基本データドリブンなので、大量のデータを一気に食ってくれますが、上記の
制限があるためCPU側からデータをVRAMに転送する必要があり、
それがオーバーヘッドになっていたが、それが緩和されるね、というのがそこそこの
メリットかと。
Re: (スコア:0)
8ビット時代は
VRAMをメインメモリ代わりに使える機種はいくらかはありましたが
メインメモリをVRAM代わりに使える機種はほとんど無かったと思いますよ
Re:それほんとに新技術なの？？ (スコア:2)
VRAMをマップして、などと間違って書いてしまったので誤解を招いた
ようです。SPにVRAMのアドレスをロードする、ですね。
暴走するとVRAMにデータぶちまけることがあったり、
VRAMも何もかもメインメモリにマップされてましたから。
関係ないけど、どういうわけか暴走するとビープ（PSG）のポートとカセットテープを
制御するリレーのポートを叩くことが多かったので、
ブピーカチン、「うひょー暴走した」、リセットポン
みたいな一連の反射行動を取ったりしてたのを生々しく記憶してます。
あの音を聞くと今でも反射的にリセットボタンに手が伸びるかもしれません。
いまのPCにはPSGとかリレーはないから聞けないですけどね。
特権だとかページング仮想記憶だとか何とか面倒なことがも何もない、
のんびりした時代だったってことで
（実際には主に使っていた8ビット機がMB-S1だったのでページング仮想記憶はあったが）
Re: (スコア:0)
CRTの表示出力を切ると処理能力があがりましたね。CRTの画面は砂嵐のようになってましたが。
Re:それほんとに新技術なの？？ (スコア:2)
構造的に、厳密に言えば画期的なのかもしれないけど、
メインメモリをVRAMとして使えるなんて10年以上前から当たり前にやってることなんじゃないの？
ついでにテキスト表示専用のVRAMもつけちゃえ!
とならないかとわくわくしてしまいます。
Re:それほんとに新技術なの？？ (スコア:1)
> メインメモリをVRAMとして使えるなんて10年以上前から当たり前にやってる
それが思い浮かぶなら、i810 [wikipedia.org]などで採用された、メインメモリの一部をVRAMとして使う機能のことをUMA [wikipedia.org]と呼ぶことも思い出して欲しいですね。
今回AMDが発表したのは、その名が「hUMA」であることからして、従来のUMAを拡張したもの、であるのは明白でしょう。
Re: (スコア:0)
日本語版にしかエントリがないのを訝しんだりしないんだろうか
Re: (スコア:0)
大転換させたら、360度回っていたでござる。みたいなものですね。
Re: (スコア:0)
いや寧ろ近いのは10年以上前だ。
物理メモリの共用と論理空間の共用の差がしっかり示されていてすら理解していない人が多いのは何故か判らん、
大丈夫か？ (スコア:1)
それは要するに、今より深刻なmarocエラーが出るようになるって事なんじゃないの？
と思うんだけど・・・
＃そもそも需要あるの？
Re: (スコア:0)
技術的な話はわかりませんが、
CPUとGPUを統合するのに都合がいいんじゃないですかね？
Re: (スコア:0)
GPUが処理しようとする作業のなかで、ページフォルトをえっちらおっちらやっている暇あるんだろうか。SSD限定か？
GPGPUなら (スコア:1)
リアルタイム性がいらないので、ディスク上の巨大なファイルをmmapして演算ソースにするとかかな。
ビデオを一本丸ごと配置して、フレーム相関使った再エンコードとかどうでしょう。
ふと思いだした (スコア:1)
00 00 3F YAMAUCHI
Re: (スコア:0)
書こうと思ったら既に書かれていた
メモリ空間 (スコア:1)
64bitになってメモリ空間が圧倒的に広くなったので、こういう構造もやりやすくなったんでしょうかね。
# メモリ容量が増えてくると、逆に戻ったりするんだろうか。
ストレージも含めて、一つの空間にマッピングできるのは愉しいかもしれない。
で、GPUと、CPUでエンディアンが逆だった.... なんてオチがつきませんように。
多重スクロール復権 (スコア:0)
ゲームの画像メモリをちまちまと書き換える作業が始まるお…
ハイパフォーマンス・コンピューティング (スコア:1)
Graphics Processing Unitとは言うものの、グラフィック／ゲーム用とは限らない。
今回のは処理の高速化、ひらたくいえばスパコン的な用途を想定しているのでは？
もしそうなら、
「大量データ（全メモリ＋仮想記憶）を使った高速演算が、今までより楽になりますよ」
が売りになるのはアリだと思う。
Re:ハイパフォーマンス・コンピューティング (スコア:1)
GPGPUすると、計算元のCPUのDRAMと大量計算するためのデータを置くGPUのVRAMが遠くて性能を上げにくいボトルネックになり易いのでその辺に効くのでしょうね。
統合だとそれこそ同じデータをあっちこっちにコピーしなおしてる訳で無駄な処理ですしねぇ
ディスクリートだとPCI-E経由しないといけないから統合GPUで出来る裏技かしらね。
将来的に本気で速度出すなら統合側で下処理して、ディスクリートで本処理みたいな役割分担とかにもなるのかな？
i810 チップセット (スコア:0)
大昔に出てたインテルの i810 チップセットもメインメモリとビデオメモリを共有してなかったっけ？
性能は段違いだろうけど。
Re:i810 チップセット (スコア:1)
ちょっと変な例えだけど、大ざっぱなイメージとしては、CPU上で動作してるプログラムがメモリの0x0000...0000番地から0xffff...ffff番地までアクセスすると途中でVRAMが出てくるかどうかの差じゃないかな。 今回のhUMAとか、古くはPC9801とかだとVRAMに触れる。
i810の方式の場合は、その方法ではVRAMには触れない。VRAMに割り当てた分はシステムから切り離されてCPUから見ると行方不明となる。 切り離された分は、GPUにぶら下げられてそっちで使われる。
実際にはページングやら何やらと、間に挟まるのでこの通りではないんだけど。
Re: (スコア:0)
そのころのは、メインメモリからBIOSレベルで予約しちゃってたから、OSのメモリ表示から減ってた(=OS管理外)けど、
今回のはOSの管理上のメモリに動的に設定したり、CPUからVRAMに割り当てられたところを直接塗りつぶしたりスワップできるように見える。
Re: (スコア:0)
ただでさえ狭いメモリ帯域(当時はPC100くらい?)をビデオに食われて、散々だったあれですね。
あれから数年間はチップセット内蔵ビデオ不信で、とりあえず適当なカードをAGPに刺してました。
コヒーレンス (スコア:0)
かなりコストかかるような気がします。直感的には
Re:コヒーレンス (スコア:2)
GPUの処理を始める直前にCPUのキャッシュを、GPUの処理を終えてプログラム側に通知を返す直前にGPUのキャッシュをフラッシュするだけでいいよ。
Re:コヒーレンス (スコア:2)
電力とか、キャッシュメモリ帯域のコストの事なら、後藤さんの記事によればOpteronと同様の方法でトラフィック削減するそうです。
Opteronでのプローブフィルタの解説記事
http://news.mynavi.jp/articles/2009/09/03/hot_chips21_server/index.html [mynavi.jp]
Re: (スコア:0)
CPUキャッシュやレジストリの内容とメモリ間で不一致起こしそうですけど、どういう仕組みで回避してるんでしょうね。
小技はいいから (スコア:0)
IntelのCoreシリーズとためをはれるCPU作って欲しい。
しばらくぶりにIntelに転んでしまった。
Re: (スコア:0)
それができないから小技に走ってるんでしょう…
察してあげてくださいよ
Re: (スコア:0)
まあでも次の展開がインテル一人勝ちではなさそうなところが面白いわけですが
MMUつけました・HWでコヒーレンシ確保します (スコア:0)
結局GPU側にページテーブル持てるようにしました。キャッシュのコヒーレンシをCPUと同様にできるようにしました。の2つかな。
前者はつければ済む話の気はする。GPUで記述することのできるプログラムがページテーブル操作をどれだけできるのかは知らないけど。
後者はCPU側のキャッシュさえも意識しないで済むようになってるのならだいぶ楽になるんでしょうね。
メモリは共用できてもIOバスへのアクセスはできないんだろうなぁ。IOMMUを設定しておけばデバイス扱いで行けるか？
CPUとGPUのメモリ (スコア:0)
CPUのメモリからテクスチャデータなどをVRAMに転送しなくてもいいのがメリットの一つじゃなかったでしたっけ？
むしろ現状の非効率さに驚き (スコア:0)
Re:ゲーム機と一緒じゃね (スコア:2)
一緒っていうか、PS4のCPUに採用したシステムの解説ですね。これ自体はもう何年もAMDが研究していて、時間的に去年か一昨年頃レベルのベータというかアルファというか、機能びみょう版がPS4には載っているっていう。そういえばPS3の時はCUDAとかが確立する直前で、IBMとかがGPUじゃないSIMDのプロセッサを追求してCell作って、結局グラボに負けてCellはポシャりましたっけ…