该文件表明,这种"分配"储存纹理和水平.提供的伪代码似乎表明这是针对mipmap级别的.
如何使用glTexStorage涉及glGenerateMipmap？glTexStorage似乎"锁定"纹理的存储大小.在我看来,这只会使事情变得不那么灵活.是否意味着要在这里获得性能提升？
它是相当新的,只能在4.2中使用,所以我会尽量避免使用它,但我很困惑,因为它的描述使它听起来很重要.
如何在早期GL版本中管理纹理存储？当我打电话给glTexImage2D我有效擦除并释放以前与纹理手柄相关联的存储时,是吗？并且生成mipmap也会自动为我处理存储空间.
我记得使用老式的glTexSubImage2D方法来实现OpenGL 2风格的渲染到纹理,以便在我以前的引擎实验中做一些后期处理效果.这是有道理的,glTexStorage会带来管理纹理相关的资源,现在我们有更好的方法来做到RTT更明智的方式.
Nic*_*las 30
要了解glTexStorage它的作用,您需要了解这些glTexImage*函数的作用.
glTexImage2D 做三件事:
GL_PIXEL_UNPACK_BUFFER),则不会发生像素传输.手动创建glTexImagemipmap 纹理需要一系列调用,每个mipmap级别一个.mipmap级别的每个大小都必须是基于先前级别大小的适当大小.
现在,如果您查看GL 4.2规范的第3.9.14节,您将看到两页规则,纹理对象必须遵循这些规则才能"完成".无法访问不完整的纹理对象.
在这些规则中,例如"mipmap必须具有适当的大小".以我上面给出的例子为例:一个64x64 2D图像,它是mipmap level 2.它将是完全有效的OpenGL代码,用于分配使用256x256纹理的mipmap level 1.或16x16.或10x345.就源代码而言,所有这些都将是完美的功能.显然,它们会产生无意义的纹理,因为纹理不完整.
再次考虑64x64 mipmap 2.我创建它作为我的第一个图像.现在,我可以创建一个128x128 mipmap 1.但我也可以创建一个128x12 9 mipmap 1.这两个都与64x64 mipmap level 2 完全一致(mipmap大小总是向下舍入).虽然它们都是一致的,但它们的尺寸也各不相同.如果驱动程序必须立即分配完整的mipmap链(这是完全可能的),它分配的大小是多少？它不知道.在明确分配其余部分之前,它无法知道.
这是另一个问题.假设我有一个带有完整mipmap链的纹理.根据规则,它完全是纹理完整的.然后我glTexImage2D再次打电话给它.怎么办？我可能会意外更改内部格式.每个mipmap级别都有一个单独的内部格式; 如果他们不同意,那么纹理是不完整的.我可能会意外地改变纹理的大小,再次使纹理不完整.
glTexStorage防止所有这些可能的错误.考虑到基本级别的大小,它会创建您想要的所有mipmap.它使用相同的图像格式分配所有这些mipmap,因此你无法搞砸它.它使纹理不可变,所以你不能过来并尝试用坏的glTexImage2D调用打破纹理.并且它可以防止我甚至懒得覆盖的其他错误.
问题不在于"glTexStorage做了什么？" 现在的问题是"我们为什么走这么长时间没有它."
glTexStorage与...没有关系glGenerateMipmap; 它们是正交功能.glTexStorage完全按照它说的做法:它分配纹理存储空间.它没有用任何东西填充那个空间.因此,它会创建一个给定大小的纹理,并填充未初始化的数据.就像glRenderbufferStorage分配一个填充了未初始化数据的给定大小的渲染缓冲区一样.如果使用glTexStorage,则需要上传数据glTexSubImage(因为glTexImage在不可变纹理上是禁止的).
glTexStorage为mipmap创建空间.glGenerateMipmap创建mipmap数据本身(基础层的较小版本).如果该空间尚不存在,它还可以为mipmap创建空间.它们用于两种不同的东西.