[Mesa-dev] I need some help about OGL extensions (Was Re: About merging pipe-video to master)
maraeo at gmail.com
Wed Jul 13 17:25:52 PDT 2011
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
2011/7/13 Christian König <deathsimple at 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
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev