作者jk21234 (BL2400PT真不錯)
看板PC_Shopping
標題Re: [閒聊] 爆顯示記憶體似乎也沒有甚麼影響...
時間Tue Aug 9 23:41:31 2016
顯示卡的記憶體是這樣分配的
|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://webptt.com/m.aspx?n=bbs/PC_Shopping/M.1470757293.A.156.html
1F：推 stu87616 : 先推不然怕人說看不懂08/09 23:44
2F：推 TurtleGods : 不管怎樣，先推就對了08/09 23:46
3F：推 KotoriCute : 看到帳號先推再說08/09 23:47
4F：推 AreLies : 先推再說08/09 23:48
5F：推 s37166117 : 認真看不懂 我資工菜鳥08/09 23:48
6F：→ Nafusica : 不要擠我先推08/09 23:50
7F：推 wahaha99 : 推詳細教學 很多東西在腦中是有點模糊的印象08/09 23:52
8F：→ wahaha99 : 這篇這樣就說得很清楚了08/09 23:52
9F：推 amALu : 不管怎樣，先推看不懂 看完還是不懂08/09 23:53
10F：推 e124374155 : 不管! 先推再說 所以我知道3.5G>4G08/09 23:57
11F：推 Egami : 完蛋了 看不懂 XD08/09 23:58
12F：推 Bencrie : 好奇想問 framebuffer 讀的機會高嗎 XD08/09 23:58
沒有每個frame都讀 他就不會叫做framebuffer了啊.
畫面最後是從framebuffer到RAMDAC或DVI等
所以至少讀跟寫都要一次以上.實際上都會超過1次就是...
13F：→ kuma660224 : LODbias是用來調整貼圖銳利度顆粒感08/09 23:59
我不太確定3D Engine內不會有其他的LOD參數
但是MIPMAP用的LOD bias只改變它選的大小
會影響貼好的感覺是必然 因為大的縮成小的
或者小的放大成大的就一定不依樣
但是原始意義就只是改這個大小的選擇而已
可查以往利用LOD Bias對3dmark2001作弊的事件
14F：→ kuma660224 : framebuffer讀取機率很高，因為半透明08/10 00:03
15F：→ kuma660224 : 非讀不可, shader要加一行。08/10 00:03
16F：→ kuma660224 : Blend SrcAlpha OneMinusSrcAlpha08/10 00:03
17F：→ kuma660224 : 意思是 新顏色x透明度+舊顏色x(1-透明度)08/10 00:04
18F：推 FrostGZ : 完了我只看得懂Baffet...咦!?08/10 00:04
19F：→ kuma660224 : 新畫的pixel跟原本buffer中的pixel就混合了08/10 00:05
20F：→ kuma660224 : frame buffer讀寫是所有VRAM操作最耗頻寬08/10 00:06
21F：→ kuma660224 : 比貼圖影響還大，因為材質能硬體解壓縮08/10 00:07
22F：→ kuma660224 : 但FrameBuffer只能用低效DeltaColor壓縮08/10 00:08
23F：→ kuma660224 : 材質貼圖卻大部分可以破壞性壓縮。08/10 00:08
24F：→ kuma660224 : 只要4~8bit就能儲存24~32bit Texel08/10 00:09
25F：推 chibon1992 : 您顯卡系?08/10 00:10
26F：推 soniko : 推不然怕人說看不懂08/10 00:10
27F：→ kuma660224 : LodBias的作弊是把材質快取命中率提高。08/10 00:12
28F：→ kuma660224 : 其實卡上存放貼圖沒有減少。08/10 00:12
貼圖總量沒有減少 但是每次都選小一號的那一塊啊
所以 需要較高頻寬放進顯示卡記憶體的量變少了
如果貼圖總量沒有減少就不影響 那這串一開始不就是
GTA 5開高放在1GB上就爆了....
29F：推 MirageAngel : ▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃推分享08/10 00:13
30F：→ kuma660224 : 但由於它不抓例如512那層而去抓25608/10 00:13
31F：→ kuma660224 : 貼圖變糊但材質快取就更容易命中08/10 00:14
32F：→ kuma660224 : 命中時，材質頻寬需求是008/10 00:14
33F：→ kuma660224 : 從內部快取就找到=不必讀外部VRAM08/10 00:15
34F：→ kuma660224 : 所以顯卡繪圖效率不受外部材質頻寬限制08/10 00:16
35F：→ kuma660224 : 達成不公平的分數。08/10 00:16
其實在3dmark 2001的作弊的那張沒有texture cache
不過由於改LOD bias是變動貼圖讀進來的大小
所以cache的總使用量跟顯示卡記憶體上需要進來的
的總量兩個都會減少
這不是很明顯嗎.兩個都是Memory Hierachy的一環啊
36F：推 tony24334 : 你4不4在老黃手下工作08/10 00:22
37F：推 CactusFlower: 嗯嗯嗯跟我想的差不多.......啊你說什麼?08/10 00:22
38F：→ jk21234 : 沒有呢 不過我今天看104,nvidia在台灣竟然在找08/10 00:23
39F：→ kuma660224 : LodBias是不影響貼圖存放位置。08/10 00:23
40F：→ kuma660224 : DDS檔把所有Mipmap放在同一個檔了。08/10 00:23
41F：→ kuma660224 : 每張圖只有全放或不放在顯卡記憶體上08/10 00:23
42F：→ jk21234 : 研發替代役做Deep Learning08/10 00:23
43F：→ kuma660224 : biad影響到只是讀取所需頻寬，08/10 00:24
44F：→ kuma660224 : 不會有只有某層mipmap擺不同記憶體情形08/10 00:25
45F：→ kuma660224 : 不管用到哪一層mipmap,都是同一個08/10 00:27
46F：→ kuma660224 : tex2D sampler對應一張DX的DDS材質08/10 00:27
這可以看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
開始做的事情不一樣
47F：推 loach98 : 推jk大08/10 00:35
48F：推 jior : 先推不然怕人說看不懂08/10 00:35
49F：→ brmelon : 嗯嗯 我本來也想發這篇文的 感謝jk大幫發08/10 00:37
50F：→ kuma660224 : 有些引擎有個功能是強制把mipmap用到08/10 00:40
51F：→ kuma660224 : 1x1那最小一層，給開發者測試貼圖效能用。08/10 00:40
52F：→ kuma660224 : 每張貼圖變成1pixel，所以快取命中率100%08/10 00:40
53F：推 CHOCOLA1983 : 嗯哼，你以為我看不懂嗎？ 我真的看不懂 Orz08/10 00:40
54F：→ kuma660224 : 然後就能看效能有多大改變。08/10 00:41
55F：推 i9602283 : 我終於看懂一篇了08/10 00:41
56F：推 Bencrie : 我發現我少講讀回 system ram 這件事 orz08/10 00:52
57F：→ Bencrie : blending 要讀 pixel 沒錯，但是有必要過 bus ?08/10 00:53
如果要講傳統的作法 可以當作只有貼圖會被暫時丟出去
因為最開始的技術是這樣.
也不太可能會把其他buffer的東西丟掉
58F：→ kuma660224 : 你那篇講的是用GPU測量mipmap用到哪層08/10 00:59
59F：→ kuma660224 : 它開頭引用另一篇gem1文章的一句話08/10 00:59
60F：→ kuma660224 : Do your users ever get to see your highest08/10 00:59
61F：→ kuma660224 : mip level? If not...但改寫了後面那一句。08/10 00:59
62F：→ kuma660224 : consider scaling back size of your textures08/10 00:59
63F：→ kuma660224 : 這才是原文。意思是用不到就縮小。08/10 00:59
這...總之現在是有把很久沒有讀到的MIP-MAP
尺寸的貼圖丟出顯示卡記憶體這件事情...
GPU可以只丟MIP-MAP的單層出去啦
64F：推 petingo : 長知識~~08/10 00:59
65F：→ kuma660224 : 如果你測試發現512x512從來沒被使用上08/10 01:00
66F：→ kuma660224 : 不如縮成256x256....效果相同且省容量。08/10 01:00
67F：→ kuma660224 : 這在10年前是一種簡易最佳化。08/10 01:04
68F：→ kuma660224 : 目前其實不太重要，因為顯卡級距越拉越大08/10 01:04
69F：→ kuma660224 : HD530/GT210用不上的最高mipmap08/10 01:06
70F：→ kuma660224 : 對跑4K的TitanX可能還嫌太糊了。08/10 01:06
※ 編輯: jk21234 (42.72.0.205), 08/10/2016 01:18:58
71F：→ kuma660224 : 不過在固定解析度封閉平臺還是用的上08/10 01:09
72F：→ kuma660224 : 例如大型電玩。螢幕顯卡都是固定配置08/10 01:09
73F：→ kuma660224 : 畫面只會顯示250pixel寬的東西，用到08/10 01:15
74F：→ kuma660224 : 512寬的素材也沒機會顯示lv0的mipmap08/10 01:15
75F：→ kuma660224 : 家機通常也是固定解析度，即使有伸縮也不大08/10 01:18
76F：→ Litfal : 咦但是我記得貼圖層，在主記憶體和顯卡記憶體裡面的08/10 01:20
78F：→ Litfal : 關係，有點像CPU那邊主記憶體與L快取的關係08/10 01:21
要看年代.以前用記憶體像overlay.....
算了,emm386你們應該看過
他和win95的虛擬記憶體的方便程度
的差距就是幾年前的gpu和現在的怎麼
放貼圖記憶體的差別
79F：→ kuma660224 : Mipmap我沒看過引擎去丟棄，因為不合邏輯08/10 01:22
80F：推 qwe04687 : 趕快推 不然別人會以為我看不懂08/10 01:22
81F：→ kuma660224 : 通常都是直接在loading就縮放08/10 01:23
82F：→ kuma660224 : mipmap用到哪一層是pixel shader已經在算08/10 01:24
83F：→ kuma660224 : 才決定的，CPU或驅動根本無法事先知道08/10 01:24
84F：推 Comebuy : 都是中文 都看不懂 @@08/10 01:31
85F：→ kuma660224 : 摸幾年繪圖領域的東西，就不得不懂...08/10 01:35
86F：→ kuma660224 : GPU GEM1 & GEM2是古董級的書了。08/10 01:35
87F：→ kuma660224 : 裡面一堆古董架構與舊時代組語shader08/10 01:36
88F：→ kuma660224 : 拿來蓋泡麵還算堪用。08/10 01:36
幹這行要有點邏輯
舊的方法如果不再提就是
被更好的取代掉了
但絕對沒有十年前可以解決的
現在反而退化這種事情
hd7970硬體支援partial resident
texture.kepler支援paged/virtual address
texture.
如果mipmap有尺寸一直用不到
它不在顯示記憶體內超正常的啊
有這兩個功能 貼圖怎麼還會
有全尺寸要一起進出這回事 囧
89F：推 sheng76314 : 都是中文 卻看不懂08/10 02:04
※ 編輯: jk21234 (42.72.0.205), 08/10/2016 03:03:56
90F：→ OscarShih : 欸?你們看不懂嗎?不會吧!?怎麼和我一樣 08/10 03:00
91F：推 neofire : 沒有必要看懂，知道結論就行了，結論是…… 08/10 03:18
92F：推 obov : 結論是看不懂QQ 08/10 03:20
93F：推 damnedfish : 只好再度承認看不懂了 08/10 03:22
94F：推 vobor : 這啥？ 中文？ 08/10 04:57
95F：推 wbenjin : 連教主都看不懂 我就放心惹 08/10 05:16
96F：推 codevery0117: 居然連教主也看無ob'_'ov 08/10 05:20
97F：推 check : 原po記憶體專家 08/10 05:32
98F：推 WeAntiTVBS : 連教主都看不懂 那就代表這公司請對人惹 08/10 06:55
99F：推 davidbright : 難道jk也是兩家某一家的lol... 08/10 07:34
100F：推 WWWSENTYOU : 教主都看不懂，我們鄉民Orz 08/10 07:53
101F：推 ry3298 : 推 08/10 07:58
102F：推 allnation : 太專業惹，只能推QQ 08/10 08:05
103F：→ nucleargod : vertex 跟 texture 一樣是開 buffer 記憶體幹嘛分區 08/10 08:09
104F：→ nucleargod : mipmap 本來就整張上，它是去雜訊不是要省空間 08/10 08:10
105F：→ nucleargod : 只是說支援偷吃主記憶體，你也不知道他放什麼 08/10 08:14
106F：→ nucleargod : vulkan 以後這些要自己管，誰會想撕開 mipmap.... 08/10 08:15
107F：推 ken1825 : 看不懂....Orz 08/10 08:15
108F：→ nucleargod : 實際上還是要看繪圖引擎的資源管理才知道 08/10 08:17
109F：推 ahaha777 : 每個字我都看得懂 連起來就... 08/10 08:41
110F：推 cloud654 : 看不懂只好推了 08/10 09:09
111F：推 freshego : 快推不然會被知道看不懂 08/10 09:14
112F：推 atpx : 這篇算是有把我的意思大致表達出來，給你80分 08/10 09:16
113F：推 zseineo : 總之我看不懂 08/10 10:27
114F：推 Ekmund : jk神 o(_ _)o 08/10 11:19
115F：推 luche : 結論是螢幕如果大或解析度高需要大量記憶體？ 08/10 11:21
116F：→ james1201 : 所以jk跟kuma誰說的是對的？ 08/10 11:24
117F：推 terrytina19 : 支持JK大 老實說太專業看不大懂 08/10 11:26
118F：→ kuma660224 : 資源管理是繪圖引擎在管的，如果你顯卡自己想管， 08/10 11:36
119F：→ kuma660224 : 問題會很嚴重，因為GPU根本不知道下個frame 08/10 11:36
120F：→ kuma660224 : 要顯示什麼。自以為mipmap用不到， 08/10 11:36
121F：→ kuma660224 : 但下個frame鏡頭就突然拉近……完蛋。 08/10 11:36
122F：推 niverse : 講中文很難？QQQQQQ 08/10 11:38
123F：→ anedo : 兩位都是人才 08/10 11:40
124F：→ kuma660224 : 知道每pixel使用哪一層mipmap已經是 rasterization 08/10 11:41
125F：→ kuma660224 : 階段 08/10 11:41
126F：→ kuma660224 : 一個優化的腳色往往身上就有不同mipmap... 08/10 11:42
127F：→ kuma660224 : 因為開發者會對重點部位用較大的texel area 08/10 11:43
128F：→ kuma660224 : 比如臉的texel用的最密集，手腳較稀疏。 08/10 11:43
129F：→ kuma660224 : 再全身包起來，以省draw call。。 08/10 11:44
130F：→ kuma660224 : 當shader用tex2d（map，uv）指令讀貼圖， 08/10 11:47
131F：→ kuma660224 : TMU硬體才即時根據pixel/texel對應比例決定最適mipm 08/10 11:47
132F：→ kuma660224 : ap 08/10 11:47
133F：→ kuma660224 : 硬體完全沒法事先知道哪層mipmap不會用到。 08/10 11:49
134F：→ kuma660224 : 只能當下發現要用哪一層mipmap。直接去抓。 08/10 11:50
135F：→ kuma660224 : 硬體virtual address不用來減少卡上存取貼圖量 08/10 11:58
136F：→ kuma660224 : 實際上要跑快還是全體mipmap都搬到VRAM上。 08/10 11:58
137F：→ kuma660224 : 不然效率很差，要準確預測那些用不上， 08/10 11:58
138F：→ kuma660224 : 只能依靠3D engine的virtual texture技術。 08/10 11:58
139F：→ kuma660224 : 引擎才知道接下來要點什麼菜，可以預先備料。 08/10 11:58
140F：→ kuma660224 : VirtualTexture/page講的mipmap/tile， 08/10 12:19
141F：→ kuma660224 : 與lodbias講的mipmap則已經是不同東西了 08/10 12:19
142F：→ kuma660224 : VirtualTexture本身是大到例如64K x 64K這種變態siz 08/10 12:23
143F：→ kuma660224 : e 08/10 12:23
144F：→ kuma660224 : 遠超過正常貼圖(4K以下), 那是屬於引擎的軟體做資 08/10 12:23
145F：→ kuma660224 : 源管理。 08/10 12:23
146F：推 ken720331 : 專業文推..意思是只能先全抓在慢慢剔除不用算的？ 08/10 12:33
147F：推 wert213 : 先推不然會被人以為看不懂 08/10 12:48
148F：→ Khadgar : 不推不然會被人家以為有看懂 XD 08/10 13:13
149F：推 show95175300: 推就對了 08/10 13:19
150F：推 kuma660224 : 引擎資源管理常叫streaming texture之類 08/10 13:53
151F：→ kuma660224 : 通常固定VRAM留一份低解析mipmap版本。 08/10 13:53
152F：→ kuma660224 : 低解析版要多低則是參數可變動的設定。 08/10 13:53
153F：→ kuma660224 : 然後高解析版在引擎快要需要時，送到卡上。 08/10 13:53
154F：→ kuma660224 : 但你移動快速時有可能發生popping. 08/10 13:53
155F：→ kuma660224 : 因為來不及把高解析版送到，只好先用 08/10 13:53
156F：→ kuma660224 : 低解析，然後過一會兒突然變清楚。 08/10 13:53
157F：→ kuma660224 : 但所有引擎預設貼圖都不是streaming 08/10 13:53
158F：→ kuma660224 : 那些貼圖適合streaming則是屬於資源最佳化 08/10 13:53
159F：→ kuma660224 : 如果streaming還是爆記憶體怎摸辦了? 08/10 13:53
160F：→ kuma660224 : 以autodesk新推廣的stingray引擎為例。 08/10 13:53
161F：→ kuma660224 : 他會把似乎沒有使用的貼圖移除，再放新的 08/10 13:53
162F：→ kuma660224 : 如果連這招都不夠，則常使用的貼圖也降級。 08/10 13:55
163F：→ kuma660224 : 基本一分錢一分貨，不必要的搬移越少越好。 08/10 13:58
164F：→ kuma660224 : streaming技術是讓你1~8GB都能全開。 08/10 13:58
165F：→ kuma660224 : 但顯卡記憶體還是得持續越來越大。 08/10 13:58
166F：→ kuma660224 : 否則效率與畫質會被拖累。 08/10 13:59
167F：→ kuma660224 : 但也不用大到用不完的程度，浪費錢而已。 08/10 13:59
168F：→ kuma660224 : 材質雖然年年提升，但顯示卡生命週期相對短。 08/10 14:00
169F：→ kuma660224 : 低階卡Ram少，但它性能低， 08/10 14:03
170F：→ kuma660224 : 跑未來遊戲也只能越開越低解析。 08/10 14:03
171F：→ kuma660224 : 材質量的成長被低解析省的記憶體彌補了 08/10 14:03
172F：推 d83602 : 不另回一篇嗎XD 08/10 14:21
173F：→ kuma660224 : 我moptt手機用回文都會死當.... 08/10 14:22
174F：推 OscarShih : 該換PiPTT了 08/10 14:24
175F：推 Windcws9Z : 該換JPTT了 08/10 15:07
176F：推 GIMIbutter : 推 08/12 13:54