Unified_Memory_Architecture
[Wikipedia|▼Menu]
.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%;font-size:90%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}html.client-js body.skin-minerva .mw-parser-output .mbox-text-span{margin-left:23px!important}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}

この記事は検証可能参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方
出典検索?: "ユニファイドメモリアーキテクチャ" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL(2015年3月)

ユニファイドメモリアーキテクチャ(: Unified Memory Architecture、UMA)は、メインメモリCPUだけでなく、他のデバイスにも共有して使用するメモリアーキテクチャの一つである。まれにUniversal Memory Architectureと表記されることもある[1][2]
概要

この節は世界的観点から説明されていない可能性があります。ノートでの議論と記事の加筆への協力をお願いします。(2023年10月)

この方式は、古くはNECPC-8001で実装された。メインメモリの一部をVRAM(ビデオメモリ)の一部として扱い、CRTC(CRTコントローラー)にDMA転送することで、画面を表示していた。DMAが動作中CPUはメモリバスの使用権を失い、画面表示中はCPU本来の能力を発することができなかった。そこで計算などの用途においてDMAを停止し、CPUがメインメモリをフルにアクセスできるようにすることが一般的だった。この手法は後に、PC-8800シリーズでも使用された。

@media screen{.mw-parser-output .fix-domain{border-bottom:dashed 1px}}現代のこの方式の応用もまた、VRAMをメインメモリにマッピングする場合に用いられていることが多い。このアーキテクチャがパーソナルコンピュータ (PC) に適用されたときは、CPU本来の性能を発揮できないことから嫌われた。そこでCPU動作速度の低下を避けるため、メモリバスの周波数をCPU本来のバス周波数より高く設定し、CPUからのメモリアクセスをさまたげないよう工夫されるようになった。CPUがメモリにアクセスする際にグラフィックスコントローラー(のちのGPU)は目的の演算を遅延することから、表示にジッターが現れることが多かった。後にこれはメモリアクセス方式を工夫したり、あるいは最終的に画面表示に使うメモリのみを、グラフィックスボード(ビデオカード)に搭載したりすることで解決した。しかし、さらに時代が下って再び採用され始める。PCに限らずワークステーションでも一般的であった。3Dアクセラレーターにおいて、VRAMだけでなくテクスチャメモリ(テクスチャマッピング用の画像データを保持するメモリ)、イメージキャプチャ結果を保持するメモリとしても使われた。[要出典]

メモリがモジュールとして増設が簡単になり、単価も下がるにしたがい、32bitアドレスのメモリ空間の上限である4GBなども普通に実装できるようになったが、ハードウェアの予約されているメモリ番地はメモリがリニアに使えない。そのうえ、UMA方式に割く場合はさらにビデオ回路用として実メモリを用いるので、32bitモードで動かす場合にはその部分がさらに削られる。もっとも、32bitオペレーティングシステム (OS) では、独立したビデオカードを搭載する場合であってもビデオメモリは最初の4GBのアドレス空間内にマッピングされる必要があるため、ビデオメモリの量だけOS側(ソフトウェア側)で利用可能なシステムメモリの総容量が減少する[3]。つまり32bit OS環境では、大容量のビデオメモリを搭載するビデオカードはむしろシステム全体の性能を低下させることになる。

なお、かつてSGIが、高帯域幅のUMAを採用したSGI O2(英語版)と呼ばれるワークステーション製品を手掛けていたことがあった[4]

UMAのメリットの一つは、グラフィックス専用のメモリが不要になるため、コストダウンが実現できることである[5]。エントリモデルのデスクトップPCやノートPCでは、独立したグラフィックスボードやGPU (dGPU) を搭載せず、マザーボード上に実装されたオンボードグラフィックスあるいはCPUに内蔵されたGPU (iGPU) を利用することが多い。スマートフォンタブレット、ゲーム専用機などに搭載されているSoCは、CPU・GPU・メモリ・周辺回路などを1チップ(1パッケージ)に統合している。いずれもVRAMは搭載せず、メインメモリをCPUとGPUとで共有するUMAとなっている。

UMAのデメリットは、パフォーマンスがメモリに律速され、各々のプロセッサの能力を最大限に活かすことができない可能性があること、また拡張性に乏しいことである。例えばグラフィックスボードに実装されるVRAMには帯域幅の大きいGDDR系メモリやHBMが使われることが多いが、UMAでは通例DDR系メモリとなるため、GPUの性能を活かしきれない。また、CPUと比較すると、並列化しやすいGPUは半導体プロセスルールの微細化に伴う性能向上率が高く、旧製品の性能陳腐化が激しいが、UMA環境ではグラフィックスボードだけを交換・増設して性能を向上させるようなことができない。メモリも統合されたSoCの場合は、メモリだけを後から交換・増設することができない。
NUMA

複数のCPUが共有するメインメモリにアクセスする対称型マルチプロセッサにおいて、そのメモリアクセスのことを「Uniform Memory Access」と呼ぶ[6]。この言葉はNUMA(Non-Uniform Memory Access)ではないことを強調して指す言葉であり、あまり一般的ではない[要出典]。

従来型のPCアーキテクチャやSoC、Xbox 360などでUMAと呼ばれているアーキテクチャは、あくまでもメモリの部品としての共用であり、CPUとGPUのメモリマップ(メモリ空間)までは統合されていない。これはUMAの中でもNUMAとして分類される[7]。従来型のUMAでは、CPUとGPUはそれぞれのメモリ空間に存在するデータをお互いに直接共有・読み書きすることができず、都度データ転送(コピー)が必要になる。
hUMA

ヘテロジニアス・ユニフォームメモリアクセス (heterogeneous Uniform Memory Access) とは、UMAの中でもさらに統合が進み、CPUGPUがメモリマップまで統合されているUMAのことを指す。AMDがHSA (Heterogeneous System Architecture) の鍵となる技術の一つとして発表した[7]

CPUとGPUで同じメモリマップを共有しているということは、必然的にGPU側もページフォールトに対応し、MMUで仮想メモリ管理が可能となっていることになる。また、hUMAではCPUとGPUのメモリ一貫性(メモリコヒーレンス/メモリコヒーレンシ)がハードウェアレベルで確保されており、CPUとGPUが扱うデータの一貫性や同期をソフトウェア側で気にする必要がなくなる[8]。これはGPUを汎用目的に利用するGPGPUにおいて大きなメリットとなる。

つまり、hUMA環境において、あるメモリアドレスは、CPUやGPUにかかわらず同じアドレス空間内の同じメモリ番地を指すということである。一見当たり前の話に聞こえるが、hUMAではない従来型のUMAではメモリという部品を容量で用途別に分けあっているだけなので、CPUとGPUで異なるアドレス空間を持ち、それぞれ個別にアドレスが振られているうえにメモリ自身もあくまで別物扱いである。それゆえに例え同じアドレス値であっても、CPU用のアドレスとGPU用のアドレスでは全く別のメモリ番地を指している。CPUとGPU間(これは、PCにおいては同時にマザーボードビデオカード間をも指す)に接続されたバスを通して転送するしか、両者間でデータのやりとりは不可能である。しかし、先述の通りhUMAの場合は単純に同じアドレスのメモリ領域でデータを読み書きするやりとりだけで済み、ソフトウェアによるデータ転送の手間が省ける。また、2023年現在においても、GPUではCPUのようにポインタあるいは参照を駆使した複雑で柔軟なデータ構造を直接扱うことができず、GPU向けにいったん分解や再構築が必要となるが、hUMA環境ではそのまま扱えるようになる。

なお、HSA規格を管理しているHSA Foundationの活動は、2020年を最後に止まっている[9][10]
API側のUMA対応

前述のように、従来型のUMAでは、CPUとGPUのメモリ空間が異なるため、たとえ同一の物理メモリ上に存在するデータであっても、お互いに直接読み書きすることができず、データ転送が必要になってしまう。データ転送処理にはDirect3DDirectX)あるいはOpenGLのようなグラフィックスAPIや、CUDAあるいはOpenCLのようなコンピューティングAPIを利用するが、このコピー処理および同期にかかるコストは、特にGPUの演算結果をCPU側で読み出して利用する場合にボトルネックとなる。しかし先進的なAPIの中には、UMAに対応した最適化機能を持つものも存在する。
OpenCL

OpenCLのclCreateBuffer()のflags引数にCL_MEM_USE_HOST_PTRまたはCL_MEM_ALLOC_HOST_PTRを使用することで、ホスト(CPU)側に割り当てられたメモリをバッファとして使用できる[11]


次ページ
記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:24 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef