Nvidia被發現不支援DX12的非同步渲染功能

freaky

Advance Member

加入日期: Jan 2002

文章: 449

老實說AMD的GPU架構我是沒研究，那畢竟不是我的工作。以我所知道的，async compute就是只有遊戲會用到，因為遊戲主要是圖形工作為主。HSA是純運算應用吧？它想解決的是CPU和GPU之間不必要的資料搬移問題，和async compute無關。Async compute相關的GPU硬體功能只在能不能同時執行圖形和運算指令。的確AMD的GPU是最早放入這項功能的，但是GM20X開始nVidia的GPU也有，Intel則是說明他們的GPU目前還不支援。但是Andrew解釋了，async compute不需要特別的硬體支援也可以做，效能未必差。

另一篇轉貼的文章我就不回應了，裡面錯誤百出但我也無法說明什麼才是對的。我簡單說，DX12不像某家廠商或其支持者一直在說的，是low-level API，D3D12 API希望達到的設計是low-overhead（為virtual reality鋪路），絕對不是low-level。

引用:

作者orakim

freaky的中文翻譯得很順暢，雖看原文會比較了解意思是什麼
裡面提到的東西，多年前就有人提及
http://pc.watch.impress.co.jp/docs/...502_598132.html
的這個部份
http://pc.watch.impress.co.jp/img/p...tml/17.png.html
讓AMD 一開始設計GCN 就採取左邊的方式
原因就個這篇文章的標題一樣為了HSA
> GCN tends to leave a lot of units idle from what I can tell, and thus it needs this sort of mechanism the most
可以明顯看出這個方式，如果不能用ACE 那就比傳統的方式多了很多idle的時間 (GPU 在等CPU排程)
大概可以解釋AMD效能差的部份原因
> Yes, I'm honestly curious what the benefits to having multiple compute kernels in parallel really are (ala AMD's >2 ACEs)...
> This is beneficial if you cannot overlap an independen...

2015-09-05, 10:02 PM #61

orakim

Master Member

加入日期: Sep 2003

文章: 1,810

這個小編這段有點在編故事的感覺，ACE本身就不是這樣的東西

引用:

傳統高級別API下，一款遊戲或者一個3D繪圖應用在調用Draw Calls時（可理解為向GPU發出指令讓其在屏幕上繪出一個或多個指定圖形）通常會經歷以下過程：來自應用程序的指令先是被“翻譯”給DirectX，然後再被“翻譯”給顯卡驅動，再然後還要“翻譯”給系統內核接口，最後才“翻譯”給GPU去執行……整個過程冗長且低效，但好處是“顯卡驅動”可以有很大發揮空間——“AMD驅動不如英偉達，尤其是遊戲表現上”的說法就是來自於此了。

DX12出現後，所有中間層的“翻譯”工作就被取消了，遊戲開發商可以直接通過API與GPU進行溝通。這不僅只是效率高了，開發者自由發揮的空間也大了（任意分配GPU資源到需要的地方），然而缺點是使用難度也提高了。

那麼，會不會出現遊戲開發者抵制DX12，或者遲遲不用DX12的現象？可能性極低。因為“低級API”一直是遊戲開發社區所呼籲的，當年DirectX的低效和復雜已被太多人詬病。遊戲主機曾經之所以風靡，部分原因就是因為開發環境的友好和高效成就了大量的經典。更何況，DX12正是一款衍生自遊戲主機平台的API接口。

技術部分談完了，英偉達第二代Maxwell是否算支持DX12的架構，恐怕每個人心中都有不同的答案。

關鍵原因是在於 intel 那位Andrew Lauritzen 提到的說法
> anyone asking the first question should also be asking questions about "how much execution unit idle time is there in workload X/Y/Z",
> "what is the granularity and overhead of preemption", etc. All of these things - most of all the workload - are relevant when determining how efficiently a given situation maps to a given architecture."
關鍵在於 granularity 和 overhead of preemption
為了效率高在架構上這兩個的最佳化方向一致 (就NV,intel 架構基本上是這樣)
就AMD不合群弄個反向的方式，再靠ACE把效能弄回來
效能上的好處嘛不能算是明顯，因為NV,intel 那種方式其實也是高效率

只不過GCN這種方式還保留了可以讓GPU進行通用運算的能力
也就是不用走NV的老路(引進GPU通用運算到Desktop上，但是會導致繪圖效能差就拿掉了)

2015-09-05, 10:09 PM #62

Stone Crab

*停權中*

加入日期: Mar 2015

您的住址: 熱火隊地盤

文章: 2,703

引用:

作者orakim

> 敝人之前合理懷疑"異步著色器和異步計算引擎(ACE)"與A卡硬體上保留通用運算有微妙的關係
我是覺的跟公司本質有關
NV被API 搞也不是最近才有的事
以前就出現過剛好也是API 轉換的時期(DX8->DX9)
也就是 GeForce4 Ti系列、Radeon 9800系列

DX12這些API 是low level 的，使用上本來就有難度，遊戲引擎轉換沒這麼快
等DX12遊戲漸漸出來時，NV新架構應該也出來了 (希望不會重複 GeForce FX那個悲劇)
去在意初期哪個比較好意義不是很大，遊戲又沒出來

感覺那段日子DX9.0規格婊到了NV架構, 所以出現了NV30系列的各種悲劇.
到了DX9.0C, M$又妥協了，GeForce 6系列(NV40)又生龍活虎.

2015-09-05, 10:30 PM #63

orakim

Master Member

加入日期: Sep 2003

文章: 1,810

> HSA是純運算應用吧？它想解決的是CPU和GPU之間不必要的資料搬移問題
這只是HSA的瓶頸，而不是HSA要達到的目的;沒有解決這個瓶頸，會導致運算延遲性高HSA就不會有效能

由於HSA需要粒度小的運算，GCN也被設計成這種方式
粒度小的問題點就是要等CPU，這一點在圖形運算上很吃虧(沒效率)
ACE是要解決這個問題所衍生出的方式

> async compute就是只有遊戲會用到，因為遊戲主要是圖形工作為主
實際上在用的是CU，ACE是圖形運算的解決方案
GCN架構下 ACE 固定8個(圖形運算基本上是固定的)
AMD想維持CU:ACE=1:1(可能方便運算混合使用)，但CU數量其實有差異不一定是1:1
PS4 有12 CU,Kaveri 是 8CU;他們 ACE都是8個

此文章於 2015-09-05 10:41 PM 被 orakim 編輯.

2015-09-05, 10:37 PM #64

freaky

Advance Member

加入日期: Jan 2002

文章: 449

其實也不是婊到誰的問題，雙方想做的都是最佳化。現在Windows開發都是以小改版的方式進行，所以更新的速度會比之前快。可能有些人不知道，AMD/Intel/nVidia在Microsoft都有駐點人員和DirectX團隊共同開發，所以設計問題彼此都有一定程度的了解。只是某公司的行銷手法愈趨極端，經常以似是而非的說法混淆視聽，實非我所樂見。

引用:

作者Stone Crab

感覺那段日子DX9.0規格婊到了NV架構, 所以出現了NV30系列的各種悲劇.
到了DX9.0C, M$又妥協了，GeForce 6系列(NV40)又生龍活虎.

2015-09-05, 11:09 PM #65

orakim

Master Member

加入日期: Sep 2003

文章: 1,810

我想舉個數字描述狀況可能會比較容易理解
假設GPU發揮效率100%是極限的話
NV、intel 走的粒度大的情形屬於高效率，可能有八九十%的效率(或者更多這邊的數字只是假設)
AMD 走的粒度小的情形效率只有六七十%，搭配ACE使用才可能追到(或者超過)NV、intel的效率

粒度大本身不適合於ACE的使用，上頁intel 那個原文有解釋一部份(雖然很隱晦沒多談)
把ACE當作是AMD挽救GCN在API層面採取的措施來看就好
本身已經是高效率架構的intel 、NV 沒有一定要採用的必要

當然有一天他們也想要弄混合運算，可能會採取與AMD一樣的措施類似的架構

2015-09-05, 11:30 PM #66

Godzilla2014

Advance Member

加入日期: Apr 2014

文章: 425

引用:

作者Stone Crab

感覺那段日子DX9.0規格婊到了NV架構, 所以出現了NV30系列的各種悲劇.
到了DX9.0C, M$又妥協了，GeForce 6系列(NV40)又生龍活虎.

DX9.0C 一開始也很不成熟
這一代最重要的特效是HDR，記得是Ati不支援，NV可以開但是不能和AA同時開....

__________________
「投手通常開肩膀手術後，旁邊的人都會跟你說『你回不去了』，
但是你真的不用在意，如果你還想投球、想回大聯盟，這些話一點點都不要留在心上，
我以前沒做到這一點，所以才會花更久時間回到這裡。」

－王建民

2015-09-06, 12:30 AM #67

不笑的老Ｋ

Major Member

加入日期: Aug 2012

您的住址: 城管局

文章: 273

引用:

作者orakim

…本身已經是高效率架構的intel 、NV 沒有一定要採用的必要
當然有一天他們也想要弄混合運算，可能會採取與AMD一樣的措施類似的架構

　整串看完，俺非科班沒全看懂，不過這次 N 卡問題的解答就是這一段，沒錯吧？

__________________
「好！你們要王，我告訴你，如果你們要王，你們要知道，你要加稅、你要被欺負，因為王要用厚厚重稅來欺壓你們，你們不要我做王，我讓你們。你們選的王，不是合我心意的，你們受盡痛苦！」

2015-09-06, 04:36 AM #68

lzarconlony1

*停權中*

加入日期: Jun 2015

您的住址: 金一十大女支三

文章: 1,282

引用:

作者freaky

話說我剛好看到的Intel Gen9 Skylake討論串，Intel人員Andrew Lauritzen的發言，這才是了解實際狀況的人會有的說法：

"From an API point of view, async compute is a way to provide an implementation with more potential parallelism to exploit. It is pretty analogous to SMT/hyper-threading: the API (multiple threads) are obviously supported on all hardware and depending on the workload and architecture it can increase performance in some cases where the different threads are using different hardware resources. However there is some inherent overhead to multithreading and an architecture that can get high performance with fewer threads (i.e. high IPC) is always preferable from a performance perspective."

從API的觀點來說，async compute是...

你回去看有說過"不支援"這個形容嗎?

我談的是"特化" 專業不專業留給時間驗證
你沒有類似硬體設計經驗居然可夸夸而談現在是家裡沒人需要派你出場?

總之Maxwell在硬體上並未針對DX12某些特性"特化" 這樣夠清楚嗎
至於要怎麼解讀這件事情支援不支援那已是觀點之爭不會影響事實
你怎麼可能要求一個在DX12未確定之前就設計的GPU能完全DX12特化?

轉貼這些剛好驗證對此點有懷疑的朋友(including me)的看法
現在是硬體說不贏要拉回API解釋

------
AMD行銷極端甚麼的說真的拉商業競爭講這個是有點好笑
根據了解這個事件的原始點似乎沒有AMD影子

過程中確實有人做了一些動作但是目標是敘述自家產品的優越性
這樣就是極端會不會太玻璃心一點傷都受不得

比較之前的酸影片這次根本就是piece行銷

此文章於 2015-09-06 06:54 PM 被 lzarconlony1 編輯.

2015-09-06, 06:53 PM #70