Skip to content
Snippets Groups Projects
  1. Apr 18, 2014
  2. Apr 16, 2014
    • Emma Anholt's avatar
      i965: Fix buffer overruns in MSAA MCS buffer clearing. · 5e718c11
      Emma Anholt authored and Carl Worth's avatar Carl Worth committed
      This manifested as rendering failures or sometimes GPU hangs in
      compositors when they accidentally got MSAA visuals due to a bug in the X
      Server.  Today we decided that the problem in compositors was equivalent
      to a corruption bug we'd noticed recently in resizing MSAA-visual
      glxgears, and debugging got a lot easier.
      
      When we allocate our MCS MT, libdrm takes the size we request, aligns it
      to Y tile size (blowing it up from 300x300=900000 bytes to 384*320=122880
      bytes, 30 pages), then puts it into a power-of-two-sized BO (131072 bytes,
      32 pages).  Because it's Y tiled, we attach a 384-byte-stride fence to it.
      When we memset by the BO size in Mesa, between bytes 122880 and 131072 the
      data gets stored to the first 20 or so scanlines of each of the 3 tiled
      pages in that row, even though only 2 of those pages were allocated by
      libdrm.  In the glxgears case, the missing 3rd page happened to
      consistently be the static VBO that got mapped right after the first MCS
      allocation, so corruption only appeared once window resize made us throw
      out the old MCS and then allocate the same BO to back the new MCS.
      
      Instead, just memset the amount of data we actually asked libdrm to
      allocate for, which will be smaller (more efficient) and not overrun.
      Thanks go to Kenneth for doing most of the hard debugging to eliminate a
      lot of the search space for the bug.
      
      Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77207
      
      
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit 7ae87021)
      5e718c11
    • Paul Berry's avatar
      i965/gen7: Prefer vertical alignment of 4 when possible. · b2f14a62
      Paul Berry authored and Carl Worth's avatar Carl Worth committed
      
      Gen6+ allows for color buffers to use a vertical alignment of either 4
      or 2.  Previously we defaulted to 2.  This may have caused problems on
      Gen7 because Y-tiled render targets are not allowed to use a vertical
      alignment of 2.
      
      This patch changes the vertical alignment to 4 on Gen7, except for the
      few formats where a vertical alignment of 2 is required.
      
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit 6b40dd17)
      b2f14a62
  3. Apr 14, 2014
  4. Mar 12, 2014
  5. Mar 11, 2014
Loading