Originally posted by shihwolf@May 4 2005, 02:40 AM
很好很好 :)
小T出手就是一堆卡 :sun:
第一句話很不錯,又有皮卡丘搞笑....會幫你加分的 mooon
不過....
如果把OPENGL那段文字翻成中文,我會幫你加更多分 mooon mooon mooon
----
你簽名檔有兩個第二屆 :|||:
OpenGL 2.0 － 為了解救可程式化繪圖而推出
可程式化能力
可程式化能力是OpenGL 2.0裡的一個關鍵字，這表示它是設計供應用程式存取運用。為使其符合大部分應用程式與使用者的標準，繪圖可程式化能力是透過一種被CPU類型所採用的可程式化能力、類似高階程式語言的方式加進來的。他將提供一個豐富的弁銃陛B獨立於硬體（正如一個標準所應該有的特性），並專為在OpenGL架構下使用所設計。
可程式化頂角處理會是最常被談論到的弁遄C它將取代座標轉換、材質應用程式及照明，並且允雀i行隨機個別頂角運算。
可程式化區段處理是另一項關鍵弁遄C它將取代材質存取、材質應用程式及霧化弁遄A以及隨機個別區段運算、這個開發者企盼已久的弁遄C
可程式化影像格式將取代固定格式封裝和解封裝運算，在自OpenGL傳送或接收像素資料時，將允傢?牴P格式進行任意組合。
這個想法是為了藉由提供可程式化能力、與豐富且常效性的弁鄖茖?N複雜度，以減少對現有及未來延伸指令的需求。
弁賌/b]
其他被用來和新標準搭配工作的弁鄍]括：
在應用程式控制下多程編譯演算法的直接支援
更具彈性的畫面緩衝區架構
OpenGL內的顯示外移交
材質記憶體的應用程式控制
OpenGL物件架構的統一化
對於讀寫影像格式更具彈性的支援
更清楚、有效的同步化機制
緩衝區互換的應用程式控制
運用任意的色彩緩衝區作為材質
這便形成了OpenGL開發與演進的進程，如下圖所示：
這個新API將有助於弁鄋獐郱リい羹W進效能，以及現有弁鄋獐郱リヾC大多數選用的OpenGL 1.3影像子集在OpenGL 2.0裡都是必備的，而且釵h延伸指令都將和標準的OpenGL搭配運作，這將可完全釋放出硬體的效能。這將可在與繪圖子系統間的往返傳輸上，獲得極佳的效能，並使CPU與繪圖處理間更加平行化。這個新的API看起來就像下圖所示：
這個新API將有助於弁鄋獐郱リい羹W進效能，以及現有弁鄋獐郱リヾC大多數選用的OpenGL 1.3影像子集在OpenGL 2.0裡都是必備的，而且釵h延伸指令都將和標準的OpenGL搭配運作，這將可完全釋放出硬體的效能。這將可在與繪圖子系統間的往返傳輸上，獲得極佳的效能，並使CPU與繪圖處理間更加平行化。這個新的API看起來就像下圖所示：
弁鄔?
新API裡的一些特色
陰影語言。一種獨立於硬體之外的OpenGL 2.0陰影語言，與OpenGL 1.3有緊密的整合。現有的狀態機又增加了可程式化單元，將可增設OpenGL 1.3固定式的替代弁遄C新的著色器可自動紀錄現有的OpenGL狀態（例如進行一個簡單的光源轉換而無須覆寫參數管理）。它以C為架構，加上容易理解的向量和矩陣類別，並也將整合一些Renderman弁遄C這套語言會虛擬資源管線，因此對大多數的程式設計師來說便不用去考慮資源管理。將來也會有相同形式、供頂角著色器與區段著色器之用的語言，並加上一些特別內建的弁鄔M資料限定器。
頂角處理器。其弁鄏b於照明、材質和幾何圖形的彈性。頂角程式將取代部分的OpenGL管線，像是：頂角轉換；正規轉換；正規化和尺寸重設；照明；彩色材質應用程式；色彩強化；材質座標產生；以及材質座標轉換。然而，頂角著色器並無法取代下列弁遄G透視投影與視覺座標對應；柱狀及使用者剪裁；背三角面丟棄；原始組合；雙面照明選擇；多重模式處理；多邊形平移；或多邊形模式。
區段處理器。其弁酮飢鷜閬s取、內插器與像素運算彈性。Open GL 2.0增加了區段 處理器能力，將取代下列弁遄G內插值頂角資料運算；像素縮放；材質存取、縮放和偏向；材質應用；色表查找；霧化；旋繞；以及OpenGL管線中的色彩矩陣部分。然而區段著色器並沒有取代下列弁遄GOpenGL的陰影模型；直方圖；覆賓蛂F極值；像素所有權測試；像素封裝和解封裝；剪裁；點刻；alpha測試；深度測試；模印測試；alpha混色；邏輯運算；顫色；或平面遮罩。
封裝和解封裝運算。封裝和解封裝運算的目的在於將「應用像素」轉換成一致性的像素群資料流。在資料傳送到解封裝處理器前先運用未封裝儲存模式。解封裝處理器和應用對OpenGL傳輸有關，而封裝處理器則負責OpenGL對應用傳輸這部分，兩者都跟複製運算沒有關係。繪圖子系統內的複製只使用區段處理器。
OpenGL現有的「像素傳輸」運算是由區段處理器所支援，而非封裝／解封裝處理器。區段處理器具有縮放、偏向、查找、旋繞等所需的能力。此外由於ARB並不要求多餘的硬體能力，封裝／解封裝處理器因而便無需具備其他可程式化單元所搭載的浮點運算能力。主要的運算能力為偏移、遮罩以及轉換為／自浮點數 - 那些和像素資料的應用對OpenGL轉換有關的弁遄C在封裝解封裝處理器中運作的程式必需和目前的區段著色器相容，並和區段處理器搭配運作以實做OpenGL像素管線。
資料移動與記憶體管理。為了增進效能，資料移動量必需減至最低。視覺處理的主要資料為：頂角資料（色彩、正規、位置、使用者定義等）以及影像資料（材質、影像、像素緩衝區）。建立與管理OpenGL物件的機制大體上就是定位、連結與透過相同介面控制物件，並運用頂角陣列、影像、材質、著色器、顯示清單以及像素緩衝區。
目前來說，OpenGL的記憶體管理還是黑箱作業；這也就是說所有的事項都會自動處理。因此應用程式無需瞭解究竟運算結果為何、運算要花多少時間、無需去控制要配置多少儲存空間以及這些物件要放在何處。因此，目前版本的OpenGL對於物件何時要被複製、搬移、刪除或封裝（區段整理）是無法加以控制的。此外也不清楚記憶體資源的虛擬化。這樣的結果是目前OpenGL僅有相當有限的能力去「要求一塊空間」，而且只能為了預存材質才能進行這項要求。下圖所示為目前OpenGL記憶體管理的組織架構。
OpenGL 2.0將提供更好的記憶體管理，並提供應用程式對資料移動的控制能力，提供更好的頂角處理能力、將資料抓進OpenGL的更有效方法，OpenGL物件的直接存取。此外，記憶體管理弁鉒鉈灠ㄛ側W進資料流量而產生的資料備份，以大幅提昇效能。
藉由記憶體管理的控制能力，應用程式便可進行調適與動態改變。然而，應用程式開發者將得運用每個物件的使用線索，並和OpenGL聯繫以使應用程式瞭解資料的使用狀態。這就會達到真的「用一次、用很多次、寫一次、非同步連結資料」 － [S1]。他也會提供一個供所有物件使用的單一機制（例如材質、顯示清單、頂角陣列、影像、像素緩衝區和著色器）。材質、顯示清單、頂角陣列記憶體等之間並無什麼區別，這並不會使OpenGL的實做無法取得這些物件的特定儲存區。另外可供選擇的，應用程式還是可以讓OpenGL去管理記憶體；這就是另一個作法 － [S2]。
OpenGL 2.0會採用應用程式掌控的固定作法，一旦資料被載入後，OpenGL便無法進行搬移、複製、封裝或刪除物件的動作。物件會被配置在高效能的繪圖記憶體上，讓應用程式負責儲存或刪除物件、或啟始封裝的運作。新的結構更有效率，如下圖所示。
非同步OpenGL。Open GL加上非同步運算後，OpenGL 2.0將提供更好的平行化和同步化能力。傳統上OpenGL在意的是如何和何處 － 而非何時。長久以來一直需要一個能瞭解並控制事件於何時發生的更好機制。平行化能讓某個事件處理完後，工作能繼續進行。比方說，在等待交換的同時清空色深暫存區。
OpenGL需要一個一般化、統一的非同步化機制，以避免每個延伸指令都要求產生自己的機制。這將會：解決一些短期的問題如平行影像下載；在未來能更加精細的運用時機控制；令應用程式必需遵守時機性；事件發生時的控制能力；以及允雩?曭摟penGL運算進行平行執行。這些長運算可相對於主移交工作「分段執行」，這會是一個替代一個做完才換下一個的好方法 － [S3]。
最後的結果會是OpenGL (2.0)將具有一般化的時間控制能力，有助於增進平行化和運算時機的控制。
Glsync。Glsync是一種新的OpenGL資料類型，可提供統一的同步化機制。它可以視為是一個控制器。現在OpenGL具有配置和釋放記憶體空間的弁遄A但沒有由應用程式所控制的ID記憶體空間。在新的版本中，執行緒可以藉由OpenGL的等待弁遄A在Glsync上稍後處理。繪圖驅動程式可以解除在Glsync上執行緒的等待狀態。Glsync可以運用在相當廣泛的地方像：防護移交；非同步資料連結；事件提示（例如垂直空白訊號）；交換完成通知；以及其他現在還沒想到的新東西... 這也提供了一個整合至基礎作業系統同步化原函式的選擇 － [S4] 。
移交一個圍牆會將執行緒同步化到移交命令流中；這是一個涵說uFinish：」弁鄋漯熄隻X。「Finish」必需停滯新移交工作無法起始的主執行緒。OpenGL將可使用Glsync作此通知。一個執行緒可以產生防護、執行更多命令，然後在Glsync上等待。「等待」會在防護之前的移交工作完成後解除。這可以達成Finish所無法辦到的弁遄C
增加了釵h額外的弁鄐巹鄐O
FlushStream。現在的規格資料暫存上允章L多的自由度。清除弁鈳Q濫用且迫使驅動程式得對此做最佳化。真正的清除弁酮O用在當應用程式已經下完移交指令後才做的。暫存的移交工作應該和應用程式在處理其他事項時平行運作，在到Glsync上等待前，必需要確定暫存起來的命令會被加以處理。[S5] － FlushStream解決了這樣的問題。
非同步資料連結。這可在資料複製前提供回傳弁?－ [S6]，並在資料進行連結時允野D平行處理。執行緒在OpenGL讀資料時可以做其他事。這可以避免記憶內容在OpenGL存取完成前被修改，不過這在可以安全修改記憶內容時需要加以通知。
背景命令流。現有的非同步資料連結還是無法進行平行移交。藉由背景命令流弁遄A另一個命令流可以下達非同步連結的指令，給比優先順序較低的移交工作執行。這便可以在前景命令流下達OpenGL的指令，一般的命令流現在都是上下連接的。前景命令流具有較高的優先順序，較背景命令流優先執行。
垂直空白訊號通知。似乎是個很明顯的事，垂直空白訊號通知讓OpenGL可以對視訊輸出和程式碼進行同步化。
麻煩小施哥哥編輯入 第一篇英文下方謝謝
