唉。死不悔改,而且一錯再錯。
首先,問題是錯的。我在另一個貼文裏
Windows 10 給 Linux 子系統寫顯卡驅動的是一個人嗎,是誰呢?提到的是Direct3D9/11的驅動,是給Drawbridge寫的,而不是Linux子系統。他們在發展上有個先後的關系,但不是一個東西。題主對此完全一知半解的情況下,不仔細看就斷章取義,實在太胡攪蠻纏。
其次,不擼兔子的說法,基本每個點都是錯誤的。
「parrallels的虛擬顯卡最多只是把OpenGL呼叫轉發到宿主機上。「
不,那麽做行不通。(甚至parallels都拼錯了)
」Linux子系統和Windows子系統在內核看來是同等地位的。應該不需要搞這套東西才對。」
不,Linux子系統在Picoprocess裏。Linux子系統和Windows本身是guest和host的關系。
「不提供CUDA真正的原因肯定不是不想做。而是已經做好了」
不,根本沒寫。而且如果你懂CUDA的話,就知道轉API容易,難點是視訊記憶體存取和管理。
「只是把Library OS裏面的呼叫轉發到外面。「
不,那麽做行不通。
好了,現在我就來說說為什麽直接把API呼叫轉到外面行不通。會有很多細節,像題主和不擼兔子這樣沒做過的人根本不會了解。
1. 流量。
API呼叫看似簡單,只要把所有的API都轉出去,就行了。原先遠端桌面就是這麽做的。但缺點是,API呼叫所要消耗的流量遠大於在驅動層搞。舉個例子,把同一個設定狀態呼叫兩次,你就得在API層轉兩次。最多就是cache一下,把變化的傳了。而在D3D的體系裏,有runtime做狀態管理,只會把真正修改了有起作用的狀態往下傳給驅動,並會做嚴格的狀態驗證。所以在驅動層,你所需要轉的數據遠少於API層。
2. 出錯控制。
如果執行過程出了嚴重問題,你需要的是不讓host crash,最多讓guest crash。如果從API層走,那麽這件事情無法避免。如果guest裏有多了個驗證,就會把錯誤留在子系統,而不會傳出來。
3. bug-to-bug相容
如果只是API層,那麽要求guest和host的runtime完全一致,才可以保證100%相容。而從驅動走,runtime是在guest,那麽只要都符合WDDM,就沒問題。guest和host的runtime可以解耦。
4. 什麽是驅動。
驅動不在於你怎麽實作,你是直接去真實硬件,還去了虛擬硬件。只要是按照驅動的規範實作、編譯、部署,系統看到的是個器材,那就是驅動。我給Drawbridge寫的第一版,是可以在普通的Windows上裝的,你能在裝置管理員裏看到多了一塊顯卡,程式可以在上面建立器材,進行渲染。(由於沒有實作電源管理的部份,在休眠後會睡死)
這裏放一張WDDM的架構圖。驅動需要實作的是user-mode display driver(UMD)和Display miniport driver(KMD)。OpenGL installable client driver屬於可選。