ユニファイドメモリアーキテクチャ
ユニファイドメモリーアーキテクチャ(英: Unified Memory Architecture、UMA)は、メインメモリーをCPUだけでなく、他のデバイスにも共有して使用するメモリーアーキテクチャの一つである。まれにUniversal Memory Architectureと表記されることもある[1][2]。
概要
編集この節は世界的観点から説明されていない可能性があります。 (2023年10月) |
この方式は、古くはNECのPC-8001で実装された。メインメモリーの一部をVRAM(ビデオメモリー)の一部として扱い、CRTC(CRTコントローラー)にDMA転送することで、画面を表示していた。DMAが動作中CPUはメモリーバスの使用権を失い、画面表示中はCPU本来の能力を発することができなかった。そこで計算などの用途においてDMAを停止し、CPUがメインメモリーをフルにアクセスできるようにすることが一般的だった。この手法は後に、PC-8800シリーズでも使用された。
現代のこの方式の応用もまた、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の中でもさらに統合が進み、CPUとGPUがメモリーマップまで統合されている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環境ではそのまま扱えるようになる。
API側のUMA対応
編集前述のように、従来型のUMAでは、CPUとGPUのメモリー空間が異なるため、たとえ同一の物理メモリー上に存在するデータであっても、お互いに直接読み書きすることができず、データ転送が必要になってしまう。データ転送処理にはDirect3D(DirectX)あるいは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]。UMA環境では、(GPUなどの)デバイス固有のルールに従ってこれらを利用することで、バッファ読み書きの際にコピーが不要となる「ゼロコピーバッファー」を実現することができる可能性がある。例えばIntel Graphicsでは、4096バイト境界でアライメントされ、64バイトの倍数のサイズを持つ既存のメモリー領域をバッファとして使うことで、ゼロコピーバッファを実現することができる[12]。ただし実装依存であり、UMA環境だからといって必ずしもゼロコピーバッファになるとは限らない。
OpenCL 2.0では、共有仮想メモリー(Shared Virtual Memory, SVM)の機能が追加され、ホストとデバイスで仮想メモリー空間を共有できるようになった[13]。SVMにより、UMA環境ではゼロコピーが実現できるようになるだけでなく、ポインタを使用した複雑なデータ構造をデバイス側で利用することもできるようになる[14]。
Direct3D
編集Microsoft Windows 10で追加されたDirect3D 11.3および12では、UMA環境の場合は冗長なコピーを減らすことのできる機能を持つ[15][2]。Direct3D 12では、通常のUMAとキャッシュコヒーレントなUMAを区別することもできる[16]。
Metal
編集AppleのMetal APIでは、単一の仮想メモリー領域内に存在する、アライメントされたメモリーアドレスを使って、データをコピーすることなく既存のメモリー領域をラップするMTLBuffer
オブジェクトを直接生成することができる[17]。また、Metalではリソース生成時にMTLStorageMode.shared
を使用することで、CPUとGPUがシステムメモリー内に割り当てられたリソースへのアクセスを共有できるが、共有メモリーを使用するリソースに対して、CPUまたはGPUのどちらかでスケジュールしたすべての変更処理が、もう片方のプロセッサ上でのリソースアクセスが発生する前に完了されなければならない[18]。つまり、MTLBuffer.contents()
を使って直接ポインタを取得して共有データを読み書きすることはできるものの、任意のタイミングでCPU/GPU間のメモリー一貫性が保証されるわけではなく、ソフトウェア側の配慮が必要となる。
Apple Silicon
編集2020年にAppleは、従来からiPhoneやiPadなどで採用されていたARMアーキテクチャベースのApple製SoCを、Macコンピュータにも採用するにあたって、Appleシリコンという総称で再定義した[19][20]。2020年末以降は、MacでもIntelのx86ベースプロセッサに代わって、Apple M1のようなApple SoCが搭載されるようになった。これらのApple SoCではUMAが採用されているが、Apple Silicon GPU環境におけるMetal APIでは、CPUとGPUとで共有可能なMTLBuffer
とMTLTexture
を生成することができる[18]。これによりゼロコピーを実現することができ、パフォーマンスと効率が向上する[21]。従来のIntelプロセッサを搭載したIntel Mac環境でも統合GPUに関してはUMAとなっており、MTLBuffer
に関しては共有モードを利用できるものの、MTLTexture
に関しては共有モードを利用できなかった。
なお、Apple GPU環境であっても、すべてのリソースに対して共有モードを設定するのではなく、リソースアクセスの傾向に応じて適切なストレージモードを選択する必要がある[22]。
脚注
編集- ^ Illustrated parts catalog | HP® Customer Support
- ^ a b UMA Optimizations CPU Accessible Textures and Standard Swizzle - Win32 apps | Microsoft Learn
- ^ Windows 7 ベースのコンピューターで使用可能なメモリが搭載されているメモリより少ない - Microsoft サポート
- ^ インターネットマガジン バックナンバーアーカイブ 1997/10
- ^ Insider's Computer Dictionary:UMA (Unified Memory Architecture) とは? - @IT
- ^ Insider's Computer Dictionary:UMA (Uniform Memory Access、Uniform Memory Architecture) とは? [マルチプロセッサ] - @IT
- ^ a b 米田聡 (2013年4月30日). “AMD,次期主力APU「Kaveri」で対応する新技術「hUMA」を発表。CPUとGPUが同じメモリ空間を共有可能に”. 4Gamer.net. 2013年7月13日閲覧。
- ^ 【後藤弘茂のWeekly海外ニュース】CPUとGPUのメモリ空間を統一するAMDの「hUMA」アーキテクチャ - PC Watch
- ^ News – Heterogeneous System Architecture Foundation
- ^ HSA Foundation | GitHub
- ^ clCreateBuffer | OpenCL 1.0 Specification
- ^ OpenCL* 1.2 の活用: インテル® プロセッサー・グラフィックスでバッファーコピーを最小限に抑えてパフォーマンスを向上する方法 | iSUS
- ^ OpenCL 2.0勉強会#1:Shared Virtual MemoryなどのOpenCLのバッファー関連まとめ - Fixstars Tech Blog /proc/cpuinfo
- ^ OpenCL™ 2.0 Shared Virtual Memory Overview
- ^ Unified Memory Architecture - Win32 apps | Microsoft Learn
- ^ D3D12_FEATURE_DATA_ARCHITECTURE (d3d12.h) - Win32 apps | Microsoft Learn
- ^ makeBuffer(bytesNoCopy:length:options:deallocator:) | Apple Developer Documentation
- ^ Apple、MacにAppleシリコンを搭載することを発表 - Apple (日本)
- ^ 「iPhone」「Mac」など全製品でApple Silicon採用、使い勝手を仮想体験 | 日経クロステック(xTECH)
- ^ Apple at Work - M1の概要
- ^ Choosing a Resource Storage Mode for Apple GPUs | Apple Developer Documentation