[Mesa-dev] [PATCH 04/15] i965/blorp: Use MSDISPMODE_PERSAMPLE rendering when necessary

[Ian Romanick]

On 05/21/2012 07:16 PM, Paul Berry wrote:
> On 21 May 2012 18:00, Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
>
>     On 05/11/2012 11:03 AM, Paul Berry wrote:
>
>         This patch modifies the "blorp" WM program so that it can be run in
>         MSDISPMODE_PERSAMPLE (which means that every single sample of a
>         multisampled render target is dispatched to the WM program, not just
>         every pixel).
>
>         Previously we were using the ugly hack of configuring multisampled
>         destination surfaces as single-sampled, and generating sample
>         indices
>         other than zero by swizzling the pixel coordinates in the WM
>         program.
>         ---
>           src/mesa/drivers/dri/i965/brw___blorp.h        |   12 ++++
>           src/mesa/drivers/dri/i965/brw___blorp_blit.cpp |   87
>         +++++++++++++++++++-------
>           src/mesa/drivers/dri/i965/__gen6_blorp.cpp     |    5 +-
>           src/mesa/drivers/dri/i965/__gen7_blorp.cpp     |   10 ++-
>           4 files changed, 87 insertions(+), 27 deletions(-)
>
>         diff --git a/src/mesa/drivers/dri/i965/__brw_blorp.h
>         b/src/mesa/drivers/dri/i965/__brw_blorp.h
>         index f14a5c7..b911356 100644
>         --- a/src/mesa/drivers/dri/i965/__brw_blorp.h
>         +++ b/src/mesa/drivers/dri/i965/__brw_blorp.h
>         @@ -132,6 +132,12 @@ const unsigned int
>         BRW_BLORP_NUM_PUSH_CONST_REGS =
>           struct brw_blorp_prog_data
>           {
>              unsigned int first_curbe_grf;
>         +
>         +   /**
>         +    * True if the WM program should be run in
>         MSDISPMODE_PERSAMPLE with more
>         +    * than one sample per pixel.
>         +    */
>         +   bool persample_msaa_dispatch;
>
>
>     (Forgive my ignorance about this general area of the code.)
>       Per-sample shading is also a feature of some later OpenGL version.
>       Is the low-level infrastructure architected so that we could
>     enable this for general use?
>
>
> This patch wouldn't get in the way of enabling per-sample shading for
> general use, but it wouldn't really facilitate it either, since this is
> just using per-sample shading for blits.
>
> Enabling per-sample shading for general use should be pretty
> straightforward.  If I'm not mistaken, all we will need to do is:
>
> - Add the front-end API to allow the client to request per-sample
> shading (I assume it's glEnable(GL_HAM_SANDWICH) or something like that,
> in which case it should be easy)
>
> - Set the MSDISPMODE_PERSAMPLE bit gen{6,7}_wm_state.c (easy).
>
> - Modify the code that configures barycentric interpolation modes so
> that we can interpolate smooth and noperspective varyings to the sample
> location rather than to the pixel center or the centroid.  This will be
> the hardest part, because it will require modifying the fragment shader
> back-end interpolation code to point to the appropriate barycentric
> coordinates depending whether per-sample shading is enabled or not.  But
> I already had to make a similar change to implement the "flat" keyword,
> and I'll have to do something similar very soon for "centroid", so I'm
> not terribly worried.  I'll try to keep this feature in mind when I'm
> implementing "centroid" so that I don't paint us into a corner.
>
> If time allows, I might could roll this feature in with implementing
> "centroid", but I won't make any guarantees because I don't want to
> delay centroid interpolation at the expense of a future feature.  Would
> you mind pointing me to the relevant text in the GL spec so that I can
> read up on it and make sure I'm not missing any subtleties?

Olivier hit most of the high points.  The spec is:

http://www.opengl.org/registry/specs/ARB/sample_shading.txt