Skip to content
Snippets Groups Projects
  1. Feb 13, 2020
  2. Feb 11, 2020
  3. Feb 10, 2020
  4. Feb 07, 2020
  5. Feb 06, 2020
    • Pierre-Eric Pelloux-Prayer's avatar
      radeonsi: stop using the VM_ALWAYS_VALID flag · 88aa4b77
      Pierre-Eric Pelloux-Prayer authored
      Allocation all the bo as ALWAYS_VALID means they must all fit in memory
      (vram + gtt) at each command submission.
      This causes some trouble when the total allocated memory is greater than
      the available memory.
      
      Possible solutions:
      - being able to tag/untag a bo as ALWAYS_VALID: would require kernel changes
      - disable VM_ALWAYS_VALID when memory usage is more than a percentage of the
        available memory
      - disable VM_ALWAYS_VALID entirely
      
      v1 of this patch implemented option 2. v2 (this version) implements option 3.
      
      Related issues:
       - drm/amd#607
       - mesa/mesa#1257
      
      It also helps with some piglit tests (-t maxsize -t "max[_-].*size" -t maxuniformblocksize):
      instead of crashing the machine, the tests fail cleanly.
      
      (cherry-pick from ab54624d)
      
      Tested-by: Marge Bot <mesa/mesa!3709>
      Part-of: <mesa/mesa!3709>
      88aa4b77
  6. Feb 05, 2020
    • Tapani Pälli's avatar
      mesa: allow bit queries for EXT_disjoint_timer_query · 03b457e0
      Tapani Pälli authored
      Closes: mesa/mesa#2090
      
      
      Signed-off-by: default avatarTapani Pälli <tapani.palli@intel.com>
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      Tested-by: Marge Bot <mesa/mesa!3707>
      Part-of: <mesa/mesa!3707>
      03b457e0
    • Tapani Pälli's avatar
      mapi: add GetInteger64vEXT with EXT_disjoint_timer_query · a3e4b96e
      Tapani Pälli authored
      From EXT_disjoint_timer_query spec:
      
         "Interaction: This extension adds GetInteger64vEXT if
          OpenGL ES 3.0 is not supported"
      
      See https://github.com/KhronosGroup/OpenGL-Registry/issues/326.
      
      Closes: mesa/mesa#2090
      
      
      Signed-off-by: default avatarTapani Pälli <tapani.palli@intel.com>
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      Part-of: <mesa/mesa!3707>
      a3e4b96e
    • Ian Romanick's avatar
      intel/fs: Don't count integer instructions as being possibly coissue · 6cd88f51
      Ian Romanick authored and Dylan Baker's avatar Dylan Baker committed
      
      Integer instructions don't coissue.  Before e64be391
      ("intel/compiler: generalize the combine constants pass"), this pass
      only looked at float sources.  There's no shader-db data in that commit,
      so I collected some.  The results are not good:
      
          Haswell
          total instructions in shared programs: 11898805 -> 11908127 (0.08%)
          instructions in affected programs: 1218680 -> 1228002 (0.76%)
          helped: 2
          HURT: 5171
          helped stats (abs) min: 12 max: 111 x̄: 61.50 x̃: 61
          helped stats (rel) min: 1.59% max: 9.20% x̄: 5.40% x̃: 5.40%
          HURT stats (abs)   min: 1 max: 311 x̄: 1.83 x̃: 1
          HURT stats (rel)   min: 0.02% max: 9.91% x̄: 1.05% x̃: 0.70%
          95% mean confidence interval for instructions value: 1.55 2.05
          95% mean confidence interval for instructions %-change: 1.02% 1.08%
          Instructions are HURT.
      
          total cycles in shared programs: 221664974 -> 221404750 (-0.12%)
          cycles in affected programs: 120012620 -> 119752396 (-0.22%)
          helped: 3464
          HURT: 3159
          helped stats (abs) min: 1 max: 428160 x̄: 314.55 x̃: 16
          helped stats (rel) min: <.01% max: 57.33% x̄: 3.40% x̃: 1.28%
          HURT stats (abs)   min: 1 max: 87846 x̄: 262.54 x̃: 14
          HURT stats (rel)   min: <.01% max: 85.57% x̄: 3.01% x̃: 0.77%
          95% mean confidence interval for cycles value: -224.23 145.65
          95% mean confidence interval for cycles %-change: -0.50% -0.19%
          Inconclusive result (value mean confidence interval includes 0).
      
          total spills in shared programs: 9804 -> 10047 (2.48%)
          spills in affected programs: 6869 -> 7112 (3.54%)
          helped: 2
          HURT: 41
      
          total fills in shared programs: 19863 -> 20319 (2.30%)
          fills in affected programs: 17428 -> 17884 (2.62%)
          helped: 2
          HURT: 41
      
          LOST:   20
          GAINED: 13
      
      This also prevents regressions in "intel/fs: Promote integer constants
      after lowering integer multiplication" (note: that patch will probably
      not be committed).  When the passes are reorderd, code like
      
          mul(8)      acc0<1>D    g9<8,8,1>D  -2078209981D    { align1 1Q };
      
      gets turned into
      
          mov(1)      g23<1>D     2078209981D                 { align1 WE_all 1N };
          ...
          mul(8)      acc0<1>D    g13<8,8,1>D  -g23<0,1,0>D   { align1 1Q compacted };
      
      It's not 100% clear why, but these produce different results.  Note that
      -2078209981 & 0x0ffff = 0x0843, and -(2078209981 & 0x0ffff) =
      0xffff0843.  It seems like the upper 16-bits of the negation should be
      ignored.
      
      Fixes: e64be391 ("intel/compiler: generalize the combine constants pass")
      Cc: Iago Toral Quiroga <itoral@igalia.com>
      Suggested-by: default avatarMatt Turner <mattst88@gmail.com>
      Reviewed-by: default avatarMatt Turner <mattst88@gmail.com>
      
      The shaders with spills or fills hurt are the usual suspects.  A couple
      compute shaders in Dirt Showdown and a compute shader in Bioshock
      Infinite.  On Haswell, a compute shader (that appears twice in
      shader-db) from Aztec Ruins was also hurt for spill and fills.
      
      Haswell
      total instructions in shared programs: 11573934 -> 11568335 (-0.05%)
      instructions in affected programs: 828623 -> 823024 (-0.68%)
      helped: 2825
      HURT: 6
      helped stats (abs) min: 1 max: 134 x̄: 2.16 x̃: 1
      helped stats (rel) min: 0.02% max: 9.05% x̄: 0.84% x̃: 0.61%
      HURT stats (abs)   min: 1 max: 216 x̄: 81.83 x̃: 56
      HURT stats (rel)   min: 0.16% max: 8.65% x̄: 4.21% x̃: 4.68%
      95% mean confidence interval for instructions value: -2.31 -1.64
      95% mean confidence interval for instructions %-change: -0.85% -0.80%
      Instructions are helped.
      
      total cycles in shared programs: 187573593 -> 187004633 (-0.30%)
      cycles in affected programs: 82816107 -> 82247147 (-0.69%)
      helped: 2186
      HURT: 1741
      helped stats (abs) min: 1 max: 35230 x̄: 326.96 x̃: 16
      helped stats (rel) min: <.01% max: 46.11% x̄: 3.11% x̃: 0.90%
      HURT stats (abs)   min: 1 max: 6138 x̄: 83.73 x̃: 16
      HURT stats (rel)   min: <.01% max: 104.11% x̄: 2.73% x̃: 0.75%
      95% mean confidence interval for cycles value: -197.13 -92.64
      95% mean confidence interval for cycles %-change: -0.72% -0.33%
      Cycles are helped.
      
      total spills in shared programs: 7870 -> 7743 (-1.61%)
      spills in affected programs: 2260 -> 2133 (-5.62%)
      helped: 31
      HURT: 5
      
      total fills in shared programs: 6320 -> 6263 (-0.90%)
      fills in affected programs: 3547 -> 3490 (-1.61%)
      helped: 31
      HURT: 6
      
      LOST:   9
      GAINED: 9
      
      Ivybridge
      total instructions in shared programs: 11863372 -> 11859793 (-0.03%)
      instructions in affected programs: 757183 -> 753604 (-0.47%)
      helped: 2236
      HURT: 3
      helped stats (abs) min: 1 max: 81 x̄: 1.86 x̃: 1
      helped stats (rel) min: 0.03% max: 5.26% x̄: 0.74% x̃: 0.48%
      HURT stats (abs)   min: 11 max: 301 x̄: 192.33 x̃: 265
      HURT stats (rel)   min: 1.55% max: 10.51% x̄: 6.89% x̃: 8.62%
      95% mean confidence interval for instructions value: -2.01 -1.18
      95% mean confidence interval for instructions %-change: -0.77% -0.70%
      Instructions are helped.
      
      total cycles in shared programs: 178377378 -> 177946087 (-0.24%)
      cycles in affected programs: 76261390 -> 75830099 (-0.57%)
      helped: 1635
      HURT: 1395
      helped stats (abs) min: 1 max: 34796 x̄: 333.53 x̃: 16
      helped stats (rel) min: <.01% max: 47.15% x̄: 2.82% x̃: 0.64%
      HURT stats (abs)   min: 1 max: 4315 x̄: 81.74 x̃: 18
      HURT stats (rel)   min: <.01% max: 49.98% x̄: 1.99% x̃: 0.53%
      95% mean confidence interval for cycles value: -197.06 -87.62
      95% mean confidence interval for cycles %-change: -0.78% -0.43%
      Cycles are helped.
      
      total spills in shared programs: 4188 -> 4182 (-0.14%)
      spills in affected programs: 1557 -> 1551 (-0.39%)
      helped: 30
      HURT: 3
      
      total fills in shared programs: 5056 -> 5245 (3.74%)
      fills in affected programs: 2708 -> 2897 (6.98%)
      helped: 30
      HURT: 3
      
      LOST:   5
      GAINED: 1
      
      No shader-db changes on any other Intel platform.
      
      Tested-by: Marge Bot <mesa/mesa!3544>
      Part-of: <mesa/mesa!3544>
      (cherry picked from commit 59488cbb)
      6cd88f51
    • Bas Nieuwenhuizen's avatar
      radv: Do not set SX DISABLE bits for RB+ with unused surfaces. · 5e7ee640
      Bas Nieuwenhuizen authored and Dylan Baker's avatar Dylan Baker committed
      
      The extra bits in CB_SHADER_MASK break dual source blending in
      SkQP on a Stoney device. However:
      
      - As far as I can tell, some other dual source blend tests are passing
        before and after the change.
      - A hacked around skqp passes on my Vega desktop and Raven laptop
      - Getting Skqp to give any useful info or to run it outside of Android
        on ChromeOS is proving difficult.
      
      I have confirmed 3 strategies that seem to work:
      - The old radv behavior of setting CB_SHADER_MASK to 0xF
      - AMDVLK: CB_SHADER_MASK = 0xFF, and the 3 RB+ regs
        are 0.
      - radeonsi: CB_SHADER_MASK = 0xFF, but does not set DISABLE
        bits in SX_BLEND_OPT_CONTROL for CB 1-7.
      
      Let us use the radeonsi solution as that solution also seems like the correct
      thing to do for holes. I have tested on my Raven laptop that setting the high
      surfaces to not disabled and downconvert to 32_R does not imply a performance
      penalty.
      
      Fixes: e9316fdf "radv: fix setting CB_SHADER_MASK for dual source blending"
      Reviewed-by: default avatarSamuel Pitoiset <samuel.pitoiset@gmail.com>
      Tested-by: Marge Bot <mesa/mesa!3670>
      Part-of: <mesa/mesa!3670>
      (cherry picked from commit 65a6dc51)
      5e7ee640
    • Danylo Piliaiev's avatar
      st/mesa: Handle the rest renderbuffer formats from OSMesa · 6dd380da
      Danylo Piliaiev authored
      Closes: mesa/mesa#2189
      Closes: mesa/mesa#989
      Closes: mesa/mesa#2036
      
      
      CC: <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarDanylo Piliaiev <danylo.piliaiev@globallogic.com>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Part-of: <mesa/mesa!3216>
      (cherry picked from commit d83abf1d)
      6dd380da
    • Danylo Piliaiev's avatar
      i965: Do not set front_buffer_dirty if there is no front buffer · e1579d96
      Danylo Piliaiev authored
      Otherwise there will be a warning:
       "libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering."
      
      Happens with EGL_KHR_surfaceless_context:
      
       eglMakeCurrent(egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE, egl_context)
       eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context)
       glFlush() // Here will be a warning
      
      Cc: <mesa-stable@lists.freedesktop.org>
      Closes: mesa/mesa#1525
      
      
      Signed-off-by: default avatarDanylo Piliaiev <danylo.piliaiev@globallogic.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Tested-by: Marge Bot <mesa/mesa!3628>
      Part-of: <mesa/mesa!3628>
      (cherry picked from commit 36126b62)
      e1579d96
    • Dylan Baker's avatar
      88865d41
    • Dylan Baker's avatar
      .pick_status.json: Update to 7eaf21cb · 7f2c7e09
      Dylan Baker authored
      7f2c7e09
  7. Feb 04, 2020
  8. Feb 03, 2020
Loading