On 26 August 2012 18:04, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div>On Thu, Aug 23, 2012 at 11:39 PM, Paul Berry <<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.com</a>> wrote: > On 23 August 2012 10:42, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: >> >> On Thu, Aug 23, 2012 at 6:42 PM, Paul Berry <<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.com</a>> >> wrote: >> > On 22 August 2012 18:54, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: >> >> >> >> The original samples positions took samples outside of the pixel >> >> boundary, >> >> leading to dark pixels on the edge of the colorbuffer, among other >> >> things. >> > >> > >> > Does this address the issues you were having with the error thresholds >> > in >> > the EXT_framebuffer_multisample piglit tests (Re: your Aug 13 email >> > "[Piglit] [PATCH] ext_framebuffer_multisample: relax MSAA precision")? >> >> Yes, it does. The accuracy tests now pass for me. >> >> Marek > > > Excellent. Glad to hear it. </div></div>Sorry, the tests actually don't pass, I tested with the piglit patch applied. :( However this patch reduces the error quite a lot, it's just not enough. I guess I have to choose the sample positions very carefully. Marek </blockquote></div> If it helps any, here are the positions I used for 8x MSAA on Intel hardware (from src/mesa/drivers/dri/i965/gen6_multisample_state.c). I don't know what the capabilities of r600g are, but if it can reproduce the same sample positions that would be a nice quick way to double check whether the remaining inaccuracy is caused by sample positions: * Sample positions: * 1 3 5 7 9 b d f * 1 5 * 3 2 * 5 6 * 7 4 * 9 0 * b 3 * d 1 * f 7 Intel hardware specifies the sample positions in offsets of 1/16 pixel, with 8=pixel center, so for example in the above diagram, sample number 2 has x coordinate of 0xb, meaning 3/16 pixel to the right of center. I *think* that means you'll have to subtract 8 from each coordinate to get the values you want to use on r600g. Here's the results I get for "ext_framebuffer_multisample-accuracy 8 color" on Ivy Bridge: Pixels that should be unlit count = 214644 Perfect output Pixels that should be totally lit count = 28972 Perfect output Pixels that should be partially lit count = 18528 RMS error = 0.060891 The error threshold for this test is 0.071928 I also tried using your sample positions with the Intel driver (I think I'm interpreting eg_sample_locs_8x correctly), and I got these results: Pixels that should be unlit count = 214644 Perfect output Pixels that should be totally lit count = 28972 Perfect output Pixels that should be partially lit count = 18528 RMS error = 0.068037 The error threshold for this test is 0.071928 Which also passes, but by a narrower margin. I'm curious what results you are getting. Perhaps there is a problem with downsampling?