[Mesa-dev] Looking for advice on how MSAA should behave under sRGB

Paul Berry stereotype441 at gmail.com
Thu Jun 7 04:45:27 CEST 2012


On 6 June 2012 19:35, Roland Scheidegger <sroland at vmware.com> wrote:

> Am 07.06.2012 01:27, schrieb Paul Berry:
> > In my current implementation of MSAA for i965, I'm facing a choice in
> > how to perform MSAA resolves when sRGB is in use.  Should I:
> >
> > (a) always combine samples using a linear average.  For example, if
> > multisampling by a factor of 4, and the 4 samples corresponding to a
> > pixel have color values of a, b, c, and d, resolve them to a pixel color
> > of (a+b+c+d)/4.
> >
> > (b) first convert the samples from sRGB to linear, then combine them
> > using a linear average, then convert back to sRGB.
> >
> > (c) try to make an educated guess between (a) and (b) based on what the
> > client program is doing.
> >
> >
> > The GL 3.0 spec seems to pull towards (a), but it leaves a great deal of
> > latitude to the implementation.  From 4.1.12 (Additional Multisample
> > Fragment Operations):
> >
> > "After all operations have been completed on the multisample buffer, the
> > sample values for each color in the multisample buffer are combined to
> > produce a single color value, and that value is written into the
> > corresponding color buffers selected by DrawBuffer or DrawBuffers. An
> > implementation may defer the writing of the color buffers until a later
> > time, but the state of the framebuffer must behave as if the color
> > buffers were updated as each fragment was processed. The method of
> > combination is not specified, though a simple average computed
> > independently for each color component is recommended."
>
> I believe this is an oversight in the 3.0 specification, all later ones
> have this instead (yes there's a typo in there not my fault...): "...
> was processed. The method of combination is not specified. If the
> framebuffer contains sRGB values, then it is recommended that the an
> average of sample values is computed in a linearized space, as for
> blending (see section 4.1.7). Otherwise, a simple average computed
> independently for each color component is recommended."
>

Aha, you're right!  Serves me right for looking at the 3.0 spec all the
time.  Thanks for pointing this out.  That pretty well resolves the
question, IMHO.


>
> And really that behavior makes sense to me. All operations are defined
> to happen in linear space, like blending, why should resolve be different?
>

Yeah, I agree.  This behaviour does seem the most sensible.


>
> Roland
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120606/3aae0149/attachment.htm>


More information about the mesa-dev mailing list