龔神給微軟Linux子系統寫的支持DirectX9、11的代碼到底屬不屬於「驅動」?

唉。去世不改過，並且一錯再錯。

其次，不擼兔子的說法，根本每個點都是錯誤的。

「parrallels的假造顯卡最多只是把OpenGL調用轉發到宿主機上。「

不，那麼做行不通。（乃至parallels都拼錯了）

」Linux子體系和Windows子體系在內核看來是劃一職位地方的。應該不必要搞這套東西才對。」

不，Linux子體系在Picoprocess里。Linux子體系和Windows本身是guest和host的干係。

「不提供CUDA真正的緣故起因肯定不是不想做。而是已經做好了」

不，底子沒寫。並且要是你懂CUDA的話，就知道轉API容易，難點是顯存訪問和辦理。

「只是把LibraryOS內里的調用轉發到表面。「

不，那麼做行不通。

好了，如今我就來說說為什麼直接把API調用轉到表面行不通。會有很多細節，像題主和不擼兔子如許沒做過的人底子不會相識。

1.流量。

API調用看似大略，只要把全部的API都轉出去，就行了。原先長途桌面便是這麼做的。但缺點是，API調用所要斲喪的流量宏大於在驅動層搞。舉個例子，把同一個設置狀態調用兩次，你就得在API層轉兩次。最多便是cache一下，把變革的傳了。而在D3D的體系里，有runtime做狀態辦理，只會把真正修改了有起作用的狀態往下傳給驅動，並會做嚴格的狀態驗證。以是在驅動層，你所必要轉的數據遠少於API層。

2.墮落控制。

要是運行進程出了緊張題目，你必要的是不讓hostcrash，最多讓guestcrash。要是從API層走，那麼這件事變無法剋制。要是guest里有多了個驗證，就會把錯誤留在子體系，而不會傳出來。

3.bug-to-bug兼容

要是只是API層，那麼要求guest和host的runtime完全同等，才可以包管100%兼容。而從驅動走，runtime是在guest，那麼只要都切合WDDM，就沒題目。guest和host的runtime可以解耦。

4.什麼是驅動。

驅動不在於你怎麼實現，你是直接去真實硬體，還去了假造硬體。只要是根據驅動的範例實現、編譯、擺設，體系看到的是個配置，那便是驅動。我給Drawbridge寫的初版，是可以在平凡的Windows上裝的，你能在配置辦理器里看到多了一塊顯卡，步伐可以在上面創配置置裝備擺設，舉行渲染。（由於沒有實現電源辦理的部分，在休眠後會睡去世）

這裡放一張WDDM的架構圖。驅動必要實現的是user-modedisplaydriver（UMD）和Displayminiportdriver（KMD）。OpenGLinstallableclientdriver屬於可選。

從這張圖也可以看到，你要是從API層面轉（也便是D3Druntime和OpenGLruntime），那麼體系並不會以為你是個配置，也沒法根據體系的範例去利用你這個配置。那就不是個驅動，也沒法實現完備的成果。

另一個緊張題目是，GDI的部分你怎麼辦。GDI是直接調用win32k，win32k又會通過dxgkrnl去調用KMD。難道想連GDI都一起轉出來？

到了Android上，環境會更遭。Android的驅動介面和OpenGLES很像，以是從外貌上看，從驅動層和從API層區別不大。但遭就遭在差別的那一點點。起首是體系有一些私有介面，只有surfaceflinger等android體系內會調用，而host不會有對應的。這得在驅動里辦理。第二，android上的顯存辦理是由驅動做的，不但host沒有對應，其他配置也會直接調用顯存辦理做一些事變，比如說攝像頭。這都不大概通過API層面實現。必須提供一個驅動讓體系利用。

總的來說，比起API層，驅動層至少要有狀態辦理和commandlist，以及大概要有顯存辦理。這些，我寫的驅動里都有。

5.怎樣傳輸數據

不要以為host和guest都在一台電腦，傳輸數據就很容易。圖形的東西數據量之大，API調用次數之多，都是遠遠高出其他方面的API的。還要思量異構（CPU和GPU）上的耽誤，傳輸數據這方面底子不trival。

前面提到的commandlist，便是一部分必做的事變。要是來一個API調用，就穿一次，即便memcpy也受不了。更好地實現是放到一個列表，只有在某些必要同步的調用下才把整個commandlist發送出去。我的實行是，用和沒用，性能差6倍。另一方面是對付大塊的數據，紋理、vb，host和guest之間怎樣直接映射，淘汰拷貝而又不影響寂靜性，這都是得思量的事變。

以上這幾點不但對D3D有效，對OpenGL/OpenGLES也有效。換句話說，不管什麼體系，都應該在驅動層，而不是API層做這件事變。不然去世路一條。

而在CUDA方面，更難處理懲罰。由於不像D3D/OGL，texture和buffer這些都是用封裝過後的形態表現（D3D用的東西，OGL用的id），只要創建一個host和guest的映射，之後在上面的操縱就能連上。CUDA內里你可以申請一塊顯存，接著就用指針到處指了。以是必要細緻做全顯存全部權闡發和數據映射。這些題目別說辦理，連發明都不容易。

少年，你們仍舊對力氣一竅不通。