[Mesa-dev] [PATCH 3/7] r600g: fix evergreen 8x MSAA sample positions

[Marek Olšák]

On Tue, Aug 28, 2012 at 2:18 AM, Paul Berry <stereotype441 at gmail.com> wrote:
> On 26 August 2012 18:04, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> On Thu, Aug 23, 2012 at 11:39 PM, Paul Berry <stereotype441 at gmail.com>
>> wrote:
>> > On 23 August 2012 10:42, Marek Olšák <maraeo at gmail.com> wrote:
>> >>
>> >> On Thu, Aug 23, 2012 at 6:42 PM, Paul Berry <stereotype441 at gmail.com>
>> >> wrote:
>> >> > On 22 August 2012 18:54, Marek Olšák <maraeo at gmail.com> 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.
>>
>> 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
>
>
> 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?

There was another issue. The hardware operated at very small subsample
precision, leading to sample positions being rounded or something. I
don't really know how exactly it works. The good thing is it has been
fixed.

Now I get 0.061324 with your sample positions and 0.067873 with mine.

Marek