Skip to content
  1. Jun 26, 2025
  2. Jun 25, 2025
  3. Jun 24, 2025
  4. Jun 23, 2025
  5. Jun 20, 2025
  6. Jun 19, 2025
  7. Jun 16, 2025
  8. Jun 13, 2025
  9. Jun 12, 2025
  10. Jun 11, 2025
  11. Jun 10, 2025
  12. Jun 05, 2025
  13. Jun 04, 2025
  14. Jun 03, 2025
  15. Jun 02, 2025
  16. May 30, 2025
  17. May 28, 2025
  18. May 27, 2025
  19. May 26, 2025
  20. May 22, 2025
  21. May 13, 2025
  22. May 08, 2025
  23. May 02, 2025
    • Jakub Sujak's avatar
      Smarter memory protection with Buffer class · 73d1e85d
      Jakub Sujak authored
      
      
      Introduces a dedicated `Buffer` abstraction for managing blocks of memory. Buffer comes with protection mechanisms that can be enabled by setting the `KAI_TEST_BUFFER_POLICY` environment variable.
      
      Example usage:
      
      ```KAI_TEST_BUFFER_POLICY=PROTECT_OVERFLOW ./kleidiai_test```
      
      Available memory protection mechanisms:
      
      - `KAI_TEST_BUFFER_POLICY=PROTECT_UNDERFLOW`
      - `KAI_TEST_BUFFER_POLICY=PROTECT_OVERFLOW`
      
      If `KAI_TEST_BUFFER_POLICY` is not set or is not one of the above values, then no memory protection mechanisms are enabled and Buffer performs naive malloc() allocation of memory.
      
      When `KAI_TEST_BUFFER_POLICY` is set to one of the above values, the following protections are enabled:
      
      - `PROTECT_UNDERFLOW`: Memory equal to the size of the user buffer rounded to the nearest whole page plus adjacent guard pages is allocated, and the user buffer is aligned to the end of the head guard page thus detecting whenever a buffer underflow occurs.
      - `PROTECT_OVERFLOW`: Same as above, but now the edge of the user buffer is aligned to the start of the tail guard page thus detecting whenever a buffer overflow occurs.
      
      Buffer is only intended to opaquely allocate and manage memory. The underlying memory resource can be requested using the familiar `Buffer::data()` method and interacted with using `kai::test::read_array<T>()` and `kai::test::write_array<T>()` utilities.
      
      Signed-off-by: Jakub Sujak's avatarJakub Sujak <jakub.sujak@arm.com>
      
      Reviewed-by: Viet-Hoa Do's avatarViet-Hoa Do <viet-hoa.do@arm.com>
      Reviewed-by: Jakub Sujak's avatarJakub Sujak <jakub.sujak@arm.com>
      Reviewed-by: Emil Ohlsson's avatarEmil Ohlsson <emil.ohlsson@arm.com>
      Approved-by: Felix Johnny Thomasmathibalan's avatarFelix Johnny Thomasmathibalan <felixjohnny.thomasmathibalan@arm.com>
      73d1e85d
  24. Apr 29, 2025
    • Jakub Sujak's avatar
      Fix segmentation faults in benchmark tool · 49e0f869
      Jakub Sujak authored
      
      
      * Fix incorrect calculation of LHS matrix stride value
      
      For kernels that use the LHS matrix stride in their API, namely
      `kai_matmul_clamp_f32_f32_f32p8x1biasf32_6x8x4_neon_mla` and
      `kai_matmul_clamp_f16_f16_f16p16x1biasf16_6x16x8_neon_mla` kernels, the
      LHS stride value was calculated incorrectly by computing in terms of
      bits, not bytes.
      
      * Fix insufficient allocation of memory for SME kernels
      
      For SME kernels, such as
      `kai_matmul_clamp_f32_f32_f32p16vlx1b_1x16vl_sme2_mla`, the tensor sizes
       are in terms of the streaming SVE vector length. Thus, when running SME
        kernels we must scale the LHS/RHS/DST buffer sizes by the VL
        appropriately.
      
      The segmentation faults were discovered when running with address
      sanitizer enabled.
      
      Signed-off-by: Jakub Sujak's avatarJakub Sujak <jakub.sujak@arm.com>
      
      Reviewed-by: Emil Ohlsson's avatarEmil Ohlsson <emil.ohlsson@arm.com>
      Approved-by: Emil Ohlsson's avatarEmil Ohlsson <emil.ohlsson@arm.com>
      49e0f869
Loading