IIRC, the OpenGL spec says that alpha-test and blending should be done in the precision of a target colorbuffer. For example, if the colorbuffer is UNORM, fragment shader outputs are supposed to be clamped before blending (likely also before alpha-test).
I am not sure how R600 is flexible, but it seemed to me that BLEND_CLAMP strictly depends on the colorbuffer format and isn't just a state where you can set whatever you want (I may be wrong though). On R300-R500, colors are converted to a target colorbuffer format right after shader outputs are written, and alpha-test and blending are carried out in that format. There is no way to have unclamped blend source arguments with UNORM colorbuffers. There is a good reason for that: blending in 8-bit UNORM is a lot faster than the floating-point one. Marek 2011/7/13 Christian König <deathsim...@vodafone.de>: > Am Mittwoch, den 13.07.2011, 18:29 +0200 schrieb Christoph Bumiller: >> > 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. >> >From ARB_color_buffer_float: >> >> 3. How does the clamping control affect the blending equation? >> >> RESOLVED: For fixed-point color buffers, the inputs and the >> result of the blending equation are clamped. For floating-point >> color buffers, no clamping occurs. >> >> So you want to clamp the colour only before blending but NOT after ? > No, just the other way around. I want to DISABLE clamping before > blending, clamping after the blending equation would occur anyway > because of format conversion. One example: > > My fragment shader outputs the value -0.5, the color buffer contains the > value 0.75 and the blending function is ADD. > > For a float buffer (with clamping disabled) I get the expected value of > 0.25, but for an unsigned normalized buffer I still get 0.75, because > the input value -0.5 gets clamped to [0,1] BEFORE blending occurs. > > My expectation was that disabling fragment_color_clamp also disables the > clamping before the blending equation occurs, because it doesn't make so > much sense to me to disable the output clamping, and clamping the value > than anyway because of blending. But that's not the way > "ARB_color_buffer_float" defines it, and also how piglit tests it. > > I have a working workaround, but it is something around 20% slower than > doing it directly with the blender and I would really like to avoid that > overhead. > > Regards, > Christian. > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
