Skip to content
Snippets Groups Projects
  1. Jan 09, 2014
  2. Jan 03, 2014
    • Alexander von Gluck's avatar
      Haiku: Add in public GL kit headers · e833368e
      Alexander von Gluck authored and Carl Worth's avatar Carl Worth committed
      
      * These make up the base of what C++ GL Haiku applications
        use for 3D rendering.
      * Not placed in includes/GL to prevent Haiku headers from
        getting installed on non-Haiku systems.
      
      Acked-by: default avatarBrian Paul <brianp@vmware.com>
      (cherry picked from commit 56d920a5)
      e833368e
    • Ilia Mirkin's avatar
      nv50: fix a small leak on context destroy · 3efc2bbf
      Ilia Mirkin authored and Carl Worth's avatar Carl Worth committed
      
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      (cherry picked from commit f50a4545)
      3efc2bbf
    • Paul Berry's avatar
      glsl: Fix inconsistent assumptions about ir_loop::counter. · d46a5870
      Paul Berry authored and Carl Worth's avatar Carl Worth committed
      The compiler back-ends (i965's fs_visitor and brw_visitor,
      ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
      ir_loop::counter is non-null, it points to a fresh ir_variable that
      should be used as the loop counter (as opposed to an ir_variable that
      exists elsewhere in the instruction stream).
      
      However, previous to this patch:
      
      (1) loop_control_visitor did not create a new variable for
          ir_loop::counter; instead it re-used the existing ir_variable.
          This caused the loop counter to be double-incremented (once
          explicitly by the body of the loop, and once implicitly by
          ir_loop::increment).
      
      (2) ir_clone did not clone ir_loop::counter properly, resulting in the
          cloned ir_loop pointing to the source ir_loop's counter.
      
      (3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
          in the ir_variable being missed by reparenting.
      
      Additionally, most optimization passes (e.g. loop unrolling) assume
      that the variable mentioned by ir_loop::counter is not accessed in the
      body of the loop (an assumption which (1) violates).
      
      The combination of these factors caused a perfect storm in which the
      code worked properly nearly all of the time: for loops that got
      unrolled, (1) would introduce a double-increment, but loop unrolling
      would fail to notice it (since it assumes that ir_loop::counter is not
      accessed in the body of the loop), so it would unroll the loop the
      correct number of times.  For loops that didn't get unrolled, (1)
      would introduce a double-increment, but then later when the IR was
      cloned for linking, (2) would prevent the loop counter from being
      cloned properly, so it would look to further analysis stages like an
      independent variable (and hence the double-increment would stop
      occurring).  At the end of linking, (3) would prevent the loop counter
      from being reparented, so it would still belong to the shader object
      rather than the linked program object.  Provided that the client
      program didn't delete the shader object, the memory would never get
      reclaimed, and so the shader would function properly.
      
      However, for loops that didn't get unrolled, if the client program did
      delete the shader object, and the memory belonging to the loop counter
      got re-used, this could cause a use-after-free bug, leading to a
      crash.
      
      This patch fixes loop_control_visitor, ir_clone, and
      ir_hierarchical_visitor to treat ir_loop::counter the same way the
      back-ends treat it: as a freshly allocated ir_variable that needs to
      be visited and cloned independently of other ir_variables.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026
      
      
      
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit d6eb4321)
      d46a5870
    • Paul Berry's avatar
      glsl: Teach ir_variable_refcount about ir_loop::counter variables. · 8eee788b
      Paul Berry authored and Carl Worth's avatar Carl Worth committed
      
      If an ir_loop has a non-null "counter" field, the variable referred to
      by this field is implicitly read and written by the loop.  We need to
      account for this in ir_variable_refcount, otherwise there is a danger
      we will try to dead-code-eliminate the loop counter variable.
      
      Note: at the moment the dead code elimination bug doesn't occur due to
      a bug in ir_hierarchical_visitor: it doesn't visit the "counter"
      field, so dead code elimination doesn't treat it as a candidate for
      elimination.  But the patch to follow will fix that bug, so we need to
      fix ir_variable_refcount first in order to avoid breaking dead code
      elimination.
      
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit 9d2951ea)
      8eee788b
  3. Jan 02, 2014
  4. Dec 13, 2013
  5. Dec 12, 2013
  6. Dec 10, 2013
Loading