話說我剛好看到的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是提供實作探索更多平行處理可能性的一種方式。它和SMT/hyper-thread十分相似：顯然所有的硬體都支援API (多執行緒)，而根據工作和架構的不同，它在某些情況下可以提升效能，也就是當不同的執行緒使用不同的硬體資源時。然而多執行緒本身就有隱含的成本，從效能觀點來說，我們總是想要一個較少執行緒的高效能架構。

"When someone says that an architecture does or doesn't support "async compute/shaders" it is already an ambiguous statement (particularly for the latter). All DX12 implementations must support the API (i.e. there is no caps bit for "async compute", because such a thing doesn't really even make sense), although how they implement it under the hood may differ. This is the same as with many other features in the API."

當某人說一個架構支援或者不支援 "async compute/shaders"時，就已經是個不精確的敘述（特別是不支援）。所有DX12的實作都必須支援這個API（並沒有針對"async compute"的支援屬性可設定，因為這件事根本無意義），儘管實際上如何實作可能有所不同。這和許多其他(D3D12) API中的功能一樣。

"From an architecture point of view, a more well-formed question is "can a given implementation ever be running 3D and compute workloads simultaneously, and at what granularity in hardware?" Gen9 cannot run 3D and compute simultaneously, as we've referenced in our slides. However what that means in practice is entirely workload dependent, and 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."

從架構的角度而言，一個更合適的問題是〝這個實作是否能同時執行3D和運算工作，以及硬體的精細度如何？〞Gen9無法同時執行3D和運算工作，我們已在簡報投影片中註明。然而實際上的意義完全和工作相關，因此問第一個問題的人接著也該問〝在工作X/Y/Z中的執行單位閒置時間是多少〞，〝先佔式（多工）的成本和精細度為何〞等問題。所有這般考量—其中最重要的，工作本身—都與決定一個使用情境對應到某個架構的效率如何相關。

"Without that context you're effectively in making claims like 8 cores are always better than 4 cores (regardless of architecture) because they can run 8 things simultaneously. Hopefully folks on this site understand why that's not particularly useful."

不去討論應用背景，基本上就像在說八核永遠比四核好（無論架構為何）因為它們可以同時做八件事。希望本站的網友能了解到這並無幫助。

"... and if anyone starts talking about numbers of hardware queues and ACEs and whatever else you can pretty safely ignore that as marketing/fanboy nonsense that is just adding more confusion rather than useful information."

…話說如果某人開始講到硬體佇列和ACE的數量之類的，你就可以忽略他的發言，因為那都是行銷／粉絲的胡說八道，只會帶來更多困擾而非有用的資訊。

"Arun said: ↑
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 independent graphics workload and you have multiple independent compute workloads to run, but I'm not sure how important that is in practice."

Arun的發言：
是啊，我真心好奇擁有數個平行多重運算核心的好處到底在那（啊，AMD有兩個以上的ACE）…。如果你無法重疊不相關的圖形工作，而且你有多個獨立的運算工作要執行，這的確有助益，但我不清楚實際上這有多重要。

"Right so the bit people get confused with is that "I want multiple semantically async queues for convenience/middleware in the API" does *not* imply you need some sort of independent hardware queue resources to handle this, or even that they are an advantage. I hate to beat a dead horse here but it really is similar to multithreading and SMT... you don't need one hardware thread per software thread that you want to run - the OS *schedules* the software threads onto the available hardware resources and while there are advantages to hardware-based scheduling at the finer granularity, you're on thin ice arguing that you need any more than 2-3 hardware-backed "queues" here."

沒錯，所以人們弄不懂的說法是〝我想要API中有多個語意上非同步的佇列以便於使用／用於中繼軟體〞，並＊不＊表示你需要某種獨立的硬體佇列資源來處理，或者它們根本不會帶來任何好處。我不想鞭屍，不過這真的和多執行緒與SMT很像…你不需要為每個軟體執行緒提供一個硬體執行緒—作業系統會將軟體執行緒＊分配＊到可供運用的硬體資源上，另一方面，硬體排程在精細度上有其優點，然而需要比兩到三個更多的硬體＊佇列＊的論點十分薄弱。

"Arun said: ↑
Certainly a lot depends on the workload, the developer, *and* the API's ability to expose that parallelism in the first place."

Arun的發言：
確實一開始很多東西就和工作、開發者，＊以及＊API表現的平行處理能力有關。

"Absolutely, and that's another point that people miss here. GPUs are *heavily* pipe-lined and already run many things at the same time. Every GPU I know of for quite a while can run many simultaneous and unique compute kernels at once. You do not need async compute "queues" to expose that - pipelining + appropriate barrier APIs already do that just fine and without adding heavy weight synchronization primitives that multiple queues typically require. Most DX11 drivers already make use of parallel hardware engines under the hood since they need to track dependencies anyways... in fact it would be sort of surprising if AMD was not taking advantage of "async compute" in DX11 as it is certainly quite possible with the API and extensions that they have."

無庸置疑，而且人們還忽略了另一點。GPU本來就是＊極度＊管線化，並且已經同時做許多事。每個我接觸過一段時間的GPU都可以同時運作許多且獨一無二的運算核心。你不需要async compute＊佇列＊來實現—管線化＋適當屏障的API已經運作得很好，並不需要增加多重佇列通常必備的重量級同步基本體。大部分DX11驅動程式已經可以使用平行硬體引擎，反正它們都需要追蹤相關性…事實上我有點意外，假如AMD之前沒有在DX11中利用"async compute"的話，因為以(D3D11) API和其擴充而言實現可能性十分高。

"Now obviously I'm all for making the API more explicit like they have in DX12. But don't confuse that with mapping one-to-one with some hardware feature on some GPU. That's simply a misunderstanding of how this all works."

顯然我非常贊成像DX12這樣，將這種API變得更加清楚直接。但是不要把這個東西與某些GPU中硬體功能的一對一對應搞混。這純然是對整個運作機制的一種誤解。

"Arun said: ↑
Another thing to consider is that if you have enough parallelism on one workload, then running a second one at the same time risks trashing your cache, and arbitration may also be non-trivial. Again I have never done any performance analysis of GCN so I don't know how well they handle that but it's certainly something that I expect will benefit from gradual improvement between hardware generations."

Arun的發言：
另一個可以考慮的是，如果你在一件工作上有足夠的平行處理能力，那麼同時間執行第二件工作就可能破壞快取，而且仲裁工作可能也不是十分容易。再次強調，我從來沒有針對GCN進行任何效能分析，因此我不知道它們對這種情況的處理有多好，不過我預期這確實是能隨著不同代的硬體逐漸改善的。

"Yes, the scheduling is non-trivial and not really something an application can do well either, but GCN tends to leave a lot of units idle from what I can tell, and thus it needs this sort of mechanism the most. I fully expect applications to tweak themselves for GCN/consoles and then basically have that all undone by the next architectures from each IHV that have different characteristics. If GCN wasn't in the consoles I wouldn't really expect ISVs to care about this very much. Suffice it to say I'm not convinced that it's a magical panacea of portable performance that has just been hiding and waiting for DX12 to expose it."

是的，排程本來就不是一件容易的事，也不是一個應用程式能做好的工作，但就我所知，GCN似乎傾向讓一堆單位閒置，因此其最需要這種機制。我完全預期應用程式會針對GCN／遊戲機調整，然後在來自每個IHV，特性不同的下一代架構中移除這些調整。如果遊戲機中使用的不是GCN，我真的不認為ISV會在乎這些。總而言之，我不覺得這是可移植效能的仙丹，好像原本只是藏在那兒等待DX12來發現。

"Anyways this is going a bit off topic so I'll leave it at that I think I've answered the question in any case and hopefully made those asking it think a little deeper."

不管怎樣，這已經離題了所以我就此打住：）我想無論如何我已經回答了問題，也希望能讓問這些問題的人再想清楚一點。

freaky大講解的好詳細
我相信PCDVD站內GPU專業程度上沒人比的過freaky大
看著跟freaky大爭論的
總覺得不是在同一個水準上

只是我有一個小問題
Pascal是不是真的會用HBM? (挖洞)

目前遊戲卡似乎不會。

遊戲卡沒HBM
不過我還是猜一下
TITAN應該有機會吧

HMC...長久規劃會是這個嗎 ?

我也來離題一下。
其實我對現在的社會蠻感嘆的，講真話沒人要聽，大家寧願相信路邊小道消息，只因為標題聳動內容生動活潑，很多根本就是置入性行銷！
想理性討論都被說是出來消毒的。

================
我到前陣子才知道無聊轉到的韓劇（搞不好根本就不是同一部）劇名不是羅琳亞的塑身衣~_~

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 independent graphics workload and you have multiple independent compute workloads to run, but I'm not sure how important that is in practice."
為什麼要兩個以上ACE 以及多個(非圖形)獨立運算負荷的答案很簡單，就是有可能會用到 (如HSA)
kaveri 最高可以到8個CU 或者說8個ACE(1個CU對應1個ACE)

為什麼是8個原因很簡單，就下面這個
http://www.pcdvd.com.tw/showpost.ph...6&postcount=111
HSA的模型下 CPU、GPU要達到效率高有個比例關係
現在kaveri 就核心數量上的比例是1:2，再加上執行效能的加成的話比例是1:3
> ... and if anyone starts talking about numbers of hardware queues and ACEs and whatever else you can pretty safely ignore that as marketing/fanboy nonsense that is just adding more confusion rather than useful information.
是可以這樣想沒錯，因為這東西不是為了圖形運算產生的
從圖形運算去解釋ACE本來就是non-sense，從HSA的角度看 CU(ACE)數量就是必須要考慮的因素
CU太多浪費沒有用，CU太少HSA 效能出不來

結論就是GCN 原本設計的目標不單純(也包含了HSA)，當然也間接導致GCN在傳統API下效能不高
所以AMD就弄了mantle 做技術展示，讓ACE實用化
間接讓MS生出與mantle 方向類似的DX12 也讓OpenGL 有了下一代API Vulkan

NV因為API的這項改變被拖下水，原本NV採用效率高的運算方式 不像AMD這種粒度小的方式
NV在DX12 效能增加幅度可能沒AMD大

畢竟大多數人只是一個普通的使用者
有些偏專業的東西
都要花時間消化
小道八卦消息聳動
又不需要什麼知識
當然容易隨之起舞

我知道freaky大不是出來消毒
有些質疑一大堆的
我是懷疑他們其實不太懂這些
解釋了又不聽、不信
鬼擋牆似的
理性討論真的有難度

分享轉貼對岸小編寫的文章。
來源：http://tech.163.com/15/0904/23/B2N5KO0L000915BF.html
我直接引述簡翻繁，只擷取部份的談論的文字就好，要看完整的文章可自行連結看。

一家叫Oxide Games的遊戲開發公司於不久前放出了全球首份A卡（AMD顯卡）和N卡（英偉達顯卡）的DirectX 12（後簡稱DX12）遊戲性能測試。不過測試的結果一度令很多媒體和用戶都大感吃驚。

其中，最令人驚訝的並不是A卡因為DX12而“煥然一新”，而是相比之下，英偉達的9xx系列旗艦卡卻因為用了DX12，反意外出現“性能倒退” ——沒理由啊！DX12可是號稱“更接近硬件底層”的API（編程接口），能更高效地調用硬件資源，因此性能表現只會比早期版本的DirectX更好——這是業界的共識，包括英偉達自己也如此承認！
可是，測試的結果確實沒有符合英偉達預期，公司方面也遲遲未作出解釋。迫切希望知道答案的用戶只好紛紛給出自己的猜測：一，這只是一款尚未正式發布的DX12遊戲，可能還未成熟；二，兼容DX12的驅動尚未完善，英偉達如此，AMD也是如此；三， Oxide Games是一家AMD支持的遊戲開發公司，從之前的Mantle技術合作就能得知，所以測試結果有偏向性，不具公信力……

其實，第一和第二點猜測都還能被認為是合理的解釋，但唯獨這第三點——質疑一家AAA遊戲開發公司的專業性——那可就觸及紅線了。

於是，Oxide也終打破沉默，將自己在開發過程中一直通過郵件與英偉達保持交流的事實公開……將英偉達一直有權訪問遊戲源代碼的事實公開……甚至將英偉達在發現測試結果不合預期後，數次施壓並要求屏蔽DX12某項核心功能的事實也公開……尤其是在屏蔽DX12核心功能ACE（Asynchronous Compute Engine，異步計算引擎，後半段將有詳解）這個問題上，Oxide更是直言不諱地指出——英偉達第二代Maxwell架構（9xx系列GeForce）根本就不支持ACE，至少是無法做到“原生支持”（Native Support）。

面對這樣的指控，英偉達用戶（除了超級粉）可真坐不住了——不支持DX12最核心功能之一的ACE，豈不就等於不支持DX12嗎？於是，國外主要科技論壇，包括Anandtech、Guru3d以及Reddit等，有關話題的跟帖迅速破千，大量用戶開始聲討英偉達，要求官方必須給出解釋。
然而，英偉達的官方聲明還沒等到，AMD的全球技術營銷主管Robert Hallock卻出現在Reddit上“添油加醋湊熱鬧”。

Hallock先是表示，自己在看到Oxide的測試成績後也有過類似懷疑，即：Maxwell架構是通過“環境切換”（context switching）的方式來實現ACE的，此方法效率極低，因此無法做到真正意義的“異步計算”（文後解釋，看不懂不要急）——這言下之意就是，N卡的DX12是殘缺的，至少在ACE這個功能上沒有做到“完全支持”。

不得不說，這是一次成功的“火上澆油”，只不過火勢蔓延太快，連Hallock自己都有些驚惶不安——N粉和A粉在Reddit論壇上即刻展開對撕，場面一度有些失控。情急之下，Hallock只好補上一句：“沒有誰家的產品能完美支持DX12，英偉達如此，AMD也是如此”——希望能藉此為整個事件打個圓場……再然後，我們就看到了《AMD：當前沒有什麼可完美支持DX12》的新聞充斥在各大科技媒體的頭條……

AMD和英偉達的恩怨其實不是小編要在這裡講述的內容，如果A粉和N粉要對撕，請三思後繞道而行。接下來，小編將花些篇幅講解DX12的技術細節，其中包括本文一再提到的ACE的概念，因此可能會很乏味，不喜者可忽略之。

DirectX 12的技術淺析
大談專業技術內容通常不會獲得網友的理解，所以小編在此會盡量簡化細節，一些不恰當的比喻還望專業人士指正。

DX12與以往任何版本的DirectX都不同。這種不同並不在於提供了更多的功能性特效，譬如光影特效、水波紋特效等，而是在於將實現這些特效的方法放到了GPU的硬件層去執行，正所謂“DX12是低級別API ”的原因。注意，這裡的低級和高級並不指“好壞”，級別越低，代表越接近硬件底層，因此執行起來效率高，但編寫時代碼特別長。

因為把“功能下放到硬件層”去實現，DX12自然就會對GPU的硬件規格（或者說資源規模）有要求，因此我們又看到了微軟根據GPU能提供的硬件資源規模，對每一項DX12的功能都給出了Tier 1、Tier 2和Tier 3三個級別分類，以表示該GPU對該項特性的支持程度（級別越高表示支持越好，但級別低也算是支持）。

聽起來有點拗口難懂？沒關係，我們換個角度來簡單說明一下。不管AMD還是英偉達，在一顆GPU上能使用的晶體管總數是有限的，所以想要把有限的資源“完美”分配給每一項DX12規範的功能，幾乎是不可能完成的任務（當前技術下）。這就好比我們只有3000元來配置新電腦，是買好一點的CPU，還是好一點的顯卡，還是大一點的硬盤，還是快一點的SSD？這都需要進行取捨，而取捨的結果將會決定該電腦擅長的領域，譬如較好的顯卡有助於提升遊戲性，大容量硬盤則可用於專業的NAS服務等。

那麼，AMD和英偉達又各自做了哪些取捨？
AMD從第一代GCN架構開始，將大量的晶體管投入到了實現Asynchronous Compute Engine（異步計算引擎）上。所以，A卡號稱擁有64+1個完整的ACE。

相比之下，第二代的Maxwell架構將大量晶體管用在了實現Conservative Rasterization（保守光柵）和Raster Ordered Views（光柵順序視圖）兩項功能上。因此，N卡的ACE只有31+1個——注意，這只是官方數據，其真實性還有待考證，這也正是引出本期《易評》的焦點所在。

(這邊我補充有比較詳細的功能分別表，AMD也有NVIDIA沒有的DX12其他的兩個功能，但也是"選用Optional"功能)
http://www.overclock.net/t/1567968/...s-and-resources

當然，以上只是一部分晶體管的分配情況和一部分DX12規範下的功能。但也就這一小部分差別，今天在互聯網上引發了劇烈的質疑和討論。

AMD說自己也不完美支持DX12，其所指正是上述的Conservative Rasterization和Raster Ordered Views兩項功能。此兩項功能在DX12標準下為“可選擇項”，是不要求必須實現的。不過，英偉達已經支持了，儘管有的只是Tier 1的支持（AMD兩項均為零支持），所以微軟又制訂了DX12.1規範，即下個升級版的DX12將會開始要求支持Conservative Rasterization和Raster Ordered Views——這也是為什麼英偉達一直標榜自己產品是DX12.1標準的原因。

不過諷刺的是，ACE可是DX12規範下必須支持的核心功能。英偉達在宣傳中號稱支持該功能，但實際測試卻發現，所謂的支持可能僅僅是通過“驅動層模擬”（emulated）來實現的，而並非是大家所期待的架構層原生支持。除了Oxide和AMD先後提出相關質疑外，beyond3D論壇上的專業網友也通過多次針對性測試得到了類似結論——特別值得一提的是，此前GTX 970被曝出的“只有3.5GB有效顯存”的問題，也是經過beyond3D網友多次測試後發現。

根據這些網友和專業人士的解釋，英偉達實現ACE的方式應該是依賴了大量Preemption（搶占式多任務）和“環境切換”操作。簡單地說，就是GPU在進行異步計算時，需要先暫停當前正在處理的任務，以騰出資源來處理優先插入的數據。這一過程，通常會產生大量的閒置（Idle）。同時，“環境切換”在存儲和重建任務上極為低效，這更進一步增加了處理的延遲。

換用更通俗一點的比喻來說，英偉達實現ACE的方法就好比有交通燈的大道，側道車輛如果要併入主道，主道車輛就必須先停下來，並等待紅燈再次變綠。相比之下，如果是從架構層實現ACE，就相當於在一條自由寬鬆的高速公路上，讓車輛自由併入主幹道，整個交通無需通過紅綠燈來控制。

英偉達這種通過“驅動模擬”實現的ACE到底算不算真正支持？目前還沒有一個權威定論。不過小編在這里大致說一下DX12是如何“弱化”驅動的，然後大家自己就會有答案了。

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

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

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

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