|
||
|
*停權中*
加入日期: May 2015
文章: 1,017
|
聽說Zen有參考apple microarchitecture
畢竟Jim Keller是從apple那回來的 有沒有大神已經研究過了？ |
|||||||
2016-07-30, 09:37 AM
#31
|
|
|
Major Member
 加入日期: Jan 2002
文章: 159
|
win7+670要同時看影片+fah要選mpalyer這種可以不call dx9的播放器
選opengl就會正常 460跑fah+Gw2=系統無回應 670跑fah+Gw2=遊戲會很慢(<10fps) 970跑fah+Gw2=遊戲稍有頓挫，不太能準確控制（<30fps)
__________________
|
||
|
2016-07-30, 09:44 AM
#32
|
|
|
Elite Member
  
加入日期: Nov 2002 您的住址: 不正常人類研究中心
文章: 6,347
|
引用:
現在搞清楚了 最好把Chrome的GPU硬體加速關掉 這樣F@H時上網才不會太卡
__________________
要用FurMark燒機請注意,作者建議跑15分鐘就好/電腦電源接頭規格 加入 F@H分散運算,幫助對抗疾病/ /加入WCG分散運算,幫助解決癌症,AIDS,糧食與能源問題 http://cid-d082ecba16a55988.skydriv...=GetSharingLink VGAMaster 請多多支持,歡迎任意轉貼! 
|
|
|
2016-07-30, 12:36 PM
#33
|
|
|
Power Member
加入日期: Nov 2004
文章: 693
|
引用:
自己搞另一套… 那麼Pascal？還是放生？ |
|
|
2016-07-30, 12:40 PM
#34
|
|
|
Advance Member
加入日期: Mar 2006 您的住址: 葉子的故鄉
文章: 486
|
引用:
以nv的性格，pascal的下場放生的機率會很高
__________________
人間近三月，往事恨悠悠... |
|
|
2016-07-30, 12:52 PM
#35
|
|
|
Power Member
加入日期: Nov 2004
文章: 693
|
引用:
所謂的彈性是否有通用的可能？ 人工調整？誰能保證以後不會放生… |
|
|
2016-07-30, 12:58 PM
#36
|
|
|
Master Member
加入日期: Sep 2003
文章: 1,810
|
原文已經說得很清楚了
他的意見是： Pascal是用Die面積當作代價去改善Dynamic scheduling GPU廠要在ultra-fast、ultra-flexible裡面找出最佳平衡點 -- 我解讀他的意思是： NV在Pascal的作法是提供一定程度的彈性，但不是AMD的那種ultra-flexible NV如果在ultra-fast、ultra-flexible找出平衡點 有可能引導接下來2-5年的遊戲開發 不過我個人認為他的基礎論調有很大的問題，沒有考慮到遊戲開發情形 正常遊戲開發下 每個遊戲的平衡點是不一樣的(差異性可以極大) 除非NV花錢綁廠商綁遊戲 從設計階段就讓廠商降低突發事件插入排程的運算量 照著NV的規格來做 |
|
2016-07-30, 06:24 PM
#37
|
|
|
Advance Member
加入日期: Jan 2002
文章: 449
|
Scheduling從來就不是DX12應用程式或遊戲可以控制的。
引用:
|
|
|
2016-07-30, 07:52 PM
#38
|
|
|
Golden Member
加入日期: Dec 2002
文章: 3,258
|
引用:
Pascal架構就是這樣, 沒有辦法, 雖然可以做(彈性給你了), 但很仰賴設計人員去最佳化, 比較"搞工", 相關人員要維持一定的默契, 這應該是NV目前權宜的做法, 整體上當然比不上很 早就為async compute鋪路的AMD GCN架構, 雖然mantle以失敗收場, 但不論是拋磚引玉, 或者說水到渠成, 目前也到差不多可以收割的時候... Volta不知架構會不會大改, 還是從原架構再改良...
__________________
2013 UPCOMING PC-GAME |
|
|
2016-07-31, 08:42 AM
#39
|
|
|
Master Member
加入日期: Sep 2003
文章: 1,810
|
> Scheduling從來就不是DX12應用程式或遊戲可以控制的。
我沒有這樣說吧，Scheduling本來就驅動程式、硬體上的東西啊 誰在跟你說DX12應用程式或遊戲可以控制它 NV的狀況就是 靜態、動態Scheduling 採固定比例分配 本來就不符合遊戲開發現況 不同場景 不同遊戲 需要插入任務量差異性極大 這些插入的任務造成所需靜態、動態Scheduling的平衡點不同 哪有固定比例的可以讓NV去抓 NV訂一個比例出來 就代表超出這個比例之後會很沒有效率 很多運算單元閒置起來 然後你就會看到不同場景 不同遊戲，NV掉的frame很多 有時候順有時候不順很惱人的狀況 而不是那篇作者寫的 NV抓到對的平衡點就可以領導遊戲開發好幾年 除非NV給錢 要不然這個是很難發生的啦 > 雖然mantle以失敗收場 與其說是失敗不如說是大成功，主要目的達到 它本身不一定需要存在，何況已經有後代了 此文章於 2016-07-31 02:14 PM 被 orakim 編輯. |
|
2016-07-31, 02:08 PM
#40
|
|
