Skip to content
Snippets Groups Projects
  1. Dec 01, 2013
  2. Nov 28, 2013
  3. Nov 27, 2013
    • Francisco Jerez's avatar
      glsl: Initialize _mesa_glsl_parse_state::atomic_counter_offsets before using it. · 5ec641bb
      Francisco Jerez authored
      
      Cc: Ian Romanick <ian.d.romanick@intel.com>
      Cc: "10.0" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      (cherry picked from commit 6b2b4cc8)
      5ec641bb
    • Paul Berry's avatar
      glsl: Fix lowering of direct assignment in lower_clip_distance. · 444a621e
      Paul Berry authored
      
      In commit 065da165 (glsl: Convert lower_clip_distance_visitor to be an
      ir_rvalue_visitor), we failed to notice that since
      lower_clip_distance_visitor overrides visit_leave(ir_assignment *),
      ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called.
      As a result, clip distance dereferences appearing directly on the
      right hand side of an assignment (not in a subexpression) weren't
      getting properly lowered.  This caused an ir_dereference_variable node
      to be left in the IR that referred to the old gl_ClipDistance
      variable.  However, since the lowering pass replaces gl_ClipDistance
      with gl_ClipDistanceMESA, this turned into a dangling pointer when the
      IR got reparented.
      
      Prior to the introduction of geometry shaders, this bug was unlikely
      to arise, because (a) reading from gl_ClipDistance[i] in the fragment
      shader was rare, and (b) when it happened, it was likely that it would
      either appear in a subexpression, or be hoisted into a subexpression
      by tree grafting.
      
      However, in a geometry shader, we're likely to see a statement like
      this, which would trigger the bug:
      
          gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i];
      
      This patch causes
      lower_clip_distance_visitor::visit_leave(ir_assignment *) to call the
      base class visitor, so that the right hand side of the assignment is
      properly lowered.
      
      Fixes piglit test:
      - spec/glsl-1.50/execution/geometry/clip-distance-itemized-copy
      
      Cc: Ian Romanick <idr@freedesktop.org>
      Cc: "9.2" <mesa-stable@lists.freedesktop.org>
      Cc: "10.0" <mesa-stable@lists.freedesktop.org>
      
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      (cherry picked from commit 9dfcb05f)
      444a621e
    • Paul Berry's avatar
      i965/gs: Set GS prog_data to NULL if there is no GS program. · 756b4f9a
      Paul Berry authored
      
      The previous commit fixes a bug wherein we would incorrectly refer to
      stale geometry shader prog_data when no geometry shader was active.
      
      This patch reduces the likelihood of that sort of bug occurring in the
      future by setting prog_data to NULL whenever there is no GS program.
      
      Cc: mesa-stable@lists.freedesktop.org
      
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit 37bdde10)
      756b4f9a
    • Paul Berry's avatar
      i965/gs: Properly skip GS binding table upload when no GS active. · d963daa3
      Paul Berry authored
      Previously, in brw_gs_upload_binding_table(), we checked whether
      brw->gs.prog_data was NULL in order to determine whether a geometry
      shader was active.  This didn't work: brw->gs.prog_data starts off as
      NULL, but it is set to non-NULL when a geometry shader program is
      built, and then never set to NULL again.  As a result, if we called
      brw_gs_upload_binding_table() while there was no geometry shader
      active, but a geometry shader had previously been active, it would
      refer to a stale (and possibly freed) prog_data structure.
      
      This patch fixes the problem by modifying
      brw_gs_upload_binding_table() to use the proper technique to determine
      whether a geometry shader is active: by checking whether
      brw->geometry_program is NULL.
      
      This fixes the crash reported in comment 2 of bug 71870 (the incorrect
      rendering remains, however).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
      
      
      
      Cc: mesa-stable@lists.freedesktop.org
      
      Reviewed-by: default avatarChris Forbes <chrisf@ijw.co.nz>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit 2714ca81)
      d963daa3
  4. Nov 26, 2013
  5. Nov 24, 2013
  6. Nov 23, 2013
Loading