跨越OpenGL和D3D的鴻溝(一) 開篇

2021-06-07 01:01:52 字數 1374 閱讀 1520

有人說,opengl直接調到驅動,效能高於d3d。

有人說,shader都得寫兩套,很麻煩。

有人說,opengl和d3d在底層有很多區別,而且不可設定。

有人說,圖形引擎如果要相容兩者,就只能取其功能的交集,最後還不如任何一種api。

真的麼?

下面先從幾個比較基本的方面來**如何跨越兩個api的鴻溝。

opengl和d3d的架構基本上是這個樣子的:

在架構上其實兩者沒有什麼區別,只是d3d的runtime是在os裡,對於不同硬體來說都是一樣的。而opengl的runtime直接是和驅動合為一體的。但這並不會造成效能有所差別,破解了流言1。

opengl 的原生shading language是glsl,d3d的是hlsl。兩者語法相似,但細節上天差地別。好在,nvidia的cg在很大程度上類似於hlsl,而且可以編譯 出glsl來。所以,cg編譯器成了跨越這兩種shader的橋梁。當然,要真正實用起來,還需要不少工作。比如cg的geometry shader和hlsl 10+的有些許不同,需要通過#ifdef來分開。另外,cg編譯器生成的glsl需要一些調整才能在ati的驅動上工作,所以還需要多一次轉換。好在這 些事情都可以通過程式自動完成,而且速度很快。具體可以參考klayge的oglshaderobject::converttoglsl。實際上,klayge的所有shader都只寫了乙份(語法用hlsl 11的),在不同api上可以自動編譯成原生的shader使用(有opengl和opengl es的編譯器,曾經還有d3d9的)。這樣就沒有重寫的繁瑣,也沒有增加runtime開銷,破解了流言2。

當然,這裡還有另一種更好的選擇,把hlsl編譯器生成的bytecode轉換成glsl。ue3等引擎用了mojoshader來完成這件事情。優點是不需要多次編譯,缺點是不支援sm4+。

初學者經常 說,opengl用右手座標系,而d3d用左手;裁剪空間裡opengl的z是[-1, 1],而d3d是[0, 1];不可調和。實際上,直接把左手的頂點和矩陣給opengl也是沒有問題的。畢竟如果在vs裡執行的都是mul(v, matrix),得到的會是同樣的結果。可能會造成麻煩的反而是viewport的z。假設乙個經過clip之後的頂點座標為(x, y, z, w),那麼在opengl上,該頂點經過viewport變換的z是(z/w + 1) / 2,而在d3d上則是z/w而已。這對於depth test不影響,但depth buffer裡的值就不同了。所以需要對project matrix做一些調整,才能讓他們寫到depth buffer中的數值相同。具體來說,如果要讓opengl流水線接受d3d的project matrix,就需要乘上

klayge遊戲引擎

跨越opengl和d3d的鴻溝(一) 開篇

多年來,在論壇和各個 上不斷能看到拿opengl和d3d進行比較的帖子和文章。他們經常製造很多謎思,使得初學者和一些從業人員對opengl和d3d產生了各種各樣的流言。有人說,opengl直接調到驅動,效能高於d3d。有人說,shader都得寫兩套,很麻煩。有人說,opengl和d3d在底層有很多區...

跨越opengl和d3d的鴻溝(三) 交集?並集?

d3d9的功能早已被opengl 2.0所覆蓋,網上可以找到很多資料,這裡就不提了。本文注重的是新的gpu特性。下表列出了d3d10 的新功能,以及實現該功能所需要的opengl擴充套件或核心。d3d 10的功能 opengl所對應的 geomrtry shader gl arb geometry ...

OpenGL和D3D的區別

1 世界座標系 opengl為右手座標系d3d為左手座標系 2 裁剪空間 opengl中z的範圍 1.0,1.0 d3d為 0.0,1.0 3 shader shader開始是以彙編的形式出現,在推出一段時間後,就出現如下幾種類c的高階語言 注 這些高階語言會被編譯成顯示卡識別的彙編 opengl的...