1. 16 Sep, 2020 1 commit
  2. 10 Jun, 2020 1 commit
  3. 05 May, 2020 1 commit
  4. 29 Apr, 2020 1 commit
  5. 15 Apr, 2020 1 commit
  6. 11 Apr, 2020 2 commits
  7. 19 Mar, 2020 1 commit
    • Jason Ekstrand's avatar
      intel/iris: Always initialize CCS to 0 · 9dbff6f6
      Jason Ekstrand authored
      
      
      Previously, we were initializing the CCS to 0xFF for MCS+CCS due to a
      misunderstanding of the following lines in the bspec:
      
          The following are the general SW requirements for MCS buffer clear
          functionality:
              ...
               - If Software wants to enable Color Compression without Fast
                 clear, Software needs to initialize MCS with zeros.
               - Lossless compression and CCS initialized to all F (using HW
                 Fast Clear or SW direct Clear) on the same surface is not
                 supported.
      
      The first line does not refer to the CCS as the comment author supposed
      but refers to the MCS as the comment says.  It means that if you want to
      use MCS compression without a fast-clear, you should initialize the MCS
      to 0x00.  This is because the value 0x00 in the MCS means "all data is
      in plane 0" which is a perfectly valid non-fast-clear initialization.
      It's also the value the MCS should be in if you do a RECTLIST slow-clear
      where the primitive fully covers each pixel such that the same value is
      written to all samples.
      
      The second line in the above quote seems to imply that CCS fast-clear is
      incompatible with MCS fast-clear.  In particular, MCS+CCS fast-clear
      uses a 0xff value in the MCS (like on Gen7-11) and leaves the CCS in
      either the compressed or the pass-through state.  Therefore, we should
      initialize the CCS to 0x00 even for MCS+CCS surfaces.
      
      Reviewed-by: Sagar Ghuge<sagar.ghuge@intel.com>
      Reviewed-by: Nanley Chery's avatarNanley Chery <nanley.g.chery@intel.com>
      Tested-by: Marge Bot <!4074>
      Part-of: <!4074>
      9dbff6f6
  8. 16 Mar, 2020 1 commit
  9. 12 Mar, 2020 2 commits
  10. 06 Feb, 2020 1 commit
  11. 28 Jan, 2020 1 commit
  12. 23 Dec, 2019 1 commit
  13. 12 Dec, 2019 1 commit
    • Kenneth Graunke's avatar
      iris: Default to X-tiling for scanout buffers without modifiers · dcb4230e
      Kenneth Graunke authored
      Neither Mutter nor KWin's wayland compositors appear to use modifiers.
      In the non-modifier case, iris was still trying to use Y-tiling for
      scan-out surfaces, leading to this error:
      
      (gnome-shell:7247): mutter-WARNING **: 09:23:47.787: meta_drm_buffer_gbm_new failed: drmModeAddFB failed: Invalid argument
      
      We now fall back to the historical X-tiling for scanout buffers, which
      ought to work everyone, at lower performance.  To regain that, we need
      to ensure modifiers are actually supported in environments people use.
      
      Fixes: fbf31247
      
       ("iris: Rework tiling/modifiers handling")
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      dcb4230e
  14. 06 Dec, 2019 1 commit
  15. 25 Nov, 2019 1 commit
  16. 14 Nov, 2019 1 commit
  17. 04 Nov, 2019 1 commit
    • James Xiong's avatar
      iris: try to set the specified tiling when importing a dmabuf · b6d45e7f
      James Xiong authored and Rafael Antognolli's avatar Rafael Antognolli committed
      
      
      When importing a dmabuf with a specified tiling, the dmabuf user
      should always try to set the tiling mode because: 1) the exporter
      can set tiling AFTER exporting/importing. 2) a dmabuf could be
      exported from a kernel driver other than i915, in this case the
      dmabuf user and exporter need to set tiling separately.
      
      This patch fixes a problem when running vkmark under weston with
      iris on ICL, it crashed to console with the following assert. i965
      doesn't have this problem as it always tries to set the specified
      tiling mode.
      
      weston: ../src/gallium/drivers/iris/iris_resource.c:990: iris_resource_from_handle: Assertion `res->bo->tiling_mode == isl_tiling_to_i915_tiling(res->surf.tiling)' failed.
      Signed-off-by: James Xiong's avatarJames Xiong <james.xiong@intel.com>
      Reviewed-by: Rafael Antognolli's avatarRafael Antognolli <rafael.antognolli@intel.com>
      b6d45e7f
  18. 30 Oct, 2019 1 commit
    • Rafael Antognolli's avatar
      iris: Align fast clear color state buffer to a page. · ffb46b2b
      Rafael Antognolli authored
      
      
      On gen11 and older, compressed images are tiled and aligned to 4K. On
      gen12 this 4K alignment restriction was removed. However, only aligning
      the fast clear color buffer to 64B (a cacheline, as it's on the
      documentation) is causing some bugs where the fast clear color is not
      converted during the fast clear operation. Aligning things to 4K seems
      to fix it.
      
      v2: Fix typo case in the comment (Nanley)
      v3: Rebase and fix conflicts.
      v4: Fix rebase mistake (Nanley).
      Reviewed-by: Nanley Chery's avatarNanley Chery <nanley.g.chery@intel.com>
      ffb46b2b
  19. 29 Oct, 2019 4 commits
  20. 28 Oct, 2019 15 commits
  21. 18 Oct, 2019 1 commit