Skip to content
Snippets Groups Projects
  1. Mar 09, 2020
  2. Mar 07, 2020
  3. Mar 06, 2020
  4. Feb 25, 2020
    • José María Casanova Crespo's avatar
      v3d: Sync on last CS when non-compute stage uses resource written by CS · e1dc5cc7
      José María Casanova Crespo authored and Dylan Baker's avatar Dylan Baker committed
      
      When a resource is written by a compute shader and then used by a
      non-compute stage we sync on last compute job to guarantee that the
      resource has been completely written when the next stage reads resources.
      
      In the other cases how flushes are done guarantee the serialization of
      the writes and reads.
      
      To reproduce the failure the following tests should be executed in batch
      as last test don't fail when run isolated:
      
      KHR-GLES31.core.shader_image_load_store.basic-allFormats-load-fs
      KHR-GLES31.core.shader_image_load_store.basic-allFormats-loadStoreComputeStage
      KHR-GLES31.core.shader_image_load_store.basic-allTargets-load-cs
      KHR-GLES31.core.shader_image_load_store.advanced-sync-vertexArray
      
      v2: Use fence dep instead of bo_wait (Eric Anholt)
      v3: Rename struct names (Iago Toral)
          Document why is not needed on graphics->compute case. (Iago Toral)
          Follow same code pattern of the other update of in_sync_bcl.
      v4: Fixed comments style. (Iago Toral)
      
      Fixes KHR-GLES31.core.shader_image_load_store.advanced-sync-vertexArray
      
      Reviewed-by: default avatarIago Toral Quiroga <itoral@igalia.com>
      CC: 19.3 20.0 <mesa-stable@lists.freedesktop.org>
      Tested-by: Marge Bot <mesa/mesa!2700>
      Part-of: <mesa/mesa!2700>
      (cherry picked from commit 01496e3d)
      e1dc5cc7
    • Dylan Baker's avatar
      .pick_status.json: Update to 01496e3d · 312a81ec
      Dylan Baker authored
      312a81ec
  5. Feb 24, 2020
  6. Feb 20, 2020
    • Danylo Piliaiev's avatar
      i965: Do not generate D16 B5G6R5_UNORM configs on gen < 8 · 3ee1f7ef
      Danylo Piliaiev authored
      We don't support MESA_FORMAT_Z_UNORM16 before Gen8, see
      intel_screen_init_surface_formats.
      
      As a consequence disables B5G6R5_UNORM configs with depth
      on gen < 6.
      
      Closes: mesa/mesa#2275
      
      
      CC: <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarDanylo Piliaiev <danylo.piliaiev@globallogic.com>
      Tested-by: Marge Bot <mesa/mesa!3206>
      Part-of: <mesa/mesa!3206>
      (cherry picked from commit 5bfd363b)
      3ee1f7ef
    • Ian Romanick's avatar
      intel/fs: Correctly handle multiply of fsign with a source modifier · ea1899f8
      Ian Romanick authored and Dylan Baker's avatar Dylan Baker committed
      
      The other source of the multiply will be interpreted as a uint32_t in an
      XOR instruction.  Any source modifiers with either not be interpreted at
      all or will be misinterpreted due to the differing types.
      
      If the other operand of the multiplication has a source modifier, just
      emit an extra move to resolve the source modifiers.
      
      The negation source modifier problem is difficult to reproduce due to an
      algebraic optimization that changes (-a*b) to -(a*b).  However, changes
      in MR !1359 push the negations back down.
      
      On Gen7+ it might be possible to do slightly better for an abs() source
      modifier by using BFI2 as a glorified copysign().
      
      On Gen8+ it might be possible to do slightly better for a neg() source
      modifier by emitting (~a ^ b).
      
      There were no shader-db changes on any Intel platform, so I think we can
      deal with that problem when it arises.
      
      See also piglit!224.
      
      Fixes: 06d2c116 ("intel/fs: Add a scale factor to emit_fsign")
      Reviewed-by: default avatarMatt Turner <mattst88@gmail.com>
      Tested-by: Marge Bot <mesa/mesa!3780>
      Part-of: <mesa/mesa!3780>
      (cherry picked from commit 273b8cd1)
      ea1899f8
Loading