glPixelStorei(GL_UNPACK_ALIGNMENT，1)的缺点？

Question

总是使用% 1的海藻有什么缺点？

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

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

Answer 1

数据怎么可能不是1字节对齐的？

这强烈地表明了对row alignment in pixel transfer operations means的缺乏理解。

您传递给OpenGL的图像数据应该分组成行。每行包含width个像素，每个像素的大小由格式和类型参数定义。因此，具有GL_UNSIGNED_BYTE类型的GL_RGB格式将产生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编写器，否则这是不太可能的)，则需要将行对齐方式设置为您的图像格式所使用的方式。

Answer 2

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

不是，因为像素存储设置只与GPU之间的数据传输相关，即数据对齐。一旦在GPU内存中，它就可以以GPU和驱动程序所需的任何方式对齐。

Answer 3

这不会对性能产生影响。设置更高的对齐方式(在openGL中)不会改善任何事情，也不会加快任何事情。

所有对齐所做的就是告诉openGL在哪里期望下一行像素。如果图像像素紧密堆积，也就是说，如果在字节行的结束位置和新行的开始位置之间没有间隙，则应始终使用1对齐。

默认对齐方式为4 (即openGL期望下一行像素位于可被4整除的内存跳转之后)，这可能会在加载不是4字节浮点数的R、RG或RGB纹理，或者宽度不能被4整除的情况下导致问题。如果图像像素被紧密打包，则必须将对齐方式更改为1，以便解包工作。

你可以(我个人没有遇到过)有一个3x3RGB ubyte的图像，它的行是第四对齐的，最后用3个额外的字节作为填充。哪些行可能如下所示：

R-G-B-X-X-X(共16字节)

原因是对齐的数据提高了处理器的性能(不确定在今天的处理器上这是正确的/合理的)。如果你可以控制原始图像的合成方式，那么也许以某种方式对齐它会改善对它的处理。但这是在openGL之前完成的。OpenGL没有办法改变这一点，它只关心在哪里找到像素。

因此，回到上面的3x3图像行-将对齐设置为4会很好(也是必要的)跳过最后一个填充。如果您将其设置为1，那么它将弄乱您的结果，因此您需要将其保留/恢复为4。(请注意，您也可以使用ROW_LENGTH跳过它，因为这是在处理图像的子集时使用的参数，在这种情况下，您有时必须跳转超过3或7字节(这是对齐参数8所能提供的最大值)。在我们的示例中，如果您提供的行长为4，并且对齐方式为1，则也可以)。

包装也是如此。您可以告诉openGL将像素行对齐为1、2、4和8。如果您要保存3x3 RGB ubyte，则应将对齐设置为1。从技术上讲，如果您希望结果行紧凑在一起，则应始终设置为1。如果您(无论出于何种原因)想要创建一些填充，您可以给出另一个值。如果(在我们的示例中) PACK_ALIGNMENT为4，则会创建与上面的行类似的行(末尾有3个额外的填充)。注意，在这种情况下，您的包含对象(openCV mat、位图等)应该能够接收到额外的填充。