Bug 98851 - triangle clipping causes wrong interpolation of non-perspective corrected attributes
Summary: triangle clipping causes wrong interpolation of non-perspective corrected att...
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/swr (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-25 07:12 UTC by Ilia Mirkin
Modified: 2019-09-18 18:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Ilia Mirkin 2016-11-25 07:12:31 UTC
Sorry for the non-descript subject. I'm just not sure what's wrong. The following test fails:

generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-noperspective-gl_FrontColor-flat-fixed.shader_test

as do many of its friends. Note that the color is meant to be non-perspective-interpolated. Also note that the flat-none.shader_test variant of this works as expected. As does the flat-vertex.shader_test variant after my perspective-interpolation for clip distances fix is applied. So it's something wrong with the clipper.

Comparing to generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-gl_FrontColor-flat-fixed.shader_test, it looks different (which smoothly-interpolates the color). And there's no reason to think that color is being perspective-interpolated, as that is decided in the user frag shader. However I'm not sure what's going on - 1/w is getting messed up perhaps? Not sure.

Furthermore, note that generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-gl_FrontColor-flat-fixed.shader_test does pass with swr, and the only difference is that the color is perspective-interpolated vs no-perspective-interpolated.
Comment 1 Ilia Mirkin 2016-11-25 07:30:09 UTC
One thing I wonder about is whether the clipper needs to know that it's a no-perspective attribute. There's an interpolation step done in clip.h:intersect, and I'm not sure that's right for the non-perspective-correcting case. (I'm also not sure that it's wrong...)
Comment 2 Ilia Mirkin 2016-11-25 07:47:48 UTC
Ah yeah, looks like that's exactly what's going on -

src/gallium/auxiliary/draw/draw_pipe_clip.c:interp has the following logic:

   /**
    * Compute the t in screen-space instead of 3d space to use
    * for noperspective interpolation.
    *
    * The points can be aligned with the X axis, so in that case try
    * the Y.  When both points are at the same screen position, we can
    * pick whatever value (the interpolated point won't be in front
    * anyway), so just use the 3d t.
    */
   if (clip->num_linear_attribs) {
      int k;
      t_nopersp = t;
      /* find either in.x != out.x or in.y != out.y */
      for (k = 0; k < 2; k++) {
         if (in->clip_pos[k] != out->clip_pos[k]) {
            /* do divide by W, then compute linear interpolation factor */
            float in_coord = in->clip_pos[k] / in->clip_pos[3];
            float out_coord = out->clip_pos[k] / out->clip_pos[3];
            float dst_coord = dst->clip_pos[k] / dst->clip_pos[3];
            t_nopersp = (dst_coord - out_coord) / (in_coord - out_coord);
            break;
         }
      }
      for (j = 0; j < clip->num_linear_attribs; j++) {
         const unsigned attr = clip->linear_attribs[j];
         interp_attr(dst->data[attr], t_nopersp, in->data[attr], out->data[attr]);
      }
   }

swr needs to grow a linear-interpolated attribute mask and incorporate the above logic for those.
Comment 3 GitLab Migration User 2019-09-18 18:24:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/190.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.