tl; dr; dr：在启用混合时，在什么情况下夹紧了什么值？
- 片段着色器输出？
- 混合因素？
- 混合方程的结果？
- 其他？
我发现的夹紧机制：
-
着色器输出（通过
glClampColor）：这似乎可以控制glReadPixels，但是有扩展标志GL_CLAMP_VERTEX_COLOR和GL_CLAMP_FRAGMENT_COLOR可以执行"某物"。据我所知，从扩展规范中，它们从顶点或碎片着色器夹住输出。 - 着色器输出（通过渲染到定点）：请参阅此答案，引用GL规格。：" 从浮点值F到相应的未签名固定固定的固定固定的转换 - 点值c是通过将f到范围[0，1]的范围[0，1]的定义（相比之下）>碎片着色器写的内容将始终被揭开。"。
-
隐含夹具：从
glBlendFunc的文档中：" 所有比例因素都有范围[0,1]。"。 方程式发生？ -
隐含夹紧：从
glBlendEquation的文档中："对于这些方程式，所有颜色组件都可以理解为具有范围内的值[0,1]。"这样做是指方程式之前将源和目的地颜色夹紧？ - 结果夹紧：从同一页面：" 这些方程的结果被夹在范围[0,1]。" " "
在我对RGBA_F32渲染目标的实验中，这些夹紧模式均未发生（我通过使用glGetTexImage的渲染目标回报值来确认这一点）。我最好（3）发生（3），但是我要求对文档进行澄清，以便我自己弄清楚。
您引用的内容的一部分非常旧，可能是混乱的根源。我从 Modern gl的角度浏览您的观点，我将为此援引OpenGL 4.5核心配置文件规格。但是，这些都不是OpenGL 4.x的特定特定的。由于GL 3.2核心。
，这基本上是没有变化的1。 glClampColor()的仅剩余功能在glReadPixels期间夹住。引用第680页的规格：
请注意，
FrontFace和ClampColor命令未弃用，因为它们仍然会影响其他非剥夺功能；但是，那ClampColor目标CLAMP_VERTEX_COLOR和CLAMP_FRAGMENT_COLOR是 弃用。"
夹紧顶点着色器输出仅对于剥夺的内置素（如gl_FrontColor，gl_BackColor等）而言是有意义的。这些只需要模仿固定功能的顶点处理，并且根本不是一个好主意。使用通用输出，GL没有机会知道哪些值是颜色，哪些是颜色。
2。片段着色器的情况相似。使用现代渲染方法，输出不一定会再染色，而是代表通用数据，因此隐含地夹紧值是有害的。如果您愿意，您总是可以手动夹着着色器中的值。
在GL 4.5规格中，Spec reto reto Koradi的答案的报价没有变化。仅当相应的渲染目标为定点或整数格式时，着色器输出才会被夹紧。
3.，4。和5。这些文档已过时。GL规范在第17.3.8节中对此表示了这一说法：
如果颜色缓冲区是定点，则是源的组成部分 目标值和混合因子每个都夹紧到[0;1]或 [-1;1]分别用于未签名的归一化或签名 在评估混合方程之前的颜色缓冲区。如果颜色 缓冲区是浮点，没有夹紧。由此产生的四个 值发送到下一个操作。仅在 颜色缓冲区具有固定点或浮点格式。如果颜色 缓冲区具有整数格式，继续进行下一个操作。
混合结果的夹紧发生在下一步中，该步骤处理可选的SRGB转换（但是，夹紧步骤与SRGB转换有关）。引用第17.3.9节：
R，G和B的结果CS值，未修饰的A形式A 新的RGBA颜色值。如果颜色缓冲区是定点，则每个 组件夹在[0;1]然后转换为 使用公式2.3的定点值。由此产生的四个值是 发送到随后的抖动操作。
是的，当使用GL_RGBA32F Framebuffer时， no 隐式夹紧完全会发生。实际上，这是通用情况的唯一有用的操作方式。如果您需要在第3步中发生一些夹具：将其发送到glBlendFunc()之前，请夹紧因素。