似乎我对与图像加载/存储相关的OpenGL格式转换完全感到困惑。我来自DX世界，那里的事物相对清晰。例如：
RGBA32_FLOAT）RWTexture2D<float4>声明与格式匹配的RW纹理您还可以将说RGBA8_UNORM纹理绑定到RWTexture2D<float4>，DirectX将以显而易见的方式执行格式转换。
现在说我想在OpenGL中做同样的事情。所以我
layout(rgba32f) uniform image2D myImg;glBindImageTexture( ..., GL_RGBA32F);因此，我计算了四个指定格式的地方：
声明图像单位两次：
layout(rgba32f)image2D本身告诉我所有加载/存储操作都将执行vec4（不是ivec4或uvec4）当我与 glBindImageTexture
我无法理解的目的layout(rgba32f)，这似乎完全是多余的。似乎知道内部纹理格式足以执行所有格式转换。如果我的内部纹理格式被规范化RGBA8并且图像定义为，我需要指定哪种布局uniform image2D myImg;？为什么我需要完全指定布局，不清楚是否应该执行哪种格式转换？我唯一能证明这些布局合理的想法是执行数据重新解释，例如将原始RGBA32F数据写入RGBA32U纹理，这对我来说似乎不是很有用。此外，您可以使用类似的功能floatBitsToInt()来完成这项工作。
传递格式的目的是什么，这glBindImageTexture对我来说完全是个谜。
因此，所有这些布局对我来说都是一个巨大的困惑源。您能帮我更好地理解它们背后的原因吗？
对我来说，将格式传递给glBindImageTexture的目的是什么？
在GL中，通常可以在相关扩展规范的“问题”部分中找到特定API决策背后的原因。在这种情况下，GL_ARB_shader_image_load_store扩展的第31期可能会有所帮助：
（31）为什么在上有一个
format参数BindImageTexture？解决：它允许进行一些位广播，以一种格式使用另一种格式查看纹理。除了查看具有不同格式的纹理有任何好处外，它还允许通过使用
R32I或R32UI格式查看原子，从而对某些多成分纹理进行原子操作。在
EXT_shader_image_load_store扩展，还有一个额外的好处来工作围绕一个更严格的限制上的一组支持的存储格式-只格式，如R8，R16，R32F，RG32F，RGBA32F是否有支持。那里不支持的其他格式可以看作是受支持的格式（例如，RGBA8可以映射到R32UI），着色器代码可以进行任何所需的打包和拆包。
因此，应该将内部纹理格式和图像格式视为两种不同的事物。它们确实必须兼容，但是不必匹配。
我无法理解的目的
layout(rgba32f)，这似乎完全是多余的。似乎知道内部纹理格式足以执行所有格式转换。
图像的内部格式（不是texture）就足够了-但是该信息不是着色器状态的一部分，并且在着色器编译时未知。GL并没有将其抽象到用户的背后。布局限定符中的格式必须与关联的图像单元的格式完全匹配，否则结果将不确定。着色器只会以指定的格式读取或写入数据，如果与实际的格式不匹配，您将被搞砸，并且规格不保证任何内容。
如果我的内部纹理格式是归一化RGBA8，并且图像定义为
uniform image2D myImg，则需要指定哪种布局；
layout(rgba8) 是根据规范在这种情况下唯一允许的一种。
我唯一能证明这些布局合理的想法是执行数据重新解释，例如将原始
RGBA32F数据写入RGBA32U纹理，这对我来说似乎不是很有用。
你实际上倒退了。将layout(format)不允许重新解释，该format参数glBindImageTexture()确实，至少在一个有限的方式。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句