1. 25 Jul, 2013 6 commits
    • Paul Berry's avatar
      glsl: Handle empty if statement encountered during loop analysis. · a5eecb24
      Paul Berry authored
      The is_loop_terminator() function was asserting that the following
      kind of if statement could never occur:
      
          if (...) { } else { }
      
      (presumably based on the assumption that such an if statement would be
      eliminated by previous optimization stages).  But that isn't the
      case--it's possible that previous optimization stages might simplify
      more complex code down to this empty if statement, in which case it
      won't be eliminated until the next time through the optimization loop.
      
      So is_loop_terminator() needs to handle it.  Fortunately it's easy to
      handle--it's not a loop terminator because it does nothing.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64330
      
      
      CC: mesa-stable@lists.freedesktop.org
      Reviewed-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      a5eecb24
    • Paul Berry's avatar
      i965: Initialize inout_offset parameter to brw_search_cache(). · b8f13fbb
      Paul Berry authored
      Two callers of brw_search_cache() weren't initializing that function's
      inout_offset parameter: brw_blorp_const_color_params::get_wm_prog()
      and brw_blorp_const_color_params::get_wm_prog().
      
      That's a benign problem, since the only effect of not initializing
      inout_offset prior to calling brw_search_cache() is that the bit
      corresponding to cache_id in brw->state.dirty.cache may not be set
      reliably.  This is ok, since the cache_id's used by
      brw_blorp_const_color_params::get_wm_prog() and
      brw_blorp_blit_params::get_wm_prog() (BRW_BLORP_CONST_COLOR_PROG and
      BRW_BLORP_BLIT_PROG, respectively) correspond to dirty bits that are
      not used.
      
      However, failing to initialize this parameter causes valgrind to
      complain.  So let's go ahead and fix it to reduce valgrind noise.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66779
      
      Reviewed-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      b8f13fbb
    • Paul Berry's avatar
      glsl: don't rename variables in interface block arrays. · 42a921fa
      Paul Berry authored
      The linker matches up variables in interface blocks according to their
      block name and variable name.  When support for interface block arrays
      was added in commit d6863acb
      
      , we renamed variables appearing in
      interface blocks so that their name included the array size.  For
      example, in a block like this:
      
      out foo {
         float bar
      } baz[3];
      
      The variable "bar" would get renamed to "bar[3]".
      
      This is unnecessary, and leads to problems in supporting geometry
      shaders, since geometry shaders require vertex shader outputs which
      are non-arrays to be linked up to geometry shader inputs which are
      arrays.
      
      This patch makes the behaviour of interface block arrays the same as
      simple non-array interface blocks; in both cases, the variables
      contained within them are not renamed.
      Reviewed-by: default avatarMatt Turner <mattst88@gmail.com>
      42a921fa
    • Zack Rusin's avatar
      draw: fix vertex id computation · f19cb0e5
      Zack Rusin authored
      
      
      vertex id has to be unaffected by the start index (i.e. when calling
      draw arrays with start_index = 5, the first vertex_id has to still
      be 0, not 5) and it has to be equal to the index when performing
      indexed rendering (in which case it has to be unaffected by the
      index bias). This fixes our behavior.
      Signed-off-by: default avatarZack Rusin <zackr@vmware.com>
      Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Reviewed-by: default avatarJose Fonseca <jfonseca@vmware.com>
      f19cb0e5
    • Zack Rusin's avatar
      draw: cleanup and fix instance id computation · 0e9ec869
      Zack Rusin authored
      
      
      The instance id system value always starts at 0, even if the
      specified start instance is larger than 0. Instead of implicitly
      setting instance id to instance id plus start instance and then
      having to subtract instance id when computing the buffer offsets
      lets just set instance id to the proper instance id. This fixes
      instance id computation and cleansup buffer offset computation.
      Signed-off-by: default avatarZack Rusin <zackr@vmware.com>
      Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Reviewed-by: default avatarJose Fonseca <jfonseca@vmware.com>
      0e9ec869
    • Vinson Lee's avatar
      gallivm: Remove dead code in lp_build_compare_ext. · 0ac31647
      Vinson Lee authored
      
      
      There are earlier returns for PIPE_FUNC_NEVER and PIPE_FUNC_ALWAYS. The
      switch value of 'func' cannot be either of those values.
      
      Fixes "Logically dead code" defects reported by Coverity.
      Signed-off-by: default avatarVinson Lee <vlee@freedesktop.org>
      Reviewed-by: default avatarJosé Fonseca <jfonseca@vmware.com>
      0ac31647
  2. 24 Jul, 2013 6 commits
  3. 23 Jul, 2013 2 commits
  4. 22 Jul, 2013 13 commits
  5. 21 Jul, 2013 2 commits
  6. 20 Jul, 2013 1 commit
  7. 19 Jul, 2013 10 commits