| Summary: | gl_FrontColor does not get clamped when FS is enabled | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Jiri Svoboda <jirik.svoboda> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
When a VS is enabled too, the situation is similar. I.e, if the VS does not clamp the color before writing it to gl_FrontColor, then the color doesn't get clamped before interpolation. Again, I believe the FF between vertex and fragment stage should clamp the gl_FrontColor that the VS writes. Again, ATI's implementation seems to do this. Mass version move, cvs -> git This is a driver bug rather than a Mesa core bug. The R300 Gallium3D driver does clamp color varyings to [0,1], so should the classic driver if I didn't miss anything. There is a piglit test for this: glsl-clamp-vertex-color. Closing as it's not a core bug. Feel free to file a new bug against specific drivers. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
When a fragment shader is used, e.g.: "void main() { gl_FragColor = gl_Color;}" along with fixed-functionality lighting, the computed vertex colors do not get clamped, as specified in section 2.14.6 "Clamping or Masking" of OpenGL spec 2.1. Thus, if for example s_cm=(2,2,2), s_cli=(2,2,2), then the hotspot gets much larger, because the vertex colors are nearing (4,4,4) and are not clamped to [0,1]. AFAICT this clamping functionality should not be replaced by neither a VS nor a FS. I also tried this on Windows on R530 with the Catalyst driver and it worked (it got clamped) so the result was exactly the same as when using fixed functionality for both vertex and fragment stage.