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

[Francisco Jerez]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20101109/18a3388a/attachment.pgp>