Skip to content
Snippets Groups Projects
  1. Feb 03, 2014
  2. Jan 31, 2014
    • Anuj Phogat's avatar
      i965: Ignore 'centroid' interpolation qualifier in case of persample shading · 559d9b89
      Anuj Phogat authored and Carl Worth's avatar Carl Worth committed
      
      This patch handles the use of 'centroid' qualifier with 'in' variables
      in a fragment shader when persample shading is enabled. Per sample
      shading for the whole fragment shader can be enabled by:
      glEnable(GL_SAMPLE_SHADING) or using {gl_SamplePosition, gl_SampleID}
      builtin variables in fragment shader. Explaining it below in more
      detail.
      
      /* Enable sample shading using OpenGL API */
      glEnable(GL_SAMPLE_SHADING);
      glMinSampleShading(1.0);
      
      Example fragment shader:
      in vec4 a;
      centroid in vec4 b;
      main()
      {
        ...
      }
      
      Variable 'a' will be interpolated at sample location. But, what
      interpolation should we use for variable 'b' ?
      
      ARB_sample_shading recommends interpolation at sample position for
      all the variables. GLSL 400 (and earlier) spec says that:
      
      "When an interpolation qualifier is used, it overrides settings
      established through the OpenGL API."
      But, this text got deleted in later versions of GLSL.
      
      NVIDIA's and AMD's proprietary linux drivers (at OpenGL 4.3)
      interpolates at sample position. This convinces me to use
      the similar approach on intel hardware.
      
      Signed-off-by: default avatarAnuj Phogat <anuj.phogat@gmail.com>
      Reviewed-by: default avatarChris Forbes <chrisf@ijw.co.nz>
      (cherry picked from commit f5cfb4ae)
      
      and
      
      i965: Ignore 'centroid' interpolation qualifier in case of persample shading
      
      I missed this change in commit f5cfb4ae. It fixes the incorrect
      rendering caused in Dolphin Emulator.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73915
      
      
      
      Signed-off-by: default avatarAnuj Phogat <anuj.phogat@gmail.com>
      Tested-by: default avatarMarkus Wick <wickmarkus@web.de>
      Reviewed-by: default avatarMatt Turner <mattst88@gmail.com>
      (cherry picked from commit dc2f94bc)
      559d9b89
    • Anuj Phogat's avatar
      i965: Use sample barycentric coordinates with per sample shading · 765e3d37
      Anuj Phogat authored and Carl Worth's avatar Carl Worth committed
      
      Current implementation of arb_sample_shading doesn't set 'Barycentric
      Interpolation Mode' correctly. We use pixel barycentric coordinates
      for per sample shading. Instead we should select perspective sample
      or non-perspective sample barycentric coordinates.
      
      It also enables using sample barycentric coordinates in case of a
      fragment shader variable declared with 'sample' qualifier.
      e.g. sample in vec4 pos;
      
      A piglit test to verify the implementation has been posted on piglit
      mailing list for review.
      
      V2: Do not interpolate all the 'in' variables at sample position
          if fragment shader uses 'sample' qualifier with one of them.
          For example we have a fragment shader:
          #version 330
          #extension ARB_gpu_shader5: require
          sample in vec4 a;
          in vec4 b;
          main()
          {
            ...
          }
      
          Only 'a' should be sampled at sample location, not 'b'.
      
      Signed-off-by: default avatarAnuj Phogat <anuj.phogat@gmail.com>
      Reviewed-by: default avatarChris Forbes <chrisf@ijw.co.nz>
      (cherry picked from commit a92e5f7c)
      765e3d37
    • Carl Worth's avatar
      cherry-ignore: Ignore 4 patches at teh request of the author, (Anuj). · ae286af0
      Carl Worth authored
      For 3 of the 4, I was already ignoring them since they were not picking
      cleanly. Now, Anuj has explicitly requested they be ignored since they all
      depend on a series that is not yet on the 10.0 branch.
      ae286af0
    • Jose Fonseca's avatar
      mesa: Use IROUND instead of roundf. · ed437df2
      Jose Fonseca authored and Carl Worth's avatar Carl Worth committed
      roundf is not available on MSVC.
      
      (cherry picked from commit bba8f105)
      ed437df2
    • Lina Versace's avatar
      i965/gen6/blorp: Emit more flushes to workaround hangs · f7848574
      Lina Versace authored and Carl Worth's avatar Carl Worth committed
      
      This is a squash of three related cherry-picks from master.
      
      [PATCH 1/3]
      
        i965/gen6/blorp: Set need_workaround_flush immediately after primitive
      
        This patch makes the workaround code in gen6 blorp follow the pattern
        established in the regular draw path. It shouldn't result in any
        behavioral change.
      
        On gen6, there are two places where we emit 3D_CMD_PRIM: brw_emit_prim()
        and gen6_blorp_emit_primitive().  brw_emit_prim() sets
        need_workaround_flush immediately after emitting the primitive, but
        blorp does not. Blorp sets need_workaround_flush at the bottom of
        brw_blorp_exec().
      
        This patch moves the need_workaround_flush from brw_blorp_exec() to
        gen6_blorp_emit_primitive().  There is no need to set
        need_workaround_flush in gen7_blorp_emit_primitive() because the
        workaround applies only to gen6.
      
      Reviewed-by: default avatarPaul Berry <stereotype441@gmail.com>
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
        (cherry picked from commit 5e0cd58d)
      
      [PATCH 2/3]
      
        i965/gen6/blorp: Set need_workaround_flush at top of blorp
      
        Unconditionally set brw->need_workaround_flush at the top of gen6 blorp
        state emission.
      
        The art of emitting workaround flushes on Sandybridge is mysterious and
        not fully understood. Ken and I believe that
        intel_emit_post_sync_nonzero_flush() may be required when switching from
        regular drawing to blorp.  This is an extra safety measure to prevent
        undiscovered difficult-to-diagnose gpu hangs.
      
        I verified that on ChromeOS, pre-patch, need_workaround_flush was not
        set at the top of blorp, as Paul expected. To verify, I inserted the
        following debug code at the top of gen6_blorp_exec(), restarted the ui,
        and inspected the logs in /var/log/ui. The abort gets triggered so early
        that the browser never appears on the display.
      
            static void
            gen6_blorp_exec(...)
            {
                if (!brw->need_workaround_flush) {
                    fprintf(stderr, "chadv: %s:%d\n", __FILE__, __LINE__);
                    abort();
                }
                ...
            }
      
        CC: Kenneth Graunke <kenneth@whitecape.org>
        CC: Stéphane Marchesin <marcheu@chromium.org>
      Reviewed-by: default avatarPaul Berry <stereotype441@gmail.com>
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
        (cherry picked from commit 6a5c86f4)
      
      [PATCH 3/3]
      
        i965/gen6/blorp: Remove redundant HiZ workaround
      
        Commit 1a928816 added extra flushes to fix a HiZ hang in
        WebGL Google Maps. With the extra flushes emitted by the previous two
        patches, the flushes added by 1a928816 are redundant.
      
        Tested with the same criteria as in 1a928816: by zooming in and out
        continuously for 2 hours on Sandybridge Chrome OS (codename
        Stumpy) without a hang.
      
        CC: Kenneth Graunke <kenneth@whitecape.org>
        CC: Stéphane Marchesin <marcheu@chromium.org>
      Reviewed-by: default avatarPaul Berry <stereotype441@gmail.com>
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
        (cherry picked from commit 90368875)
      
        Conflicts:
        	src/mesa/drivers/dri/i965/gen6_blorp.cpp
      f7848574
  3. Jan 28, 2014
  4. Jan 26, 2014
  5. Jan 09, 2014
Loading