<div class="gmail_quote">On 6 June 2012 19:35, Roland Scheidegger <span dir="ltr"><<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 07.06.2012 01:27, schrieb Paul Berry:<br>
<div class="im">> In my current implementation of MSAA for i965, I'm facing a choice in<br>
> how to perform MSAA resolves when sRGB is in use. Should I:<br>
><br>
> (a) always combine samples using a linear average. For example, if<br>
> multisampling by a factor of 4, and the 4 samples corresponding to a<br>
> pixel have color values of a, b, c, and d, resolve them to a pixel color<br>
> of (a+b+c+d)/4.<br>
><br>
> (b) first convert the samples from sRGB to linear, then combine them<br>
> using a linear average, then convert back to sRGB.<br>
><br>
> (c) try to make an educated guess between (a) and (b) based on what the<br>
> client program is doing.<br>
><br>
><br>
> The GL 3.0 spec seems to pull towards (a), but it leaves a great deal of<br>
> latitude to the implementation. From 4.1.12 (Additional Multisample<br>
> Fragment Operations):<br>
><br>
> "After all operations have been completed on the multisample buffer, the<br>
> sample values for each color in the multisample buffer are combined to<br>
> produce a single color value, and that value is written into the<br>
> corresponding color buffers selected by DrawBuffer or DrawBuffers. An<br>
> implementation may defer the writing of the color buffers until a later<br>
> time, but the state of the framebuffer must behave as if the color<br>
> buffers were updated as each fragment was processed. The method of<br>
> combination is not specified, though a simple average computed<br>
> independently for each color component is recommended."<br>
<br>
</div>I believe this is an oversight in the 3.0 specification, all later ones<br>
have this instead (yes there's a typo in there not my fault...): "...<br>
was processed. The method of combination is not specified. If the<br>
framebuffer contains sRGB values, then it is recommended that the an<br>
average of sample values is computed in a linearized space, as for<br>
blending (see section 4.1.7). Otherwise, a simple average computed<br>
<div class="im">independently for each color component is recommended."<br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
</div>And really that behavior makes sense to me. All operations are defined<br>
to happen in linear space, like blending, why should resolve be different?<br></blockquote><div><br></div><div>Yeah, I agree. This behaviour does seem the most sensible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Roland<br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div><br>