硬科技:GPU虛擬化為何超級難搞(上)

2020.10.21 04:51PM
10620
照片中跟英偉達有關,包含了英偉達、索泰GeForce GTX 660 NVIDIA、NVIDIA GeForce GTX TITAN系列、GeForce GTX 660 Ti、英偉達

筆者很久以前用了6篇文章,簡單解釋x86電腦虛擬化的困難之處與解決方案,但留下了1個尚未完成的結尾:相較於「比較單純」的CPU,「GPU虛擬化」更是個值得大書特書的複雜議題,絕對只有站在時代浪頭的科科們才有權獨享。

所以筆者試圖用僅僅3篇的規模,簡單解釋GPU虛擬化究竟有哪些棘手的挑戰。為了避免混淆,相關術語(Terminology)也優先採用VMware和NVIDIA的東西,畢竟十幾年的光陰過去了,在這個領域的領導者,依舊是他們2家。

硬科技:為何x86的虛擬化這麼難搞(上)
硬科技:為何x86的虛擬化這麼難搞(中)
硬科技:為何x86的虛擬化這麼難搞(下)
硬科技:x86虛擬化由內到外還是繼續難搞(上)
硬科技:x86虛擬化由內到外還是繼續難搞(中)
硬科技:x86虛擬化由內到外還是繼續難搞(下)

在遙遠的20年或更早之前,就應用層面來看,顯示卡就像隻荒野孤狼,某個應用程式一旦要上下其手,如執行亟需3D運算資源的遊戲,就得全權佔有,油門踩到底,再加上過去缺乏統一的3D API規範與相對應的GPU指令集架構,形同作業系統眼中的化外之民。

VMware曾在2005年4月,首度在其Workstation 5.0加入實驗性(不保證穩定度和性能表現)3D虛擬化功能,2008年導入於Workstation 6.5和Fusion 2.0的SVGA,則是首次嘗試GPU共享虛擬化。後來被Oracle併購的Sun,其以功能強大又免費而著稱的VirtualBox,到了2009年6月的3.0版,才有比較像樣(但毛病還是不少)的DirectX 8/9和OpenGL 2.0支援度。

照片中提到了Virtual Graphics Stack、App、VMware SVGA Driver,包含了組織、的VMware、虛擬化、虛擬機、I / O虛擬化

就算不提虛擬機,作業系統要「充分掌握」GPU也是一件難事。其實2006年底的Windows Vista有一件少人記得的大事:將繪圖記憶體納入分頁(Paging)管理機制。為何微軟當時要這樣做?因為導入3D化的GUI後,意味著將會有大量應用程式須同時使用顯示卡,多工作業系統絕對有直接管理顯示記憶體內容的必要性,這就是Windows Vista之後,華麗的Flip 3D介面的技術基礎。

更進一步,各位科科可用力回想一件事:Windows是何時才能在工作管理員,看到GPU每個在驅動程式層面、由不同功能模組化身的不同引擎(Engine)?答案是Windows 10秋季創作者更新1709版本,足足是Windows Vista上市的10年之後,還發生過使用率測不準的狀況,這也充分證明了,要讓GPU可被作業系統或虛擬機Hypervisor完全掌控,困難度究竟有多高。

那麼,GPU虛擬化到底是哪裡難搞?原因很複雜也很簡單。

一、不像CPU,GPU並沒有統一的指令集標準,即使單一廠商的歷代產品之間,也是天差地遠(到了AMD的GCN和NVIDIA的Fermi後,才算「勉強」大致穩定下來),硬體規格的混亂度就更不用講了,配合持續推陳出新的3D API,GPU的硬體架構演進,遠比CPU迅速且激進,歷代GPU架構幾乎各自有其獨特的執行狀態格式,硬體底層的技術細節更是高度商業機密,外人難以一窺其全貌。

照片中提到了RADEON™ ARCHITECTURAL ADVANCES、OF PROGRAMMABLE GRAPHICS、PRE 2000,包含了進化架構和、迪蘭恆進Radeon RX 5700 XT、AMD Vega、Advanced Micro Devices公司、AMD公司

也因此,套句VMware的說法,GPU的驅動程式本質上也是1套編譯器(Compiler),管你GPU硬體採用哪種阿貓阿狗怪異指令集,將中間碼(Immediate)編譯成符合3D API規範的二進位執行檔即可,所以科科一定不難理解,為何指令集層面的Bug會造成CPU的大麻煩,但GPU卻有機會用驅動程式「蓋掉」的道理,你有聽說過那顆x86 CPU需要先安裝驅動程式才能開機的嗎?

照片中提到了Unique challenges、• API、The OpenGL IMachine,包含了角度、產品設計、產品、儀表、線

順便一題,要如何「因應來自於客戶的強烈要求,開源繪圖驅動程式,並隱藏硬體架構細節」,也是擺在NVIDIA和AMD眼前的大難題。假以時日,這2間廠商的旗艦GPU都偷偷塞了顆可自我開機的ARM指令集相容處理器(筆者故意不點破,請各位科科細細思量),也不是太讓人感到意外的發展。

二、如同多工作業系統,高效能的虛擬化奠基於「可迅速收集系統運行狀態資訊,並高速切換執行內容」,這也是科科們應當熟悉的x86 CPU虛擬化的基本原理:作業系統教科書絕對會提到的Context Switch。

但這些年來,因水漲船高的可程式化,3D API與其定義的繪圖管線,複雜度也持續破表,動輒數百個程式進入點和不同的程式語言規範,加上GPU在硬體實作層面帶來的龐大運算單元規模、如紡紗機般千絲萬縷的多重執行緒、數以萬計的資料暫存器檔案,都讓GPU能像CPU一樣的「換位子馬上跟著換腦袋」成為不可能的任務。

淺談GPU到底是什麼(上):不同的運算型態
淺談GPU到底是什麼(中):兼具SIMD與MIMD優點的SIMT
淺談GPU到底是什麼(下):走向汎用化的GPGPU

別的不提,在2008年,也就是VMware發表 ”GPU Virtualization on VMware’s Hosted I/O Architecture” 一文並公佈SVGA之時,那時最具代表性的旗艦GPU是14億電晶體的NVIDIA GTX280(CPU則是將近3億電晶體的Intel Core 2 Duo “Penryn”)。

照片中提到了How much computation?、NVIDIA GeForce GTX 280:、1.4 billion transistors,包含了中央處理器、GeForce 200系列、中央處理器、英偉達、圖形處理單元

根據VMware的說法,那時的GPU硬體狀態的紀錄資訊量就是 “GB” 等級,切換「整顆」GPU的Context Switch的時間成本之高,完全讓人連想都不敢想。反觀Intel的Penryn,包含全部指令集架構(如暫存器的資料)和大多數處理器微架構(像執行單元的內容),1個CPU核心的狀態也只不過需要8kB而已,根本天差地遠。結果就是CPU的Context Switch或虛擬機切換,可能僅僅需要幾個ns,GPU卻是好幾百個ns甚至上看ms,這也讓虛擬GPU的調度策略,變成1個難搞的議題。

不過俗語說的好,出來混的,總是要還,既然時下已經四處可見所謂的「雲端GPU」,這10幾年來各家廠商也是一步一腳印的見招拆拆、提出解決方案,而VMware早在2008年就確立了GPU虛擬化的技術走向,遠比很多人認知中的時間點,還要早很多年。科科。

資料來源

0 則回應