glPixelStorei(GL_UNPACK_ALIGNMENT,1)缺点？

Question

glPixelStorei(GL_UNPACK_ALIGNMENT,1)缺点？

ron*_*nag 28 c++ opengl textures alignment pbo

总是使用1的alginment有什么缺点？

glPixelStorei(GL_UNPACK_ALIGNMENT, 1)
glPixelStorei(GL_PACK_ALIGNMENT, 1)

Run Code Online (Sandbox Code Playgroud)

它会影响现代gpus的性能吗？

Answer 1

Nic*_*las 44

数据如何不是1字节对齐的？

这强烈表明缺乏对像素传输操作中行对齐的含义的理解.

传递给OpenGL的图像数据应该按行分组.每行包含width像素数,每个像素的大小由格式和类型参数定义.因此,GL_RGB具有类型的格式GL_UNSIGNED_BYTE将导致像素的大小为24位.否则期望像素被打包,因此这些像素中的16行将占用48个字节.

期望每一行在特定值上对齐,如由GL_PACK/UNPACK_ALIGNMENT.这意味着您添加到指针以获取到下一行的值是:align(pixel_size * width, GL_*_ALIGNMENT).如果像素大小为3字节,宽度为2,对齐为1,则行字节大小为6.如果对齐为4,则行字节大小为8.

看到问题？

图像数据可能来自某些图像文件格式,如某些图像加载器所加载的,具有行对齐.有时这是1字节对齐,有时不是.DDS图像具有指定为格式一部分的对齐.在许多情况下,图像具有4字节行对齐; 因此,小于32位的像素大小将在具有特定宽度的行的末尾处具有填充.如果你给OpenGL的对齐方式不匹配,那么你会得到格式错误的纹理.

您将对齐设置为与图像格式的对齐方式匹配.如果您知道或以其他方式可以确保行对齐始终为1(除非您编写自己的图像格式或DDS编写器,否则这种情况不太可能),您需要将行对齐设置为图像格式使用的行对齐方式.

尼科尔的答案是现场,但我仍然困惑了一段时间数据如何不是1字节对齐.对于那些坚持这一点的人,假设您从图像加载库获取数据,您没有控制数据,因此您无法控制布局.假定可以在每行的末尾使用对齐字节导入数据.这种对齐是您指定的.希望这有助于某人! (5认同)
@ronag:这里有很多不同的变量,你正在考虑最复杂的选项,这基本上是为了重新实现应用程序中的OpenGL解包器,希望它可能更快.您猜测RGB - > BGRA转换"可能大约为1%的开销"这一事实意味着您可能还没有为此做好准备 - 这种猜测没有通过气味测试有几个原因(聊天)如果你想要他们).假设您可以发布基准数据,也许您希望切换到聊天,或者打开另一个关于提高应用程序性能的问题. (4认同)
@sepideh:因为这就是*alignment*的含义.每一行必须以对齐的偶数倍开始.32是8的下一个偶数倍,高于27. (3认同)
@ronag:你不太可能超过解包器的性能,这是使用SIMD编写的一个非常复杂的功能.这听起来像很多工作,必须通过基准测试证明你的应用程序受上传速度限制***上传速度受到解包器的不利影响. (2认同)
@ronag:1)你不会打败OpenGL的解包器.2)即使你要击败它,PBO解包也是*异步*,这需要你的应用程序显式使用线程.3)优化这种方法的正确方法是对各种不同的格式进行基准测试,直到找到硬件原生支持的格式(即:最快的格式),然后**预处理**您的数据,使它们符合要求对那些.格式/类型值比行对齐更重要. (2认同)

Answer 2

dat*_*olf 11

它会影响现代gpus的性能吗？

不,因为像素存储设置仅与从GPU传输数据或与GPU传输数据相关,即数据的对齐.一旦进入GPU内存,它就会以GPU和驱动程序所需的任何方式对齐.

我问是否以及何时可能影响gpu上传/下载以及是否还有其他方面我需要考虑. (5认同)
我认为他在询问一个或多个GPU是否需要CPU在上传之前对数据进行一些修改.也就是说,如果GPU无法处理字节对齐的行. (4认同)
@ronag:嗯,如果GPU无法处理原始数据的数据格式,那么数据格式需要先由驱动程序转换.但是,由于您总是偶尔上传纹理数据,因此只消耗很少的CPU时间.但是,数据传输并不是我认为的GPU性能问题.瓶颈显然是那里的CPU和数据总线. (2认同)

归档时间：	13 年，2 月前
查看次数：	15618 次
最近记录：	6 年，5 月前