GPU 算圖引擎的發展 @ CG 曙光 :: 隨意窩 Xuite日誌
  • Sai,賽到亂七八糟,無可救藥的 Sai。
    整天想著要做出好看的CG動畫,卻好像變成軟體技術人員...

  • 關鍵字






  • 如何使用RSS
    Powered by Xuite
  • My Plurk
    1. 沒有新回應!
  • 2010-06-12 10:34 GPU 算圖引擎的發展
    平均分數:0 顆星    投票人數:0
    我要評分:

    瞎掰一下...

    以下是一些個人看法,不一定正確...畢竟我沒有實際看過 cuda 和 opencl 的文件或什麼,只是以目前實際試用以及觀看其他技術人員所寫的心得歸納之後的總結...

    基本上目前所講的 GPU 算圖通常都是指類似 vray rt 或是 hyper shot 這類"持續一直在算圖,並且讓你很快看到結果的物理算圖引擎"(ps:這兩個都是基於 cpu*)。

    hypershot:

    VRAY RT:(題外話..vray rt 在台灣的影片還真少...翻來翻去只有太陽兄有丟出來...)

    如果算圖引擎玩很大的人會發現,這種算圖法和基於真實物理的 maxwell 很類似,就是一直放著然後他會越算越細,只不過 maxwell 在速度上令人缺乏耐心,很難拿來算動畫...不過官方也用這個影片反駁了沒人拿來作動畫這件事....

    Alma: a short animated film, written and directed by Spaniard Rodrigo Blass and rendered completely with Maxwell Render.

    因為 GPU 在物理演算上的速度遠快於 CPU,所以現在才會有像 physX 這樣透過 GPU 計算的物理引擎。

    而算圖也是一種物理計算,只是為了要節省計算時間,所以才發展出了像是 vray、fr、mr 等等,透過自家開發的演算法來簡化,或是排除掉物理計算上需要花太多時間的部份,不過如果你要精準的話,這些算圖引擎還是有保留最原始的暴力演算(brute force)

    而既然 GPU 算物理很快,所以也就不用作弊了,直接像 maxwell 那樣用真實物理來暴力演算就是最適合的,因此目前大部份的 GPU 算圖都是標榜自己是基於真實物理的(un-biased, physically based renderer),例如 Octane Render

    會說"大部分"是因為 vray rt GPU 和 iray 令人不確定,因為他們有可能會用以往的經驗來讓不需要被計算的地方排除來加快速度。

    不管是要暴力還是取巧,GPU 都像是救世主般的降臨了 CG 的世界....

    但是,真的有那麼簡單嗎?

    先排除 GPU 和 CPU 在物理演算上的差別,來看看一般的算圖流程好了...

    不管是用哪種算法,首先我們一定要有模型,然後上材質+texture,然後環境、燈光等等,然後讓引擎演算需要的資料,如果模型有動態的話,還要在加上動畫的資料(可能是 vertex animation 或是一般 PRS 等等)

    這些資料都存需要在記憶體,或是 cache 在硬碟讓算圖引擎可以隨時讀取。

    而這類物理算圖引擎,目前有三種方向 CPU、CPU+GPU、pure GPU

    這三個分法不只單純的用來分辨算圖使用的核心,也劃分了這個算圖引擎可以取用的資源。

    1.CPU:

    最一般的狀況,也是我們已經用了很長時間的東西,可以取用的資源是 CPU、主機板上的記憶體、虛擬記憶體(硬碟)、網路、網路上的硬碟、CPU。

    2.pure GPU:

    就是你顯卡上的資源了,GPU+VRAM(也許還有 LAN ?)

    3.CPU+GPU

    以上兩個加起來...

    --------------------

    而綜觀我們在算圖時會遇到的問題,其實就是兩個-- 速度與記憶體

    速度,就是多加幾台或是多幾個核心,不管是CPU 還是 GPU,都是這樣解決,這也是 GPU的優勢,因為一顆 GPU 有上百個核心。

    記憶體,是目前搞 CG 的都要把作業系統換成 64 位元的唯一理由,有了 64 位元,軟體可用的記憶體不再局限於 1.3 ~ 1.8,開 RENDER 不會再出現 OUT OF MEMORY,愛算多大都可以。

    CPU 的部份還 OK,反正就砸錢加記憶體,記憶體不夠還可以吃一下硬碟來補。

    但是 GPU 就麻煩了...他只能吃自己卡上的那一份記憶體...

    以目前來說,1G 的記憶體大概可以吃 1~1.2 千萬的三角面,看似很多,但以現在場景越作越大,然後動不動就算到 hd 畫質的時代來說,加一下 texture、materials/shaders,其實是很隨便就超過了的(NEO 大借一下圖 >< )



    而 pure GPU 目前能做的,就是只有等,等製程技術提高還有管線增加,來多放一些記憶體,不過這種事情很難說,現在 GTX 480 已經有 1.5 可以用了,我想過沒多久就會有破 2G 的版本出現。

    所以說,其實只要多花點錢這些都不是問題  XD

    最後是比較特別的 CPU+GPU,感覺上他應該是最佳的方式,不過卻不一定,因為過程其實很麻煩,而且大幅增加撰寫上的困難度。

    這類算圖方式並非把一樣的東西同時丟給 CPU 和 GPU 那麼簡單,而是把適合的部份拆開,例如開源的 SmallLuxGPU 就是把過去 lux render 需要算很久的 ray-intersection 和tonemapping 拆給 GPU,但是實際上的演算法還是存在 CPU 。因此 GPU 的部份只保存模型物件以及速度資訊,而其他材質、貼圖等等就保留在 CPU,CPU 會把 GPU 算出來的資訊作最後的 comp。這麼作大概可以減少 70~90 的計算時間。

    因為要拆又要合,所以就速度上肯定不會比 pure GPU 快,不過因為拆開了,所以貼圖以及後半段的 comp 處理就不會佔掉 VRAM。

    最簡單的說法就是 -  大概省了所有貼圖,以及一張 full channel openEXR 的大小

    而這種節省的程度,就看不同的需求,如果今天你只是作 NTSC 的動畫,那貼圖其實沒多大,但如果你今天作 1080p 的..那就很可觀了....更不用說要算到 4k 8k 的平面設計業,光最後那一張 4k 的 tif 檔可能都要個兩三百 mb,不省不行阿....

    雖然,如果 VRAM 真的不夠,CPU+GPU 的模式也可以選擇不使用 VRAM 改用 RAM,不過只能二擇一,而且用 RAM 的話,速度肯定會下降很多,畢竟目前主機板上的 RAM 最快也才 DDR3,VRAM 都到 DDR5 了...再加上排匯流的限制...

    另外一個拆開的好處是,後半段的 comp 可以透過網路結合其他 cpu 來計算,也就是像現在 gi cache 一樣,一台算好 cache,然後其他台就處理後面的。只是現在 cache 的部份丟給 GPU,所以速度可以大幅的加快。

    整個算圖流程的建構只需要多買一塊好的顯卡,其他原本已有的設備都可以沿用,這才是 CPU+GPU 追求的重點。

    以基於真實物理的算圖法來說,單純 CPU 算圖已經出局了...即使之後出到了實體 8 核,在速度的部份還是追不上 GPU,而之後也會有越來越多 GPU 算圖的東西出現,也肯定會有為了解決記憶體問題而產生的壓縮技術,或是使用 point cloud 的算圖引擎等等...

    相信以後大家都會算圖愉快的....


    20100614 更新:

    剛看了一下,新的 Tesla 2070 規格已經可以有 6 G 的 vram 了,所以基本上肯砸錢,記憶體的限制應該是可以無視...

    sai / Xuite日誌 / 回應(2) / 引用(0) / 好文轉寄
    回應