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

看板PC_Shopping作者 (BL2400PT真不錯)時間7年前 (2016/08/09 23:41), 7年前編輯推噓55(55推 0噓 121→)
留言176則, 62人參與, 最新討論串1/1
顯示卡的記憶體是這樣分配的 |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
推
08/09 23:44, , 1F
先推不然怕人說看不懂
08/09 23:44, 1F
推
08/09 23:46, , 2F
不管怎樣，先推就對了
08/09 23:46, 2F
推
08/09 23:47, , 3F
看到帳號先推再說
08/09 23:47, 3F
推
08/09 23:48, , 4F
先推再說
08/09 23:48, 4F
推
08/09 23:48, , 5F
認真看不懂 我資工菜鳥
08/09 23:48, 5F
→
08/09 23:50, , 6F
不要擠我先推
08/09 23:50, 6F
推
08/09 23:52, , 7F
推詳細教學 很多東西在腦中是有點模糊的印象
08/09 23:52, 7F
→
08/09 23:52, , 8F
這篇這樣就說得很清楚了
08/09 23:52, 8F
推
08/09 23:53, , 9F
不管怎樣，先推看不懂 看完還是不懂
08/09 23:53, 9F
推
08/09 23:57, , 10F
不管! 先推再說 所以我知道3.5G>4G
08/09 23:57, 10F
推
08/09 23:58, , 11F
完蛋了 看不懂 XD
08/09 23:58, 11F
推
08/09 23:58, , 12F
好奇想問 framebuffer 讀的機會高嗎 XD
08/09 23:58, 12F
沒有每個frame都讀 他就不會叫做framebuffer了啊. 畫面最後是從framebuffer到RAMDAC或DVI等 所以至少讀跟寫都要一次以上.實際上都會超過1次就是...
→
08/09 23:59, , 13F
LODbias是用來調整貼圖銳利度顆粒感
08/09 23:59, 13F
我不太確定3D Engine內不會有其他的LOD參數 但是MIPMAP用的LOD bias只改變它選的大小 會影響貼好的感覺是必然 因為大的縮成小的 或者小的放大成大的就一定不依樣 但是原始意義就只是改這個大小的選擇而已 可查以往利用LOD Bias對3dmark2001作弊的事件
→
08/10 00:03, , 14F
framebuffer讀取機率很高，因為半透明
08/10 00:03, 14F
→
08/10 00:03, , 15F
非讀不可, shader要加一行。
08/10 00:03, 15F
→
08/10 00:03, , 16F
Blend SrcAlpha OneMinusSrcAlpha
08/10 00:03, 16F
→
08/10 00:04, , 17F
意思是 新顏色x透明度+舊顏色x(1-透明度)
08/10 00:04, 17F
推
08/10 00:04, , 18F
完了我只看得懂Baffet...咦!?
08/10 00:04, 18F
→
08/10 00:05, , 19F
新畫的pixel跟原本buffer中的pixel就混合了
08/10 00:05, 19F
→
08/10 00:06, , 20F
frame buffer讀寫是所有VRAM操作最耗頻寬
08/10 00:06, 20F
→
08/10 00:07, , 21F
比貼圖影響還大，因為材質能硬體解壓縮
08/10 00:07, 21F
→
08/10 00:08, , 22F
但FrameBuffer只能用低效DeltaColor壓縮
08/10 00:08, 22F
→
08/10 00:08, , 23F
材質貼圖卻大部分可以破壞性壓縮。
08/10 00:08, 23F
→
08/10 00:09, , 24F
只要4~8bit就能儲存24~32bit Texel
08/10 00:09, 24F
推
08/10 00:10, , 25F
您顯卡系?
08/10 00:10, 25F
推
08/10 00:10, , 26F
推不然怕人說看不懂
08/10 00:10, 26F
→
08/10 00:12, , 27F
LodBias的作弊是把材質快取命中率提高。
08/10 00:12, 27F
→
08/10 00:12, , 28F
其實卡上存放貼圖沒有減少。
08/10 00:12, 28F
貼圖總量沒有減少　但是每次都選小一號的那一塊啊 所以　需要較高頻寬放進顯示卡記憶體的量變少了 如果貼圖總量沒有減少就不影響　那這串一開始不就是 GTA 5開高放在1GB上就爆了....
推
08/10 00:13, , 29F
▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃推分享
08/10 00:13, 29F
→
08/10 00:13, , 30F
但由於它不抓例如512那層而去抓256
08/10 00:13, 30F
→
08/10 00:14, , 31F
貼圖變糊但材質快取就更容易命中
08/10 00:14, 31F
→
08/10 00:14, , 32F
命中時，材質頻寬需求是0
08/10 00:14, 32F
→
08/10 00:15, , 33F
從內部快取就找到=不必讀外部VRAM
08/10 00:15, 33F
→
08/10 00:16, , 34F
所以顯卡繪圖效率不受外部材質頻寬限制
08/10 00:16, 34F
→
08/10 00:16, , 35F
達成不公平的分數。
08/10 00:16, 35F
其實在3dmark 2001的作弊的那張沒有texture cache 不過由於改LOD bias是變動貼圖讀進來的大小 所以cache的總使用量跟顯示卡記憶體上需要進來的 的總量兩個都會減少 這不是很明顯嗎.兩個都是Memory Hierachy的一環啊
還有 101 則推文
還有 7 段內文
→
08/10 11:58, , 137F
不然效率很差，要準確預測那些用不上，
08/10 11:58, 137F
→
08/10 11:58, , 138F
只能依靠3D engine的virtual texture技術。
08/10 11:58, 138F
→
08/10 11:58, , 139F
引擎才知道接下來要點什麼菜，可以預先備料。
08/10 11:58, 139F
→
08/10 12:19, , 140F
VirtualTexture/page講的mipmap/tile，
08/10 12:19, 140F
→
08/10 12:19, , 141F
與lodbias講的mipmap則已經是不同東西了
08/10 12:19, 141F
→
08/10 12:23, , 142F
VirtualTexture本身是大到例如64K x 64K這種變態siz
08/10 12:23, 142F
→
08/10 12:23, , 143F
e
08/10 12:23, 143F
→
08/10 12:23, , 144F
遠超過正常貼圖(4K以下), 那是屬於引擎的軟體做資
08/10 12:23, 144F
→
08/10 12:23, , 145F
源管理。
08/10 12:23, 145F
推
08/10 12:33, , 146F
專業文推..意思是只能先全抓在慢慢剔除不用算的？
08/10 12:33, 146F
推
08/10 12:48, , 147F
先推不然會被人以為看不懂
08/10 12:48, 147F
→
08/10 13:13, , 148F
不推不然會被人家以為有看懂 XD
08/10 13:13, 148F
推
08/10 13:19, , 149F
推就對了
08/10 13:19, 149F
推
08/10 13:53, , 150F
引擎資源管理常叫streaming texture之類
08/10 13:53, 150F
→
08/10 13:53, , 151F
通常固定VRAM留一份低解析mipmap版本。
08/10 13:53, 151F
→
08/10 13:53, , 152F
低解析版要多低則是參數可變動的設定。
08/10 13:53, 152F
→
08/10 13:53, , 153F
然後高解析版在引擎快要需要時，送到卡上。
08/10 13:53, 153F
→
08/10 13:53, , 154F
但你移動快速時有可能發生popping.
08/10 13:53, 154F
→
08/10 13:53, , 155F
因為來不及把高解析版送到，只好先用
08/10 13:53, 155F
→
08/10 13:53, , 156F
低解析，然後過一會兒突然變清楚。
08/10 13:53, 156F
→
08/10 13:53, , 157F
但所有引擎預設貼圖都不是streaming
08/10 13:53, 157F
→
08/10 13:53, , 158F
那些貼圖適合streaming則是屬於資源最佳化
08/10 13:53, 158F
→
08/10 13:53, , 159F
如果streaming還是爆記憶體怎摸辦了?
08/10 13:53, 159F
→
08/10 13:53, , 160F
以autodesk新推廣的stingray引擎為例。
08/10 13:53, 160F
→
08/10 13:53, , 161F
他會把似乎沒有使用的貼圖移除，再放新的
08/10 13:53, 161F
→
08/10 13:55, , 162F
如果連這招都不夠，則常使用的貼圖也降級。
08/10 13:55, 162F
→
08/10 13:58, , 163F
基本一分錢一分貨，不必要的搬移越少越好。
08/10 13:58, 163F
→
08/10 13:58, , 164F
streaming技術是讓你1~8GB都能全開。
08/10 13:58, 164F
→
08/10 13:58, , 165F
但顯卡記憶體還是得持續越來越大。
08/10 13:58, 165F
→
08/10 13:59, , 166F
否則效率與畫質會被拖累。
08/10 13:59, 166F
→
08/10 13:59, , 167F
但也不用大到用不完的程度，浪費錢而已。
08/10 13:59, 167F
→
08/10 14:00, , 168F
材質雖然年年提升，但顯示卡生命週期相對短。
08/10 14:00, 168F
→
08/10 14:03, , 169F
低階卡Ram少，但它性能低，
08/10 14:03, 169F
→
08/10 14:03, , 170F
跑未來遊戲也只能越開越低解析。
08/10 14:03, 170F
→
08/10 14:03, , 171F
材質量的成長被低解析省的記憶體彌補了
08/10 14:03, 171F
推
08/10 14:21, , 172F
不另回一篇嗎XD
08/10 14:21, 172F
→
08/10 14:22, , 173F
我moptt手機用回文都會死當....
08/10 14:22, 173F
推
08/10 14:24, , 174F
該換PiPTT了
08/10 14:24, 174F
推
08/10 15:07, , 175F
該換JPTT了
08/10 15:07, 175F
推
08/12 13:54, , 176F
推
08/12 13:54, 176F
‣ 更多 jk21234 的文章
文章代碼(AID): #1NgVcj5M (PC_Shopping)