Hi Henri and everybody else on the list, Am Dienstag, den 12.07.2011, 19:01 +0200 schrieb Henri Verbeet: > I guess my point was mostly that there's not much of a point in doing > the clamping both through BLEND_CLAMP and the fragment shader. Also, I > guess we need this for EG+ as well. Oh, I got quite a problem here: After your mail I created patches to push the changes to r600g separately into master. While doing so I also checked that there are no piglit regressions, unfortunately the "arb_color_buffer_float" test is now failing.
After reading "ARB_color_buffer_float" extension (again) and checking that against the r600 documentation, I realized that the behavior of the BLEND_CLAMP bit on r600 hardware has nothing todo with clamping the fragment color. As the name of this (well documented) hardware flag already implies: It just disabled clamping the output of the fragment shader BEFORE blending to a normalized buffer. My problem now is that I can't find any OpenGL extension that controls such a behavior, and also Direct 3D doesn't seems to have such a flag. So what I got now is a hardware feature that makes perfectly sense for video decoding, but doesn't seems to have an equivalent in the 3D world. The situation is very similarly to the "interlaced" textures feature, it doesn't makes sense for a 3D app to use such a feature, so mesa doesn't have an interface for it, but it would be really (REALLY) useful if you want to decode video streams. So any ideas guys? Should I just add an additional flag to the blender and hope that the other hardware vendors do it in the same way? Or do I need to find a workaround to do this without this feature? Or maybe anybody know a OpenGL extension that's currently not implemented and does exactly what BLEND_CLAMP does? Regards, Christian. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
