On 22 May 2012 12:12, Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</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 class="im">On Fri, 11 May 2012 11:03:44 -0700, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> 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. </div>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. </blockquote></div> Thanks for the comment. On further rereading, I've realized that the documentation is technically *not* lying, because it's not making any claims about the layout of samples in memory--it's just telling us how the X and Y coordinates are interpreted when sampling from an MSAA buffer. But it's extremely misleading because in the absence of any other documentation, it's natural to assume that samples are laid out in this fashion in memory, and that's not the case. With that accounted for, and correcting a minor error in the actual layout, I've changed the comment to this: /* Adjust width/height for MSAA. * * 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" * * Thus, when sampling from a multisampled texture, it behaves as though * the layout in memory 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) * * However, the actual layout of multisampled data in memory is: * * (0,0,0) (1,0,0) (0,0,1) (1,0,1) * (0,1,0) (1,1,0) (0,1,1) (1,1,1) * * (0,0,2) (1,0,2) (0,0,3) (1,0,3) * (0,1,2) (1,1,2) (0,1,3) (1,1,3) * * This pattern repeats for each 2x2 pixel block. * * 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. */