<div class="gmail_quote">On 21 May 2012 18:00, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 05/11/2012 11:03 AM, Paul Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch modifies the "blorp" WM program so that it can be run in<br>
MSDISPMODE_PERSAMPLE (which means that every single sample of a<br>
multisampled render target is dispatched to the WM program, not just<br>
every pixel).<br>
<br>
Previously we were using the ugly hack of configuring multisampled<br>
destination surfaces as single-sampled, and generating sample indices<br>
other than zero by swizzling the pixel coordinates in the WM program.<br>
---<br>
src/mesa/drivers/dri/i965/brw_<u></u>blorp.h | 12 ++++<br>
src/mesa/drivers/dri/i965/brw_<u></u>blorp_blit.cpp | 87 +++++++++++++++++++-------<br>
src/mesa/drivers/dri/i965/<u></u>gen6_blorp.cpp | 5 +-<br>
src/mesa/drivers/dri/i965/<u></u>gen7_blorp.cpp | 10 ++-<br>
4 files changed, 87 insertions(+), 27 deletions(-)<br>
<br>
diff --git a/src/mesa/drivers/dri/i965/<u></u>brw_blorp.h b/src/mesa/drivers/dri/i965/<u></u>brw_blorp.h<br>
index f14a5c7..b911356 100644<br>
--- a/src/mesa/drivers/dri/i965/<u></u>brw_blorp.h<br>
+++ b/src/mesa/drivers/dri/i965/<u></u>brw_blorp.h<br>
@@ -132,6 +132,12 @@ const unsigned int BRW_BLORP_NUM_PUSH_CONST_REGS =<br>
struct brw_blorp_prog_data<br>
{<br>
unsigned int first_curbe_grf;<br>
+<br>
+ /**<br>
+ * True if the WM program should be run in MSDISPMODE_PERSAMPLE with more<br>
+ * than one sample per pixel.<br>
+ */<br>
+ bool persample_msaa_dispatch;<br>
</blockquote>
<br></div></div>
(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?<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Enabling per-sample shading for general use should be pretty straightforward. If I'm not mistaken, all we will need to do is:</div><div><br></div><div>- 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)</div>
<div><br></div><div>- Set the MSDISPMODE_PERSAMPLE bit gen{6,7}_wm_state.c (easy).</div><div><br></div><div>- 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.</div>
<div><br></div><div>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?</div>
</div>