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

[Paul Berry]

On 21 May 2012 18:00, Ian Romanick <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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120521/9e3ed039/attachment-0001.html>