パスワードを忘れた? アカウント作成
8677985 story
ハードウェア

AMD、CPUとGPUが同じメモリ空間を共有可能になる新技術「hUMA」を発表 85

ストーリー by hylom
CPUとGPUの統合が近づく 部門より
あるAnonymous Coward 曰く、

4月30日、AMDは同社が提唱するGPUコンピューティングフレームワーク「HSA」(Heterogeneous System Architecture)のキーテクノロジーといえる「hUMA」(heterogeneous Uniform Memory Access」を発表した(4GamerPC Watch)。

HSAは次世代APU「Kaveri」のフレームワークで「CPUとGPUのコードを別々に記述する煩雑さや複雑さ」をなくそうことを考えているらしい。主題の「hUMA」は複数のプロセッサが論理的に単一のメモリ空間を共有する「Uniform Memory Access」と「heterogeneous」を掛け合わせた造語で、hUMAは詰まるところCPUとGPUがソフトウェア的にメモリ空間を共有する技術だという。

4gamer記事によれば、次世代APUで実現されるhUMAでは、CPUとGPUがアクセスするメモリ内のデータの一貫性が保たれるようになる、GPUがページフォルトを扱えるようになる、GPUがメモリ空間の全域にアクセスできるようといったことができるようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 星飛雄馬 (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2013年05月02日 13時22分 (#2374174)

    言ってみただけ。ごめん。

  • by saitoh (10803) on 2013年05月02日 17時50分 (#2374367)
    外付けの浮動小数点チップへの命令をCPUへの命令に混ぜて書ける方式を思い出した。って86~386がそうだったはずだけど(記憶違いだったらごめん)。
  • by kicchy (4711) on 2013年05月02日 12時50分 (#2374150)

    この仕組の穴をついてGPUの並列処理機能を活用したクラッキング。
    あるいは、CPU側プロセスのメモリ領域を覗けたりとか……
    マルウェアを送り込めたらマシン上でのブルートフォースがはかどってしまうとか?
    まぁマルウェア送り込まれた段階で、十分ダメな状況なので
    単にクラッカーのプログラミングの手間が省けるとかなのかな

    # アプリケーション側からは、アーキテクチャの違うマルチCPUマシンって見える
    # としたら……TeraDriveみたいなものなのかな?

    • by miyuri (33181) on 2013年05月02日 13時26分 (#2374178) 日記

       しかし、hUMAでは、ページフォルトがGPU側のMMUでもサポートされているために、シームレスに仮想メモリ空間全体にアクセスができる。つまり、ページフォルトになったら、MMUが割り込みをかけて、ストレージ上にあるメモリ内容を物理メモリに書き戻す。

      こういう事だから、問題無いね。

      親コメント
      • by epgrec (43527) on 2013年05月02日 13時47分 (#2374201)

        その話と元コメントのセキュリティ上の懸念はあまり関係ないかと。

        たとえば、CPUの特権レベルの枠外でGPUが動作しているならGPUが
        悪さをすることができるのではないか、という懸念ですね。
        これは私も考えました。

        たとえば特権レベルとは無関係にGPUが物理メモリページをマップできるとかだと、
        コンピュータのセキュリティ上はかなり問題があるわけですが、GPUというのは
        実行できるコードにかなりの制約があるので、おそらくはGPU側からページテーブルを
        弄るといったことはできないようにしているとは思います。
        そもそもGPUコードをキックスタートさせるのはCPUからだけになると思うので、
        そういった意味ではセキュリティは保ちやすいような気がします。

        いまのところAMDはGPUと特権レベルの関係について、これといった
        コメントは述べていなかったと思うので、詳細は実像が明らかになってみないとわかりません。
        いずれにしてもGPUがOSを落とせるといったことが可能だとセキュリティ上の
        問題になるので、そう出来ない仕組みは入ってると思います。

        # 聞いてみりゃ良かったが後から思いついたので、機会があれば聞いてみましょう。

        ところで、後藤さんの記事からですが

        >ストレージ上にあるメモリ内容を物理メモリに書き戻す。

        とありますが、ページフォルトはスワップアウトされたメモリページだけで発生するわけでは
        ないので、その点は要注意ですね。

        親コメント
        • by 90 (35300) on 2013年05月02日 21時41分 (#2374495) 日記

          CPUに繋がるメモリと並列に別のCPUとしてGPUが繋がってればCPUの扱うコードをいじることが当然できそうですが、それは今のマルチコアCPUでも同じことで、現実の脅威にはなってなさそうですね。AMDは少し前にARMのライセンスを取ってCPU内部にセキュリティプロセッサとして組み込むって言ってたので、CPUとGPUで認識を共通化させる役割を持たせるとかもあるのかも。

          親コメント
          • by epgrec (43527) on 2013年05月03日 0時00分 (#2374541)

            >今のマルチコア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でも問題ないといってるので、どうなってるかは
            気になるところです。

            親コメント
            • by 90 (35300) on 2013年05月03日 1時17分 (#2374569) 日記

              AMDはメモリコントローラ統合の次にCPUとGPU統合を進めていて、APUのGPUというのはCPUと同じダイに焼かれてオンダイのメモリコントローラを通して外部のSDRAMに繋がるわけですけど、そこでページが書けるかどうかもチェックしないGPUをCPUとなんの連携もせずに載っけちゃうってことがどのくらいありえるんでしょう…

              GPUの起こした例外はとりあえずそのプログラムを投げたプロセスの例外でいいのでは…

              親コメント
    • でもビデオドライバ(など)のクラックでDMA経由でカーネルを汚染する手法はあるからなぁ...

      # この場合はユーザーモードドライバとかなのかな?

      気をつけないとですね。

      --
      M-FalconSky (暑いか寒い)
      親コメント
    • 汎用のOSから使えるようにするにはそのとき所属しているOSのプロセスに合わせてGPUスレッドごとにページテーブルを設定出来ないとセキュリティが確保できないんだけど、そこら辺の事には触れられてなくてコヒーレンシーが取れる取れる言ってるだけなのが気になりますね。
      親コメント
  • 構造的に、厳密に言えば画期的なのかもしれないけど、
    メインメモリをVRAMとして使えるなんて10年以上前から当たり前にやってることなんじゃないの?

    #GPUをVRAMにアクセスさせる時に自動的にメインメモリに置き換えるだけのラッパーだったら笑いますがw
    • それは物理アドレス=アプリケーションが使用しているアドレスだったX68kとか、x86上の
      MS-DOSまでですね。
      8ビット時代だと、CPUのスタックポインタにVRAMをマップして、ドットがムニョムニョ動くのを
      見て「スタックが可視化できたyo! すっげー最高」などと遊べたものです。まあ目で見てデバッグ
      とかほとんど無理なんですけど。

      VRAMはCPUの物理アドレス空間にマップされてるので、CPUからVRAMを参照することは
      これまでもやろうと思えば可能でしたが、GPUがプロセスのページテーブルを参照
      できない等で、GPUからプロセスの仮想アドレス空間を参照できないという形でした。

      GPUは基本データドリブンなので、大量のデータを一気に食ってくれますが、上記の
      制限があるためCPU側からデータをVRAMに転送する必要があり、
      それがオーバーヘッドになっていたが、それが緩和されるね、というのがそこそこの
      メリットかと。

      親コメント
      • by Anonymous Coward

        8ビット時代は
        VRAMをメインメモリ代わりに使える機種はいくらかはありましたが
        メインメモリをVRAM代わりに使える機種はほとんど無かったと思いますよ

        • VRAMをマップして、などと間違って書いてしまったので誤解を招いた
          ようです。SPにVRAMのアドレスをロードする、ですね。

          暴走するとVRAMにデータぶちまけることがあったり、
          VRAMも何もかもメインメモリにマップされてましたから。

          関係ないけど、どういうわけか暴走するとビープ(PSG)のポートとカセットテープを
          制御するリレーのポートを叩くことが多かったので、
          ブピーカチン、「うひょー暴走した」、リセットポン
          みたいな一連の反射行動を取ったりしてたのを生々しく記憶してます。
          あの音を聞くと今でも反射的にリセットボタンに手が伸びるかもしれません。
          いまのPCにはPSGとかリレーはないから聞けないですけどね。

          特権だとかページング仮想記憶だとか何とか面倒なことがも何もない、
          のんびりした時代だったってことで
          (実際には主に使っていた8ビット機がMB-S1だったのでページング仮想記憶はあったが)

          親コメント
        • by Anonymous Coward

          CRTの表示出力を切ると処理能力があがりましたね。CRTの画面は砂嵐のようになってましたが。

    • 構造的に、厳密に言えば画期的なのかもしれないけど、
      メインメモリをVRAMとして使えるなんて10年以上前から当たり前にやってることなんじゃないの?

      ついでにテキスト表示専用のVRAMもつけちゃえ!
      とならないかとわくわくしてしまいます。

      親コメント
    • > メインメモリをVRAMとして使えるなんて10年以上前から当たり前にやってる
      それが思い浮かぶなら、i810 [wikipedia.org]などで採用された、メインメモリの一部をVRAMとして使う機能のことをUMA [wikipedia.org]と呼ぶことも思い出して欲しいですね。

      今回AMDが発表したのは、その名が「hUMA」であることからして、従来のUMAを拡張したもの、であるのは明白でしょう。

      親コメント
      • by Anonymous Coward

        日本語版にしかエントリがないのを訝しんだりしないんだろうか

    • by Anonymous Coward

      大転換させたら、360度回っていたでござる。みたいなものですね。

    • by Anonymous Coward

      いや寧ろ近いのは10年以上前だ。

      物理メモリの共用と論理空間の共用の差がしっかり示されていてすら理解していない人が多いのは何故か判らん、

  • by duenmynoth (34577) on 2013年05月02日 14時08分 (#2374220) 日記
    > CPUとGPUがアクセスするメモリ内のデータの一貫性が保たれるようになる、GPUがページフォルトを扱えるようになる、GPUがメモリ空間の全域にアクセスできる

    それは要するに、今より深刻なmarocエラーが出るようになるって事なんじゃないの?
    と思うんだけど・・・

    #そもそも需要あるの?
    • by Anonymous Coward

      技術的な話はわかりませんが、
      CPUとGPUを統合するのに都合がいいんじゃないですかね?

    • by Anonymous Coward

      GPUが処理しようとする作業のなかで、ページフォルトをえっちらおっちらやっている暇あるんだろうか。SSD限定か?

      • by barrin (34369) on 2013年05月03日 2時27分 (#2374580) 日記

        リアルタイム性がいらないので、ディスク上の巨大なファイルをmmapして演算ソースにするとかかな。
        ビデオを一本丸ごと配置して、フレーム相関使った再エンコードとかどうでしょう。

        親コメント
  • by Anonymous Coward on 2013年05月02日 14時48分 (#2374258)

    00 00 3F YAMAUCHI

    • by Anonymous Coward

      書こうと思ったら既に書かれていた

  • by jizou (5538) on 2013年05月02日 15時00分 (#2374266) 日記

    64bitになってメモリ空間が圧倒的に広くなったので、こういう構造もやりやすくなったんでしょうかね。
    # メモリ容量が増えてくると、逆に戻ったりするんだろうか。
    ストレージも含めて、一つの空間にマッピングできるのは愉しいかもしれない。

    で、GPUと、CPUでエンディアンが逆だった.... なんてオチがつきませんように。

  • by Anonymous Coward on 2013年05月02日 13時04分 (#2374163)

    ゲームの画像メモリをちまちまと書き換える作業が始まるお…

    • Graphics Processing Unitとは言うものの、グラフィック/ゲーム用とは限らない。
      今回のは処理の高速化、ひらたくいえばスパコン的な用途を想定しているのでは?

      もしそうなら、
      「大量データ(全メモリ+仮想記憶)を使った高速演算が、今までより楽になりますよ」
      が売りになるのはアリだと思う。

      親コメント
      • GPGPUすると、計算元のCPUのDRAMと大量計算するためのデータを置くGPUのVRAMが遠くて性能を上げにくいボトルネックになり易いのでその辺に効くのでしょうね。
        統合だとそれこそ同じデータをあっちこっちにコピーしなおしてる訳で無駄な処理ですしねぇ
        ディスクリートだとPCI-E経由しないといけないから統合GPUで出来る裏技かしらね。
        将来的に本気で速度出すなら統合側で下処理して、ディスクリートで本処理みたいな役割分担とかにもなるのかな?

        親コメント
  • by Anonymous Coward on 2013年05月02日 13時15分 (#2374170)

    大昔に出てたインテルの i810 チップセットもメインメモリとビデオメモリを共有してなかったっけ?
    性能は段違いだろうけど。

    • by s02222 (20350) on 2013年05月03日 10時04分 (#2374639)
      あれは、メインメモリの端っこをチップセットの機能としてどちらかというとハードウェアレベルで切り離してVRAMとして扱う、みたいな話じゃなかったかと。

      ちょっと変な例えだけど、大ざっぱなイメージとしては、CPU上で動作してるプログラムがメモリの0x0000...0000番地から0xffff...ffff番地までアクセスすると途中でVRAMが出てくるかどうかの差じゃないかな。 今回のhUMAとか、古くはPC9801とかだとVRAMに触れる。

      i810の方式の場合は、その方法ではVRAMには触れない。VRAMに割り当てた分はシステムから切り離されてCPUから見ると行方不明となる。 切り離された分は、GPUにぶら下げられてそっちで使われる。

      実際にはページングやら何やらと、間に挟まるのでこの通りではないんだけど。
      親コメント
    • by Anonymous Coward

      そのころのは、メインメモリからBIOSレベルで予約しちゃってたから、OSのメモリ表示から減ってた(=OS管理外)けど、
      今回のはOSの管理上のメモリに動的に設定したり、CPUからVRAMに割り当てられたところを直接塗りつぶしたりスワップできるように見える。

    • by Anonymous Coward

      ただでさえ狭いメモリ帯域(当時はPC100くらい?)をビデオに食われて、散々だったあれですね。
      あれから数年間はチップセット内蔵ビデオ不信で、とりあえず適当なカードをAGPに刺してました。

  • by Anonymous Coward on 2013年05月02日 13時33分 (#2374186)

    かなりコストかかるような気がします。直感的には

  • by Anonymous Coward on 2013年05月02日 13時41分 (#2374195)

    IntelのCoreシリーズとためをはれるCPU作って欲しい。
    しばらくぶりにIntelに転んでしまった。

    • by Anonymous Coward

      それができないから小技に走ってるんでしょう…
      察してあげてくださいよ

      • by Anonymous Coward

        まあでも次の展開がインテル一人勝ちではなさそうなところが面白いわけですが

  • by Anonymous Coward on 2013年05月02日 14時23分 (#2374242)

    結局GPU側にページテーブル持てるようにしました。キャッシュのコヒーレンシをCPUと同様にできるようにしました。の2つかな。
    前者はつければ済む話の気はする。GPUで記述することのできるプログラムがページテーブル操作をどれだけできるのかは知らないけど。
    後者はCPU側のキャッシュさえも意識しないで済むようになってるのならだいぶ楽になるんでしょうね。
    メモリは共用できてもIOバスへのアクセスはできないんだろうなぁ。IOMMUを設定しておけばデバイス扱いで行けるか?

  • by Anonymous Coward on 2013年05月02日 15時17分 (#2374279)

    CPUのメモリからテクスチャデータなどをVRAMに転送しなくてもいいのがメリットの一つじゃなかったでしたっけ?

  • by Anonymous Coward on 2013年05月02日 15時22分 (#2374284)
    CPUとGPUが別々の言語でプログラムしてるとか一本化は当然の流れだと思う
typodupeerror

人生unstable -- あるハッカー

読み込み中...