<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 4:42 PM, Jordan Justen <span dir="ltr"><<a href="mailto:jordan.l.justen@intel.com" target="_blank">jordan.l.justen@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 2016-03-17 01:04:27, Kenneth Graunke wrote:<br> > Yuanhan Liu decided these were useful for linear filtering in<br> > commit 76669381 (circa 2011). Prior to that, we never set them;<br> > it seems he tried to preserve that behavior for nearest filtering.<br> ><br> > It turns out they're useful for nearest filtering, too: setting<br> > these fixes the following dEQP-GLES3 tests:<br> ><br> > functional.fbo.blit.rect.nearest_consistency_mag<br> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x<br> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_y<br> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_min<br> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_x<br> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_y<br> > functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_x<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_y<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_x<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_y<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_y<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_x<br> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_y<br> ><br> > Apparently, BLORP has always set these bits unconditionally.<br> ><br> > However, setting them unconditionally appears to regress tests using<br> > texture projection, 3D samplers, integer formats, and vertex shaders,<br> > all in combination, such as:<br> ><br> > functional.shaders.texture_functions.textureprojlod.isampler3d_vertex<br> ><br> > Setting them on Gen4-5 appears to regress Piglit's<br> > tests/spec/arb_sampler_objects/framebufferblit.<br> ><br> > Honestly, it looks like the real problem here is a lack of precision.<br> > I'm just hacking around problems here (as embarassing as it is).<br> ><br> > Signed-off-by: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>><br> > ---<br> > src/mesa/drivers/dri/i965/brw_sampler_state.c | 9 ++++++---<br> > 1 file changed, 6 insertions(+), 3 deletions(-)<br> ><br> > diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c b/src/mesa/drivers/dri/i965/brw_sampler_state.c<br> > index c20a028..d53cb5d 100644<br> > --- a/src/mesa/drivers/dri/i965/brw_sampler_state.c<br> > +++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c<br> > @@ -436,14 +436,17 @@ brw_update_sampler_state(struct brw_context *brw,<br> > }<br> > }<br> ><br> > - /* Set address rounding bits if not using nearest filtering. */<br> > + /* Set address rounding bits. The conditions are empirically<br> > + * derived in order to pass test cases.<br> > + */<br> > + bool round_nearest = brw->gen >= 6 && target != GL_TEXTURE_3D;<br> > unsigned address_rounding = 0;<br> > - if (min_filter != BRW_MAPFILTER_NEAREST) {<br> > + if (min_filter != BRW_MAPFILTER_NEAREST || round_nearest) {<br></div></div></blockquote><div><br>I feel the need to state, for the record, that this is super-sketchy. Then again, given that GL doesn't really specify what we're supposed to do on the edges of a NEAREST sampling, it doesn't much matter. That's explcitly *not* a NAK, just a comment on the sketcyness of the whole thing.<br><br>I don't think it's too sketchy to merge, but it may be a good candidate for the "pass dEQP" branch?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"> <br> </div></div>How about folding the min_filter != BRW_MAPFILTER_NEAREST test into<br> round_nearest?<br> <br> Reviewed-by: Jordan Justen <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>><br> <div class=""><div class="h5"><br> > address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MIN |<br> > BRW_ADDRESS_ROUNDING_ENABLE_V_MIN |<br> > BRW_ADDRESS_ROUNDING_ENABLE_R_MIN;<br> > }<br> > - if (mag_filter != BRW_MAPFILTER_NEAREST) {<br> > + if (mag_filter != BRW_MAPFILTER_NEAREST || round_nearest) {<br> > address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MAG |<br> > BRW_ADDRESS_ROUNDING_ENABLE_V_MAG |<br> > BRW_ADDRESS_ROUNDING_ENABLE_R_MAG;<br> > --<br> > 2.7.3<br> ><br> > _______________________________________________<br> > mesa-dev mailing list<br> > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> _______________________________________________<br> mesa-dev mailing list<br> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> </div></div></blockquote></div><br></div></div>