不好意思 我英文不夠好
經過再看一遍 該怎麼說 不該說是ROP SM(SMM)或者是L2問題
應該說有好幾個問題點 要分開討論

直接改圖 不知道該怎麼表達 這算是一個資源分配的問題 最主要是controller沒處理好
我相信這理論上是有可能從韌體或驅動改善結果的



兩個部分 簡單結論因為應該不是大家都是Computing背景
1.圖中紅色方塊1
SMM(Streaming Multiprocessor Maxwell). 還是習慣稱其SM..
13 SM give you 52pixel/clock, 8 ROPs accept 56pixel/clock. the bottleneck is SMMs not ROPs.

2.圖中紅色方塊2
L2 block 7 recived twice requesting and getting more. it's take twice time compare other 6 L2 blocks and effect memory controller.

有人說SM沒影響 瓶頸在SM根本不在ROPs 怎麼不影響?
然後L2取消了一個方塊 只有7個port要接受所有要求
這樣就會變成最後一個port的L2接收兩倍要求 所以等其他六個L2送到MC(memory controller), 第七個還在執行.

理論上應該會設計通知 也就是說cache更新會需要回傳訊號 其他六個都回傳OK
第七個還沒有回應 這時候就不會refresh L2資料 這樣間接影響到MC的速度

不曉得這樣做的意義是因為cache良率不佳還是??不甚理解會這樣動的原因何在


還有應該要參照一下這個 上圖表達不完全盡善 不只會影響到最後一個MC
而是你用到就會影響到整體效率 因為所有request都必須要等第七個L2處理完畢
http://international.download.nvidi...paper_FINAL.PDF

不管從結構還是實測來看 確實用超過就會有FPS低落的情況
這已經算是big bug應該提出解決方案或者recall
當初都沒小量產測試就直接大量產嗎...