以preemption的議題而言，這樣的比喻是恰當的。
不過async compute比較像是一條馬路要劃幾線道給兩種不同車輛（汽車和機車來比方好了）使用的情況。
Maxwell 2.0的架構類似只有一條機車專用道(compute)，其他都是給汽車走(graphics)。機車和汽車現在可以不用互相排隊了，但是機車道的容量比較小，如果民眾都改騎機車並且走機車專用道，自然就變慢了。但是這些民眾原本可以開車。

> 粒度是對岸翻譯
其實我引用那個日文網頁也是叫粒度 (基本上對岸的東西我很少去看，也不知道對岸怎麼翻就是了)
當然這個英文，很容易在intel 那篇原文內找的到

我大概了解 lzarconlony1 提到的那些是什麼
那其實是GPU平行處理能力，但這跟粒度是不一樣的東西
就GPU平行處理能力NV,AMD是類似的，但是DX11沒辦法顯示出這一點

這篇有說一些，粒度大小對效能的影響
http://pc.watch.impress.co.jp/docs/...514_168480.html
在這段 "データ並列の粒度とデータ並列ハードウェアの関係"

這樣講可能有誤，不過簡單的敘述
粒度就是CPU 與GPU溝通的頻率
粒度大的情形就是CPU 一次下很多命令給GPU運算
粒度小的情形是CPU 一次下一點 給GPU運算

兩者的差異在於CPU下的運算指令是不是適合GPU運算
GPU是個向量特化的運算單元
如果給他運算的東西剛好是向量 那粒度大有優勢，也就是之前我提到的粒度大對傳統圖形運算效率高
如果給他運算的是沒有太多向量的東西(反而CPU處理速度較快) 那粒度小比較好

以上屬於AMD的看法 先不管AMD 這樣認為對不對，最終他選擇的粒度小 很明顯不利於dx11 但有利於dx12
DX11 單執行緒取向沒辦法多下很多指令，DX12就可以平行下很多指令來填滿GPU運算(不管向量還是非向量)

簡單說 出來混(功耗降低) 是要有代價的
是這個意思嗎?

以DX12的定義 要求一定要走graphics或者compute真的是有點"管太寬"...
Maxwell 2.0還不只這樣而已吧 還需要一個交通警察來"分配指揮"

相信從驅動是可以做到 但是能做到甚麼層度有待商榷 已經先天不良
所以按照現在的狀態 連Pascal有可能還是這樣做 所以最近幾版BSOD連連的驅動是這樣來的嗎?




兩者是本質相同的東西 硬體有硬體名詞 軟體有軟體名詞
兩個不同角度去探討事情的本質 這跟AMD甚麼沒關係
從2009-2010就看到有相關硬體與軟體paper
Fine-grained進行一段時間 相當來說是老東西..

你貼的那篇裡面有稍微提到
●データ並列の粒度とデータ並列ハードウェアの関係

------
單從granularity的角度來看還是行不通
NV的Warp一次是32 threads/4 cycles
AMD則是Wavefront一次64 threads/4 cycles
所以AMD一次進來流量較大 單從這邊來看GCN較有效率

NV驅動能改善大概就是Warp Scheduling的問題
不管是要31+1還是怎樣 這種方案似乎在整體效率上很難比肩

反正NV需要再加上一個驅動或者軟體來調度資源
DX12還有空間 希望最後不是又見到NV到處壓迫遊戲商

Most DX12 games are partnering with AMD next year, says AMD

趁勝追擊？預先綁標? 西瓜效應?

馬路版
從交警的角度來說 沒有不能通行的馬路
馬路就是為了追求汽車/機車在"跑路"時更快(更有效率 比較會落跑)而"特化"鋪設的專用道
既然是馬路 就不可避免要探討車流量(效率)

不管你是小綿羊 還是大貨卡 只要能跑路 就是好車
當然交警是人 有些人個性比較強勢 規定小綿羊不准騎內線道(這年頭小綿羊騎外線很容易車禍滴)
另外一個交警比較隨合 替窮人想 小綿羊可以任意騎

反正老闆都是開汽車 騎機車算甚麼呢 沒這樣怎麼能開跑車泡美人:laugh:
預計大概隔兩代才會有機車任意騎的方案出現 Pascal流片啦

相關的東西有人實際測試延遲性
https://www.extremetech.com/extreme...-we-know-so-far
結論上就之前我提到的那樣,NV preemption的latency 表現的不理想
只不過之前不知道NV其實有留個路給小綿羊走(同時可以跑31輛，再多就爆了)
還以為全部都是給火車走的，latency 可能一開始就糟糕了

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

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



=================================

理論上應該快很多
可是連mantle出來的測試也才只快了那麼一點

從工程角度來說這篇完全沒有參考價值
雖然對Maxwell 2.0沒有硬體特化感到一種欺騙 但還是要就事論事

1.沒有學術嚴謹度 科學強調 理論 方法 實驗
這些都沒有在這篇文章中體現 至少個人沒閱讀到

2.不管是甚麼測試 軟體測試要有方法論 硬體測試應該有架構
甚麼都沒有就丟一個結果 天曉得是不是做圖王者
要知道連學術發期刊都有人這樣玩 被踢爆過
當你有一定水準 是可以完全不需要任何data就能製造出似是而真 需要大量時間驗證的結果

3.雙方陣營在硬體層級上除了關鍵的SMM與CU 更應該拉開到system-level來探討
所以不該有 "NV不支援DX12" 這樣不專業的形容出線的原因在此
從system-level與DX12大框架來看 Maxwell甚至之前的kepler是可以被容許
關鍵點一直都是"效率" 也就是硬體特化 如果NV可以用軟+硬做得差不多 那也無妨(感覺超難xD)

這不可避免要納入記憶體設計考量 兩者因前面硬體管線與架構不同
在沒有細部電路的情況 只單單探討一部分沒有太大意義
也許有其他的設計理念 latency高不一定能說明什麼

4.control flow也是一個關鍵 這是可用軟體實現 所以這篇文章
沒有方法論 沒有source code 篇幅超短
(光一篇conference隨便都十幾頁 軟體的都很好寫..還嫌寫不夠 硬體十幾頁就真的有強)
真的很難採用這些結果

5.若你google Joel Hruska 這位
https://www.google.com.tw/search?sa...%90%9C%E5%B0%8B
觀察比對一下 你會發現他的background與工程扯不上邊

我們都知道生病該找醫生 但醫生也有分科 你感冒會去找外科醫生嗎?
GPU效率 牽涉到硬體&軟體層面 當然是要接觸過這兩者的人來探討阿
想魚目混珠藉機紅起來嗎?看起來是一個網路媒體寫手而已 :flash:


也許我們對NV的作法感到失望或者憤怒 但是不應該用這樣的手法去抹黑對方 :)
透過討論讓整個事情更透明 不曉得從NV內部人員角度是怎麼想
我是覺得危機就是轉機 這樣不一定就會對NV不利 AMD在此次中目前只贏面子
GCN是硬體又怎樣? 1.0還是1.1或者1.2能純硬體DX12呢?
如果是1.0 1.1 那就是之前產品 市佔率潰敗是新產品 這樣情況怎麼要求玩家掏腰包買GCN 1.2
如果是GCN 1.2 那更糟糕 定位太高端+缺貨 聽說HBM成本高 這樣賺的到裡子?



ps. overclock.net都蓋到262頁啦

老實說我真的搞不懂你要表達什麼
又沒什麼黑不黑的問題
就單純的NV架構在傳統圖形運算很吃香，AMD架構很沒效率
DX12站在AMD那邊 傳統運算架構不能handle 大量compute NV就無言了
(前面已經有大量敘述不重複)

> 也許我們對NV的作法感到失望或者憤怒
這串還沒看到這個，不過你這篇倒是感受到嚴重的情緒反應

事情就是NV被API婊 這麼簡單
不過這個API的確是個很好的解(相對於DX11僵化的運算)
很可惜的是他跟架構綁死死，軟體可能可以稍微舒緩但結構造成的劣勢很難改變
就看NV新架構怎麼反應