纹理内存使用

huangapple go评论66阅读模式
英文:

Texture Memory Usage

问题

我正在尝试找出我的应用程序消耗了多少纹理内存。我进行了以下类型的纹理和我的计算:

  1. RGB纹理 -> 纹理宽度 * 纹理高度 * 3(内存使用)
  2. RGBA纹理 -> 纹理宽度 * 纹理高度 * 4(内存使用)

因此,我想知道图形驱动程序是否可以分配比上面计算的内存多得多的内存?

英文:

I am trying to find out how much texture memory does consumed from my application. There are following types of texture and calculations by me:

  1. RGB textures -> textureWidth * textureHeight * 3 (memory usage)
  2. RGBA textures -> textureWidth * textureHeight * 4 (memory usage)

As a result I am wondering that can graphics driver allocate much more memory than above calculated memory?

答案1

得分: 3

根据我所知,大约有20年的时间(大多数)硬件设备支持打包的24位RGB数据。在现代硬件中,这通常以“XRGB”(或等效)格式表示,每个像素有一个填充字节。在硬件中,高效处理跨越缓存线等的像素是困难的。此外,由于许多应用程序(读作“游戏”)使用纹理压缩,因此支持完全打包的24位似乎有些多余。

纹理尺寸:如果纹理的尺寸对于特定硬件而言不够“好”(例如,可能 x 不是16字节的倍数,或者是4x4或8x8块),那么驱动程序可能会填充纹理的物理大小。

最后,如果您使用了MIP映射(出于性能和质量原因,您确实希望这样做),它会使纹理大小增加约33%。

英文:

A few simple answers:

To the best of my knowledge, it's been around 2 decades since (the majority of) hardware devices supported packed 24bit RGB data. In modern hardware this is usually represented in an "XRGB" (or equivalent) format where there is one padding byte per pixel. It is painful in hardware to efficiently handle pixels that straddle cache lines etc. Further, since many applications (read "games") use texture compression, having support for fully packed 24bit seems a bit redundant.

Texture dimensions: If a texture's dimensions are not 'nice' for the particular hardware (e.g,. maybe, say, x is not a multiple of 16bytes, or, say, 4x4 or 8x8 blocks), then the driver may pad the physical size of the texture.

Finally, if you have MIP mapping (and you do want this for performance as well as quality reasons), it will expand the texture size by around 33%.

答案2

得分: 3

除了Simon F的回答之外,值得注意的是,糟糕编写的应用程序可能会强制驱动程序为相同纹理的多个副本分配内存。如果应用程序尝试在仍被进行中的渲染操作引用的情况下修改纹理,就会发生这种情况。这通常被称为"资源写时复制"或"资源幽灵"。

这篇博客在这里提供了更详细的解释:

https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-6-efficiently-updating-dynamic-resources

英文:

In addition to the answer from Simon F, it's also worth noting that badly written applications can force the driver to allocate memory for multiple copies of the same texture. This can occur if it attempts to modify the texture while it is still referenced by an in-flight rendering operation. This is commonly known as "resource copy-on-write" or "resource ghosting".

Blog here explains in more detail:

https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-6-efficiently-updating-dynamic-resources

huangapple
  • 本文由 发表于 2020年1月3日 15:22:45
  • 转载请务必保留本文链接:https://go.coder-hub.com/59574653.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定