[Mesa-dev] [PATCH 2/2] meta: Handle bitmaps with alpha test enabled.

Brian Paul brianp at vmware.com
Tue Nov 9 10:57:45 PST 2010


On 11/09/2010 11:00 AM, Francisco Jerez wrote:
> Francisco Jerez<currojerez at riseup.net>  writes:
>
>> Brian Paul<brianp at vmware.com>  writes:
>>
>>>> +static GLboolean
>>>> +alpha_test_bitmap(struct gl_context *ctx)
>>>> +{
>>>> +   struct gl_colorbuffer_attrib *color =&ctx->Color;
>>>> +   GLenum func = (color->AlphaEnabled ? color->AlphaFunc : GL_ALWAYS);
>>>> +   GLubyte ref = FLOAT_TO_UBYTE(color->AlphaRef);
>>>> +   GLubyte alpha = FLOAT_TO_UBYTE(ctx->Current.RasterColor[ACOMP]);
>>>
>>> I don't think we should convert the alpha values to GLubyte here.  If
>>> the hardware does the alpha comparison with floats, the outcome could
>>> be different than comparing with GLubytes.  More on that below.
>>>
>> Doing a floating point comparison on a fixed point color buffer would be
>> incorrect. Fixed point comparison on a floating point color buffer seems
>> to be fine, the spec is very relaxed in that regard.
>>
>>  From ARB_color_buffer_float:
>>
>> |  28. At what precision should alpha test be carried out?  At the
>> |      precision of the framebuffer?  Or some other unspecified
>> |      precision?  What happens if you have a framebuffer with no
>> |      alpha?
>> |
>> |      RESOLVED: No specific precision requirements are added, except
>> |      that the reference value used in the alpha test should be
>> |      converted to the same precision and in the same manner as the
>> |      fragment's alpha. This requirement is intended to avoid cases
>> |      where the act of converting the alpha value of a fragment to
>> |      fixed-point (or lower-precision floating-point) might change the
>> |      result of the test.
>> |
>> |[...]
>> |
>> |  37. Is it expected that a floating-point color read from a
>> |      floating-point color buffer exactly match a floating-point
>> |      color in a fragment?  Will the alpha test of GL_EQUAL
>> |      be expected to work?
>> |
>> |      RESOLVED: This behavior is not required by this extension.
>> |      Floating-point data may have different precision at different
>> |      parts of the pipeline.
>
> Brian, what's your understanding of the text I quoted?

Well, my point was we should do the alpha comparison in floating point 
rather than a quantized GLubyte in that specific place.  Two floats X 
and Y may have different values but quantize down to the same ubyte 
(or ushort or uint) value.  The outcome of a X==Y test could be 
different for floats vs. ints.

Of course, we _could_ do the comparison with ints but we'd have to 
query the number of framebuffer alpha bits, convert the floats to ints 
with the right number of bits, then compare (to match the hardware). 
It seems to be a lot of extra work for no good reason.

-Brian


More information about the mesa-dev mailing list