tree: 58258250881de8dce4cc5cc5fb28b97eca317a1e [path history] [tgz]
  1. testdata/
  2. allocator_test.h
  3. buffer_mapping_test.h
  4. CMakeLists.txt
  5. command_buffer_dispatch_test.h
  6. command_buffer_push_constants_test.h
  7. command_buffer_test.h
  8. cts_test_base.h
  9. cts_test_template.cc.in
  10. descriptor_set_layout_test.h
  11. driver_test.h
  12. event_test.h
  13. executable_cache_test.h
  14. pipeline_layout_test.h
  15. README.md
  16. semaphore_submission_test.h
  17. semaphore_test.h
runtime/src/iree/hal/cts/README.md

Conformance Test Suite (CTS) for HAL implementations

These tests exercise IREE's Hardware Abstraction Layer (HAL) in a way that checks for conformance across implementations and devices. The tests themselves are structured to help with HAL driver development by using individual features in isolation, demonstrating typical full-system usage, and pointing out where capabilities are optional.

Usage

Each HAL driver (in-tree or out-of-tree) can use the iree_hal_cts_test_suite() CMake function to create a set of tests. See the documentation in iree_hal_cts_test_suite.cmake and cts_test_base.h for concrete details.

On testing for error conditions

In general, error states are only lightly tested because the low level APIs that IREE's HAL is designed to thinly abstract over often assume programmer usage will be correct and treat errors as undefined behavior. See the Vulkan spec:

While the generic tests in the CTS may not be able to check for error conditions exhaustively, individual HAL implementations can implement stricter behavior or enable higher level checks like what the Vulkan Validation Layers provide.

Tips for adding new HAL implementations

  • Driver (iree_hal_driver_t) and device (iree_hal_device_t) creation, tested in driver_test, are both prerequisites for all tests.
  • Tests for individual components (e.g. descriptor_set_layout_test) are more approachable than tests which use collections of components together (e.g. command_buffer_test).