蘋果最新推出的 Metal 圖形介面未來有沒有可能與微軟的 DirectX 抗衡？
Metal 的移植性和 OpenGL 相比如何，要放到整體的環境中去考慮。一般來說，目前的 GPU API，不管是 OpenGL，還是更接近底層的 DirectX、Vulkan、Metal，都不可能在其上直接去寫更高層的邏輯。而是必須先建立一個抽象程度更高的封裝層。
這點和一般的 toolkit API，比如 Cocoa、MFC、Qt 是不一樣的。在 toolkit API 上直接寫 app 邏輯當然不是最好的設計，但是作為一些 quick and dirty 的東西，撐上一下還是可以的，甚至很多功能比較豐富，而且維護良好的長期項目也沒有很厚的 API 抽象層。反過來看，直接在 GPU API 上寫 quick and dirty 的東西都應付不了，肯定是一寫就亂，必須先寫一個封裝。所以用 toolkit API 的思維去討論 GPU API 的可移植性是會有偏差的。
一開始別說你我，整個業界也沒有意識到這種偏差，所以討論起 OpenGL 以為是一個可以和 Qt、socket、POSIX 相提並論的東西。後來發現不是那麼回事。關於這一點，有人看出來比較早，比如 The Saint - Personal Technology Blog of DirectX co-creator and WildTangent founder, Alex St. John 的作者。後來 Apple 談起來為什麼搞 Metal，基本上也是認識到了這一點。
既然終歸要有一個封裝層，那麼 API 本身的 cross-platform 就沒那麼重要了。而且要維護 API 本身的 platform neutrality 是需要代價的。要養個委員會，平衡各家廠商的利益，忍受龜速迭代發展。通俗的說，這些代價本身跟養一個 Unreal 系統來比不見得便宜。
而現在遊戲在 Mac 上的狀態，是由 API，硬體，driver 一起決定的。Metal 在 Mac 上比 OpenGL 在 Mac 上優秀，和 Mac 的遊戲現狀與 Windows 相比，這不是一個正確的比較。從 Mac 自身來比較，引入 Metal 前後是不是有改善也不是 Metal 一個 API 能完全決定的。
OpenGL移植難度高，說的是同樣用的OpenGL，不同廠商的硬體上需要分別debug。也就是一次開發，到處debug。（跟java一樣）
Metal的話，就不叫移植難度高了，因為根本無法移植。需要到處開發，到處debug。
所以說，一個根本沒法移植而且開發難度超高的東西，和一個開發難度不高移植有風險的，沒法比。
主流遊戲不上mac是因為mac佔有率實在太低了啊。跟API沒關係。WP和Windows的API一樣，也沒看到主流遊戲啊。
剛在Dx下優化完美顏演算法，來一個個回答一下2邊的體驗和問題：1.Opengl移植難度大，性能跟N卡A卡驅動層有關係，但是總體使用感覺是Dx在N卡下比Opengl 要高效很多，最簡單的是寫個程序，試著讀GPU里的數據到cpu，你就能體會到了。這個同樣適用於Opengles。總體感覺是Metal近似於Dx&>Opengl/Opengles
2.主流遊戲移植到Metal的比較少，這個怎麼說？我覺得很多自從A8以來，大多都做了Metal優化，比如Cocos2d，虛幻引擎。app也有一堆如爐石等等。。。這些應該很有名吧。如果你otool一下app，grep一下metal關鍵字，還是能看到一堆遊戲已經metal化了。3.至於Metal與Dx比較，我覺得不能一概而論，Dx在windows平台始終是最強的（綜合起來看，在渲染，並行方面），但在移動端Metal依託的ios平台本身就比其他平台性能高不知多少，這個沒有可比性。4.反正，Opengl這個坑，被填完是遲早的。。。否則福爾康同志也不會被android著急上。。。
未來有可能追上，但希望不大為什麼？因為 DirectX 的生態鏈非常良好，工具、教程、庫之類很容易找，經過那麼多年的發展也比較成熟，Metal 作為一個新的API，和 vulkan一樣，需要發展
蘋果先把自家iOS模擬器對Metal的支持解決了再說吧。GL移植難度高是驅動問題。明明在N卡上work的好好的到了A卡上就出bug，而且不同A卡出得bug還不一樣。但是就是這麼爛遊戲廠商也得做，不然用戶會罵遊戲廠商而不是顯卡。如果沒有這個問題直接換系統編譯一遍就好了嘛。
DX移植Metal是得整個重寫一遍。值不值得拿出人力物力去做就是一個問題。
推薦閱讀：