1. 29 Sep, 2021 31 commits
  2. 28 Sep, 2021 1 commit
  3. 27 Sep, 2021 1 commit
  4. 24 Sep, 2021 4 commits
    • Ville Syrjälä's avatar
      drm/i915/fbc: Allow higher compression limits on FBC1 · 09bbdd87
      Ville Syrjälä authored
      On FBC1 we can specify an arbitrary cfb stride. The hw will
      simply throw away any compressed line that would exceed the
      specified limit and keep using the uncompressed data instead.
      Thus we can allow arbitrary compression limits.
      
      The one thing we have to keep in mind though is that the cfb
      stride is specified in units of 32B (gen2) or 64B (gen3+).
      Fortunately X-tile is already 128B (gen2) or 512B (gen3+) wide
      so as long as we limit outselves to the same 4x compression
      limit that FBC2 has we are guaranteed to have a sufficiently
      aligned cfb stride.
      Reviewed-by: default avatarJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210921152517.803-5-ville.syrjala@linux.intel.com
      09bbdd87
    • Ville Syrjälä's avatar
      drm/i915/fbc: Implement Wa_16011863758 for icl+ · 5f524aea
      Ville Syrjälä authored
      There's some kind of weird corner cases in FBC which requires
      FBC segments to be separated by at least one extra cacheline.
      Make sure that is present.
      
      v2: Respin to fit in with skl_fbc_min_cfb_stride()
      v3: Make it build
      
      Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210921181245.15091-1-ville.syrjala@linux.intel.com
      5f524aea
    • Ville Syrjälä's avatar
      drm/i915/fbc: Align FBC segments to 512B on glk+ · 2f051f67
      Ville Syrjälä authored
      Apply the same 512 byte FBC segment alignment to glk+ as we use
      on skl+. The only real difference is that we now have a dedicated
      register for the FBC override stride. Not 100% sure which
      platforms really need the 512B alignment, but it's easiest
      to just do it on everything.
      
      Also the hardware no longer seems to misclaculate the CFB stride
      for linear, so we can omit the use of the override stride for
      linear unless the stride is misaligned.
      Reviewed-by: default avatarJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210921152517.803-3-ville.syrjala@linux.intel.com
      2f051f67
    • Ville Syrjälä's avatar
      drm/i915/fbc: Rework cfb stride/size calculations · bdc1a2d2
      Ville Syrjälä authored
      The code to calculate the cfb stride/size is a bit of mess.
      The cfb size is getting calculated based purely on the plane
      stride and plane height. That doesn't account for extra
      alignment we want for the cfb stride. The gen9 override
      stride OTOH is just calculated based on the plane width, and
      it does try to make things more aligned but any extra alignment
      added there is not considered in the cfb size calculations.
      So not at all convinced this is working as intended. Additionally
      the compression limit handling is split between the cfb allocation
      code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just
      confusing.
      
      Let's streamline the whole thing:
      - Start with the plane stride, convert that into cfb stride (cfb is
        always 4 bytes per pixel). All the calculations will assume 1:1
        compression limit since that will give us the max values, and we
        don't yet know how much stolen memory we will be able to allocate
      - Align the cfb stride to 512 bytes on modern platforms. This guarantees
        the 4 line segment will be 512 byte aligned regardles of the final
        compression limit we choose later. The 512 byte alignment for the
        segment is required by at least some of the platforms, and just doing
        it always seems like the easiest option
      - Figure out if we need to use the override stride or not. For X-tiled
        it's never needed since the plane stride is already 512 byte aligned,
        for Y-tiled it will be needed if the plane stride is not a multiple
        of 512 bytes, and for linear it's apparently always needed because the
        hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of
        the PLANE_STRIDE*64 that it use with linear.
      - The cfb size will be calculated based on the aligned cfb stride to
        guarantee we actually reserved enough stolen memory and the FBC hw
        won't end up scribbling over whatever else is allocated in stolen
      - The compression limit handling we just do fully in the cfb allocation
        code to make things less confusing
      
      v2: Write the min cfb segment stride calculation in a more
          explicit way to make it clear what is going on
      v3: Remeber to update fbc->limit when changing to 16bpp
      
      Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v2
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210923042151.19052-1-ville.syrjala@linux.intel.com
      bdc1a2d2
  5. 23 Sep, 2021 3 commits