作者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/cn.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