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

[Paul Berry]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120827/e4e8996b/attachment.html>