1. 28 Oct, 2019 10 commits
  2. 17 Oct, 2019 1 commit
  3. 28 Aug, 2019 1 commit
  4. 31 Jul, 2019 1 commit
  5. 27 Jun, 2019 1 commit
    • Nanley Chery's avatar
      isl: Don't align phys_level0_sa by block dimension · 02f6995d
      Nanley Chery authored
      
      
      Aligning phys_level0_sa by the compression block dimension prior to
      mipmap layout causes the layout of compressed surfaces to differ from
      the sampler's expectations in certain cases. The hardware docs agree:
      
      From the BDW PRM, Vol. 5, Compressed Mipmap Layout,
      
         The compressed mipmaps are stored in a similar fashion to
         uncompressed mipmaps [...]
      
         The following exceptions apply to the layout of compressed (vs.
         uncompressed) mipmaps:
            * [...]
            * The dimensions of the mip maps are first determined by applying
      	the sizing algorithm presented in Non-Power-of-Two Mipmaps
      	above. Then, if necessary, they are padded out to compression
      	block boundaries.
      
      The last bullet indicates that alignment should not be done for
      calculating a miplevel's dimensions, but rather for determining miplevel
      placement/padding. Comply with this text by removing the extra
      alignment.
      
      Fixes some fbo-generatemipmap-formats piglit failures on all tested
      platforms (SNB-KBL).
      
      v2:
      - Note fixed platforms.
      - Update some consumers via a helper function.
      
      Cc: <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      02f6995d
  6. 20 Jun, 2019 1 commit
    • Eric Engestrom's avatar
      isl: tag unreachable path as such · a9e09d56
      Eric Engestrom authored and Eric Engestrom's avatar Eric Engestrom committed
      
      
      GCC should be able to figure out that all the possible enum values are
      exhausted in the switch() and all the branches return from the function,
      but apparently it doesn't, so let's tell the compiler explicitly.
      
      This gets rid of the following warnings in GCC 9:
      
          [1/24] Compiling C object 'src/intel/isl/60d23f8@@isl@sta/isl.c.o'.
          ../src/intel/isl/isl.c: In function ‘isl_surf_init_s’:
          ../src/intel/isl/isl.c:1569:10: warning: ‘array_pitch_el_rows’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           1569 |    *surf = (struct isl_surf) {
                |    ~~~~~~^~~~~~~~~~~~~~~~~~~~~
           1570 |       .dim = info->dim,
                |       ~~~~~~~~~~~~~~~~~
           1571 |       .dim_layout = dim_layout,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~
           1572 |       .msaa_layout = msaa_layout,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1573 |       .tiling = tiling,
                |       ~~~~~~~~~~~~~~~~~
           1574 |       .format = info->format,
                |       ~~~~~~~~~~~~~~~~~~~~~~~
           1575 |
                |
           1576 |       .levels = info->levels,
                |       ~~~~~~~~~~~~~~~~~~~~~~~
           1577 |       .samples = info->samples,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~
           1578 |
                |
           1579 |       .image_alignment_el = image_align_el,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1580 |       .logical_level0_px = logical_level0_px,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1581 |       .phys_level0_sa = phys_level0_sa,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1582 |
                |
           1583 |       .size_B = size_B,
                |       ~~~~~~~~~~~~~~~~~
           1584 |       .alignment_B = base_alignment_B,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1585 |       .row_pitch_B = row_pitch_B,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1586 |       .array_pitch_el_rows = array_pitch_el_rows,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1587 |       .array_pitch_span = array_pitch_span,
                |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           1588 |
                |
           1589 |       .usage = info->usage,
                |       ~~~~~~~~~~~~~~~~~~~~~
           1590 |    };
                |    ~
          ../src/intel/isl/isl.c:1488:24: warning: ‘*((void *)&phys_total_el+4)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           1488 |    struct isl_extent2d phys_total_el;
                |                        ^~~~~~~~~~~~~
          ../src/intel/isl/isl.c:1335:38: warning: ‘phys_total_el’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           1335 |       isl_align_div(phys_total_el->w * tile_el_scale,
                |                     ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
          ../src/intel/isl/isl.c:1488:24: note: ‘phys_total_el’ was declared here
           1488 |    struct isl_extent2d phys_total_el;
                |                        ^~~~~~~~~~~~~
      Signed-off-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      a9e09d56
  7. 14 May, 2019 3 commits
  8. 24 Apr, 2019 1 commit
  9. 22 Feb, 2019 1 commit
  10. 20 Feb, 2019 1 commit
  11. 05 Feb, 2019 1 commit
  12. 10 Jan, 2019 1 commit
  13. 26 Sep, 2018 1 commit
  14. 18 May, 2018 1 commit
  15. 09 May, 2018 3 commits
  16. 05 Apr, 2018 1 commit
    • Rafael Antognolli's avatar
      intel: Use Clear Color struct size. · 94675edc
      Rafael Antognolli authored
      
      
      The size of the clear color struct (expected by the hardware) is 8
      dwords (isl_dev.ss.clear_value_state_size here). But we still need to
      track the size of the clear color, used when memcopying it to/from the
      state buffer. For that we keep isl_dev.ss.clear_value_size.
      
      v4:
       - Add struct to gen11 too (Jason, Jordan)
       - Add field for Converted Clear Color to gen11 (Jason)
       - Add clear_color_state_offset to differentiate from
         clear_value_offset.
       - Fix all the places where clear_value_size was used.
      
      v5 (Jason):
       - Split genxml changes to another commit.
       - Remove unnecessary gen checks.
       - Bring back missing offset increment to init_fast_clear_color().
      
      v6 (Jason):
       - On init_fast_clear_color, change:
         addr.offset += 4 => sdi.Address.offset += i * 4
       - Use GEN_GEN instead of GEN_VERSIONx10.
      
      [jordan.l.justen@intel.com: isl_device_init changes]
      Signed-off-by: Rafael Antognolli's avatarRafael Antognolli <rafael.antognolli@intel.com>
      Signed-off-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      94675edc
  17. 20 Feb, 2018 1 commit
  18. 16 Feb, 2018 2 commits
  19. 19 Aug, 2017 1 commit
  20. 18 Aug, 2017 1 commit
  21. 10 Aug, 2017 1 commit
    • Kenneth Graunke's avatar
      isl: Validate row pitch of stencil surfaces. · 5563872d
      Kenneth Graunke authored
      
      
      Also, silence an obnoxious finishme that started occurring for all
      GL applications which use stencil after the i965 ISL conversion.
      
      v2: Check against 3DSTATE_STENCIL_BUFFER's pitch bits when using
          separate stencil, and 3DSTATE_DEPTH_BUFFER's bits when using
          combined depth-stencil.
      
      Cc: "17.2" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      5563872d
  22. 07 Aug, 2017 2 commits
    • Jason Ekstrand's avatar
      intel/isl: Don't align the height of the last array slice · 4d27c609
      Jason Ekstrand authored
      
      
      We were calculating the total height of 2D surfaces by multiplying the
      row pitch by the number of slices.  This means that we actually request
      slightly more space than actually needed since the padding on the last
      slice is unnecessary.  For tiled surfaces this is not likely to make a
      difference.  For linear surfaces, on the other hand, this means we may
      require additional memory.  In particular, this makes the i965 driver
      reject EGL imports of buffers which do not have this extra padding.
      Reviewed-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      Cc: "17.2" <mesa-stable@lists.freedesktop.org>
      4d27c609
    • Jason Ekstrand's avatar
      intel/isl: Stop padding surfaces · c15b92ce
      Jason Ekstrand authored
      
      
      The docs contain a bunch of commentary about the need to pad various
      surfaces out to multiples of something or other.  However, all of those
      requirements are about avoiding GTT errors due to missing pages when the
      data port or sampler accesses slightly out-of-bounds.  However, because
      the kernel already fills all the empty space in our GTT with the scratch
      page, we never have to worry about faulting due to OOB reads.  There are
      two caveats to this:
      
       1) There is some potential for issues with caches here if extra data
          ends up in a cache we don't expect due to OOB reads.  However,
          because we always trash the entire cache whenever we need to move
          anything between cache domains, this shouldn't be an issue.
      
       2) There is a potential issue if a surface gets placed at the very top
          of the GTT by the kernel.  In this case, the hardware could
          potentially end up trying to read past the top of the GTT.  If it
          nicely wraps around at the 48-bit (or 32-bit) boundary, then this
          shouldn't be an issue thanks to the scratch page.  If it doesn't,
          then we need to come up with something to handle it.
      
      Up until some of the GL move to ISL, having the padding code in there
      just caused us to harmlessly use a bit more memory in Vulkan.  However,
      now that we're using ISL sizes to validate external dma-buf images,
      these padding requirements are causing us to reject otherwise valid
      images due to the size of the BO being too small.
      Acked-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Tested-by: Tapani Pälli's avatarTapani Pälli <tapani.palli@intel.com>
      Tested-by: Tomasz Figa's avatarTomasz Figa <tfiga@chromium.org>
      Reviewed-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      Cc: "17.2" <mesa-stable@lists.freedesktop.org>
      c15b92ce
  23. 23 Jul, 2017 3 commits