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

[Paul Berry]

On 22 May 2012 10:15, Ian Romanick <idr at freedesktop.org> wrote:

> 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<http://www.opengl.org/registry/specs/ARB/sample_shading.txt>
>

Thanks for the ref.  Looking at the spec, it looks like there would be a
bit more work to do to fully implement the extension:

- Add the gl_SampleID variable to GLSL, and write back-end code to populate
it (should be fairly straightforward)
- Add the gl_SamplePosition variable to GLSL, and write back-end code to
populate it (a bit more work; I think we have to set some additional flags
in 3DSTATE_WM to get this info)
- Add the gl_SampleMask[] variable to GLSL, and write back-end support for
it (ugh, this is going to require some tricky bit swizzling I think*)
- Add the gl_NumSamples mask to GLSL, and write back-end support for it (a
bit of work since I'm less familiar with how uniforms work)

*However, it's possible that I'm going to need to do a lot of this work
anyway to implement the alpha-to-coverage stuff.

On balance I no longer think it's worth trying to roll this extension in
with the initial MSAA implementation.  There's just a bit too much work to
do.

Also, this extension will be *a lot* easier to test after we've implemented
ARB_texture_multisample, because ARB_texture_multisample gives the ability
for client programs to directly query individual samples.

So I'm going to back burner ARB_sample_shading for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120522/c67af043/attachment.htm>