On Fri, 11 May 2012 11:03:44 -0700, Paul Berry <stereotype...@gmail.com> wrote:
> Gen6 MSAA buffers (and Gen7 MSAA depth/stencil buffers) interleave
> MSAA samples in a complex pattern that repeats every 2x2 pixel block.
> Therefore, when allocating an MSAA buffer, we need to make sure to
> allocate an integer number of 2x2 blocks; if we don't, then some of
> the samples in the last row and column will be cut off.
>
> Fixes piglit tests "EXT_framebuffer_multisample/unaligned-blit {2,4}
> color msaa" on i965/Gen6.Given that you had to go through this two with us, I think the following comment would help here: /* In the Sandy Bridge PRM, volume 4, part 1, page 31, it says: * * "Any of the other messages (sample*, LOD, load4) used with a * (4x) multisampled surface will in-effect sample a surface with * double the height and width as that indicated in the surface * state. Each pixel position on the original-sized surface is * replaced with a 2x2 of samples with the following arrangement: * * sample 0 sample 2 * sample 1 sample 3" * * You would read this as saying that the layout in memory of a 2x2 * pixel area for (x,y,sample) is: * * (0,0,0) (0,0,2) (1,0,0) (1,0,2) * (0,0,1) (0,0,3) (1,0,1) (1,0,3) * * (0,1,0) (0,1,2) (1,1,0) (1,1,2) * (0,1,1) (0,1,3) (1,1,1) (1,1,3) * * That is a lie. The actual layout is: * * (0,0,0) (1,0,0) (0,0,2) (1,0,2) * (0,1,0) (1,1,0) (0,1,2) (1,1,2) * * (0,0,1) (1,0,1) (0,0,3) (1,0,3) * (0,1,1) (1,1,1) (0,1,3) (1,1,3) * * As a result, when calculating the size of our 4-sample buffer for * an odd width or height, we have to align before scaling up because * sample 3 is in that bottom right 2x2 block. */ I may have swapped pixels (0,1) and (1,0)'s position in the "actual layout" blocks, though.
pgpgHxzebRq72.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
