Re: [閒聊] 爆顯示記憶體似乎也沒有甚麼影響...

[jk21234 (BL2400PT真不錯)]

顯示卡的記憶體是這樣分配的


|XXXXXXXX| (假定1GB)

 **
   顯示卡自己保留 比如說跟driver互相傳遞的buffer,啟動顯卡
   資源分配的有的沒有的...沒有規定會做多大 有的卡可能不太大
   不過如果你想保留512MB給自己用也不是不行

   ++
     每次啟動3D的時候 基本的buffer例如frame buffer,double buffer,z buffer
     放置vertex的buffer,放shader code的buffer等等

     ---------
              貼圖使用


一般用軟體看顯示記憶體用量,可能是**++--------或者是++--------
的總和 看軟體怎麼偵測.

但是,--------是應用程式所準備好 所有貼圖的所有"尺寸(MIP-MAP)"


真正影響效能的 是--------中那些會被最近的frame所讀取

如果已經很久沒讀取了 基本上可以放在主記憶體之中,這是AGP顯示卡以來
的基本功能,所以,--------得總和大於顯示記憶體總量也沒甚麼


為甚麼--------不會每次都讀取到?

基本上有幾種可能


1.貼圖種類不同 像是假設有冰山 有火山
  那你看不見其中一種的時候 也不會讀取他的貼圖
  這就和視角以及場景有關

2.貼圖只用到其中幾個尺寸

  MIP-MAP是由最小2*2開始,4*4,8*8....一直到N*N
  都準備好,要用到的時候會挑x或者y長度最接近的一個
  送到貼圖filter去.

  如果解析度比較低 因為MIP-MAP會挑選解析度相近的
  所以會傾向選擇比較小的 所以這個frame的貼圖總用量也會相應變小

  怎麼說?假設2560*1440,占了螢幕的1/10要選一個貼圖　大約會
　選到512*512的,如果是1280*720　就應該是選到256的.

　不過即使是高解析度這個仍然可以調整,這個參數叫做LOD(Level of details)
  Bias.就是跟標準的尺寸比起來　你想要傾向選較小或者是較大的貼圖
  選擇小一號的就會只需要1/4的記憶體動態用量跟頻寬

  這個不影響貼圖使用的總量　但是會影響你有多大的顯示記憶體
　可以跑順


因此在這個例子,"高"的2GB貼圖可能
(h表示常用)

2560*1440

hhhhhh--

1920*1080
hhhh----

1280*720  or LOD =-1
hh------


真正影響效能的量就是**++hh三種的總和

但是開放場景的話　貼圖的變化也會很大
那麼活動的總量就可能遠比你想像的還要高了



--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.72.0.205
※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1470757293.A.156.html
推 stu87616    : 先推不然怕人說看不懂
推 TurtleGods  : 不管怎樣，先推就對了
推 KotoriCute  : 看到帳號先推再說
推 AreLies     : 先推再說
推 s37166117   : 認真看不懂 我資工菜鳥
→ Nafusica    : 不要擠我先推
推 wahaha99    : 推詳細教學 很多東西在腦中是有點模糊的印象
→ wahaha99    : 這篇這樣就說得很清楚了
推 amALu       : 不管怎樣，先推看不懂    看完還是不懂
推 e124374155  : 不管! 先推再說  所以我知道3.5G>4G
推 Egami       : 完蛋了 看不懂 XD
推 Bencrie     : 好奇想問 framebuffer 讀的機會高嗎 XD
沒有每個frame都讀 他就不會叫做framebuffer了啊.

畫面最後是從framebuffer到RAMDAC或DVI等

所以至少讀跟寫都要一次以上.實際上都會超過1次就是...

→ kuma660224  : LODbias是用來調整貼圖銳利度顆粒感
我不太確定3D Engine內不會有其他的LOD參數
但是MIPMAP用的LOD bias只改變它選的大小
會影響貼好的感覺是必然 因為大的縮成小的
或者小的放大成大的就一定不依樣

但是原始意義就只是改這個大小的選擇而已
可查以往利用LOD Bias對3dmark2001作弊的事件


→ kuma660224  : framebuffer讀取機率很高，因為半透明
→ kuma660224  : 非讀不可, shader要加一行。
→ kuma660224  : Blend SrcAlpha  OneMinusSrcAlpha
→ kuma660224  : 意思是 新顏色x透明度+舊顏色x(1-透明度)
推 FrostGZ     : 完了我只看得懂Baffet...咦!?
→ kuma660224  : 新畫的pixel跟原本buffer中的pixel就混合了
→ kuma660224  : frame buffer讀寫是所有VRAM操作最耗頻寬
→ kuma660224  : 比貼圖影響還大，因為材質能硬體解壓縮
→ kuma660224  : 但FrameBuffer只能用低效DeltaColor壓縮
→ kuma660224  : 材質貼圖卻大部分可以破壞性壓縮。
→ kuma660224  : 只要4~8bit就能儲存24~32bit Texel
推 chibon1992  : 您顯卡系?
推 soniko      : 推不然怕人說看不懂
→ kuma660224  : LodBias的作弊是把材質快取命中率提高。
→ kuma660224  : 其實卡上存放貼圖沒有減少。
貼圖總量沒有減少　但是每次都選小一號的那一塊啊

所以　需要較高頻寬放進顯示卡記憶體的量變少了

如果貼圖總量沒有減少就不影響　那這串一開始不就是
GTA 5開高放在1GB上就爆了....

推 MirageAngel : ▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃推分享
→ kuma660224  : 但由於它不抓例如512那層而去抓256
→ kuma660224  : 貼圖變糊但材質快取就更容易命中
→ kuma660224  : 命中時，材質頻寬需求是0
→ kuma660224  : 從內部快取就找到=不必讀外部VRAM
→ kuma660224  : 所以顯卡繪圖效率不受外部材質頻寬限制
→ kuma660224  : 達成不公平的分數。
其實在3dmark 2001的作弊的那張沒有texture cache

不過由於改LOD bias是變動貼圖讀進來的大小
所以cache的總使用量跟顯示卡記憶體上需要進來的
的總量兩個都會減少

這不是很明顯嗎.兩個都是Memory Hierachy的一環啊

推 tony24334   : 你4不4在老黃手下工作
推 CactusFlower: 嗯嗯嗯跟我想的差不多.......啊你說什麼?
→ jk21234     : 沒有呢　不過我今天看104,nvidia在台灣竟然在找
→ kuma660224  : LodBias是不影響貼圖存放位置。
→ kuma660224  : DDS檔把所有Mipmap放在同一個檔了。
→ kuma660224  : 每張圖只有全放或不放在顯卡記憶體上
→ jk21234     : 研發替代役做Deep Learning
→ kuma660224  : biad影響到只是讀取所需頻寬，
→ kuma660224  : 不會有只有某層mipmap擺不同記憶體情形
→ kuma660224  : 不管用到哪一層mipmap,都是同一個
→ kuma660224  : tex2D sampler對應一張DX的DDS材質
這可以看GPU gems2

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter28.html

performance can be enhanced and memory can be saved by swapping
those unused mipmap levels out of video memory.

至於你的疑問我想是這樣說
driver的行為分為user mode和kernel mode,
在user mode被那些API call的語意和真正從kernel mode
開始做的事情不一樣

推 loach98     : 推jk大
推 jior        : 先推不然怕人說看不懂
→ brmelon     : 嗯嗯 我本來也想發這篇文的 感謝jk大幫發
→ kuma660224  : 有些引擎有個功能是強制把mipmap用到
→ kuma660224  : 1x1那最小一層，給開發者測試貼圖效能用。
→ kuma660224  : 每張貼圖變成1pixel，所以快取命中率100%
推 CHOCOLA1983 : 嗯哼，你以為我看不懂嗎？        我真的看不懂 Orz
→ kuma660224  : 然後就能看效能有多大改變。
推 i9602283    : 我終於看懂一篇了
推 Bencrie     : 我發現我少講讀回 system ram 這件事 orz
→ Bencrie     : blending 要讀 pixel 沒錯，但是有必要過 bus ?
如果要講傳統的作法 可以當作只有貼圖會被暫時丟出去

因為最開始的技術是這樣.


也不太可能會把其他buffer的東西丟掉
→ kuma660224  : 你那篇講的是用GPU測量mipmap用到哪層
→ kuma660224  : 它開頭引用另一篇gem1文章的一句話
→ kuma660224  : Do your users ever get to see your highest
→ kuma660224  : mip level? If not...但改寫了後面那一句。
→ kuma660224  : consider scaling back size of your textures
→ kuma660224  : 這才是原文。意思是用不到就縮小。
這...總之現在是有把很久沒有讀到的MIP-MAP
尺寸的貼圖丟出顯示卡記憶體這件事情...

GPU可以只丟MIP-MAP的單層出去啦

推 petingo     : 長知識~~
→ kuma660224  : 如果你測試發現512x512從來沒被使用上
→ kuma660224  : 不如縮成256x256....效果相同且省容量。
→ kuma660224  : 這在10年前是一種簡易最佳化。
→ kuma660224  : 目前其實不太重要，因為顯卡級距越拉越大
→ kuma660224  : HD530/GT210用不上的最高mipmap
→ kuma660224  : 對跑4K的TitanX可能還嫌太糊了。
※ 編輯: jk21234 (42.72.0.205), 08/10/2016 01:18:58
→ kuma660224  : 不過在固定解析度封閉平臺還是用的上
→ kuma660224  : 例如大型電玩。螢幕顯卡都是固定配置
→ kuma660224  : 畫面只會顯示250pixel寬的東西，用到
→ kuma660224  : 512寬的素材也沒機會顯示lv0的mipmap
→ kuma660224  : 家機通常也是固定解析度，即使有伸縮也不大
→ Litfal      : 咦但是我記得貼圖層，在主記憶體和顯卡記憶體裡面的
→ kuma660224  : 那句出處 http://goo.gl/fVa9np
→ Litfal      : 關係，有點像CPU那邊主記憶體與L快取的關係
要看年代.以前用記憶體像overlay.....
算了,emm386你們應該看過
他和win95的虛擬記憶體的方便程度
的差距就是幾年前的gpu和現在的怎麼
放貼圖記憶體的差別

→ kuma660224  : Mipmap我沒看過引擎去丟棄，因為不合邏輯
推 qwe04687    : 趕快推 不然別人會以為我看不懂
→ kuma660224  : 通常都是直接在loading就縮放
→ kuma660224  : mipmap用到哪一層是pixel shader已經在算
→ kuma660224  : 才決定的，CPU或驅動根本無法事先知道
推 Comebuy     : 都是中文 都看不懂 @@
→ kuma660224  : 摸幾年繪圖領域的東西，就不得不懂...
→ kuma660224  : GPU GEM1 & GEM2是古董級的書了。
→ kuma660224  : 裡面一堆古董架構與舊時代組語shader
→ kuma660224  : 拿來蓋泡麵還算堪用。
幹這行要有點邏輯
舊的方法如果不再提就是
被更好的取代掉了

但絕對沒有十年前可以解決的
現在反而退化這種事情

hd7970硬體支援partial resident
texture.kepler支援paged/virtual address
texture.

如果mipmap有尺寸一直用不到
它不在顯示記憶體內超正常的啊

有這兩個功能 貼圖怎麼還會
有全尺寸要一起進出這回事 囧

推 sheng76314  : 都是中文 卻看不懂
※ 編輯: jk21234 (42.72.0.205), 08/10/2016 03:03:56
→ OscarShih   : 欸?你們看不懂嗎?不會吧!?怎麼和我一樣
推 neofire     : 沒有必要看懂，知道結論就行了，結論是……
推 obov        :                               結論是看不懂QQ
推 damnedfish  : 只好再度承認看不懂了
推 vobor       : 這啥？ 中文？
推 wbenjin     : 連教主都看不懂 我就放心惹
推 codevery0117: 居然連教主也看無ob'_'ov
推 check       : 原po記憶體專家
推 WeAntiTVBS  : 連教主都看不懂 那就代表這公司請對人惹
推 davidbright : 難道jk也是兩家某一家的lol...
推 WWWSENTYOU  : 教主都看不懂，我們鄉民Orz
推 ry3298      : 推
推 allnation   : 太專業惹，只能推QQ
→ nucleargod  : vertex 跟 texture 一樣是開 buffer 記憶體幹嘛分區
→ nucleargod  : mipmap 本來就整張上，它是去雜訊不是要省空間
→ nucleargod  : 只是說支援偷吃主記憶體，你也不知道他放什麼
→ nucleargod  : vulkan 以後這些要自己管，誰會想撕開 mipmap....
推 ken1825     : 看不懂....Orz
→ nucleargod  : 實際上還是要看繪圖引擎的資源管理才知道
推 ahaha777    : 每個字我都看得懂                     連起來就...
推 cloud654    : 看不懂只好推了
推 freshego    : 快推不然會被知道看不懂
推 atpx        : 這篇算是有把我的意思大致表達出來，給你80分
推 zseineo     : 總之我看不懂
推 Ekmund      : jk神  o(_  _)o
推 luche       : 結論是螢幕如果大或解析度高需要大量記憶體？
→ james1201   : 所以jk跟kuma誰說的是對的？
推 terrytina19 : 支持JK大 老實說太專業看不大懂
→ kuma660224  : 資源管理是繪圖引擎在管的，如果你顯卡自己想管，
→ kuma660224  : 問題會很嚴重，因為GPU根本不知道下個frame
→ kuma660224  : 要顯示什麼。自以為mipmap用不到，
→ kuma660224  : 但下個frame鏡頭就突然拉近……完蛋。
推 niverse     : 講中文很難？QQQQQQ
→ anedo       : 兩位都是人才
→ kuma660224  : 知道每pixel使用哪一層mipmap已經是 rasterization
→ kuma660224  : 階段
→ kuma660224  : 一個優化的腳色往往身上就有不同mipmap...
→ kuma660224  : 因為開發者會對重點部位用較大的texel area
→ kuma660224  : 比如臉的texel用的最密集，手腳較稀疏。
→ kuma660224  : 再全身包起來，以省draw call。。
→ kuma660224  : 當shader用tex2d（map，uv）指令讀貼圖，
→ kuma660224  : TMU硬體才即時根據pixel/texel對應比例決定最適mipm
→ kuma660224  : ap
→ kuma660224  : 硬體完全沒法事先知道哪層mipmap不會用到。
→ kuma660224  : 只能當下發現要用哪一層mipmap。直接去抓。
→ kuma660224  : 硬體virtual address不用來減少卡上存取貼圖量
→ kuma660224  : 實際上要跑快還是全體mipmap都搬到VRAM上。
→ kuma660224  : 不然效率很差，要準確預測那些用不上，
→ kuma660224  : 只能依靠3D engine的virtual texture技術。
→ kuma660224  : 引擎才知道接下來要點什麼菜，可以預先備料。
→ kuma660224  : VirtualTexture/page講的mipmap/tile，
→ kuma660224  : 與lodbias講的mipmap則已經是不同東西了
→ kuma660224  : VirtualTexture本身是大到例如64K x 64K這種變態siz
→ kuma660224  : e
→ kuma660224  : 遠超過正常貼圖(4K以下), 那是屬於引擎的軟體做資
→ kuma660224  : 源管理。
推 ken720331   : 專業文推..意思是只能先全抓在慢慢剔除不用算的？
推 wert213     : 先推不然會被人以為看不懂
→ Khadgar     : 不推不然會被人家以為有看懂 XD
推 show95175300: 推就對了
推 kuma660224  : 引擎資源管理常叫streaming texture之類
→ kuma660224  : 通常固定VRAM留一份低解析mipmap版本。
→ kuma660224  : 低解析版要多低則是參數可變動的設定。
→ kuma660224  : 然後高解析版在引擎快要需要時，送到卡上。
→ kuma660224  : 但你移動快速時有可能發生popping.
→ kuma660224  : 因為來不及把高解析版送到，只好先用
→ kuma660224  : 低解析，然後過一會兒突然變清楚。
→ kuma660224  : 但所有引擎預設貼圖都不是streaming
→ kuma660224  : 那些貼圖適合streaming則是屬於資源最佳化
→ kuma660224  : 如果streaming還是爆記憶體怎摸辦了?
→ kuma660224  : 以autodesk新推廣的stingray引擎為例。
→ kuma660224  : 他會把似乎沒有使用的貼圖移除，再放新的
→ kuma660224  : 如果連這招都不夠，則常使用的貼圖也降級。
→ kuma660224  : 基本一分錢一分貨，不必要的搬移越少越好。
→ kuma660224  : streaming技術是讓你1~8GB都能全開。
→ kuma660224  : 但顯卡記憶體還是得持續越來越大。
→ kuma660224  : 否則效率與畫質會被拖累。
→ kuma660224  : 但也不用大到用不完的程度，浪費錢而已。
→ kuma660224  : 材質雖然年年提升，但顯示卡生命週期相對短。
→ kuma660224  : 低階卡Ram少，但它性能低，
→ kuma660224  : 跑未來遊戲也只能越開越低解析。
→ kuma660224  : 材質量的成長被低解析省的記憶體彌補了
推 d83602      : 不另回一篇嗎XD
→ kuma660224  : 我moptt手機用回文都會死當....
推 OscarShih   : 該換PiPTT了
推 Windcws9Z   : 該換JPTT了
推 GIMIbutter  : 推