Skip to content

Latest commit

 

History

History
52 lines (44 loc) · 3.57 KB

REQUIREMENTS.md

File metadata and controls

52 lines (44 loc) · 3.57 KB
Raw

Requirements

API and Library Requirements

API Namespace

  • API’s will clearly define the functionality
  • API’s will use a consistent style within the library
  • APIs’ will not allow namespace collision when multiple libraries are linked in the same user application
  • API will be consistent across libraries included in the product
  • Will not allow namespace collision when multiple libraries are linked in the same user application
  • Exceptions:
    • If two libraries are unlikely to used together, willing to sacrifice optimal performance
    • For existing libraries, favor API consistency vs. stylist name space

Common Functional Requirements

  • Libraries will use common resource allocation (memory, threads, device context) – under & above API where applicable
  • Libraries will support consistent data types to avoid unnecessary data manipulation / reformatting
  • Libraries will support a composable threading model and synchronous/asynchronous operations
  • Libraries will utilize unified error reporting, debug information, I/O mechanism (file, network,…), etc.

Directory Structure and Deployment Requirements

  • The Libraries can be delivered as “stand-alone” deliverables
  • The Libraries can be delivered in a common product suite configuration (with other product components)
  • When delivered in a product suite, the directory structure will conform to the master product directory layout requirements
  • The library subcomponents will be installed in a consistent directory structure across the included libraries
  • When two or more libraries are installed independently, they will conform to a common directory structure and versioning layout
  • Libraries will be packaged for installation using common packaging mechanism for the operations systems that they targeted (e.g. .rpm, .deb, .msi, etc.)

Library Language Binding Requirements

  • DPC++ Language binding requirements
    • Performance Libraries that execute on multiple Intel IP’s shall support the DPCP++ language binding as the primary mechanism for programming on multiple Intel Hardware IP’s
    • If the library supports DPC++ for a only a subset of functions for offload to an accelerator (e.g. ATS), all CPU functions should all support DPC++ Language bindings so that application developers can write their entire application in DPC++
    • If a Library only supports only the CPU, but is likely to be used with another library the supports DPC++ on CPU and ATS, the library shall also support DPC++
  • Libraries may support other language bindings (C/C++/FORTRAN/JAVA/PYTHON, etc.) to support existing user base and use cases required by the developer domain

Library API Deprecation Management

  • Library API deprecation will be managed via a change control process
  • Definitions:
    • Supported – In the currently released library and will not change at short notice.
    • Deprecated – Documented to be no longer supported, and may be removed in the future at an announced date. Users are encouraged to use an alternative API or library
    • Removed – Removed from library, no longer supported or available

Objectives for Deprecation

  • Refine and improve APIs to deliver better value for developer and Intel
    • API does not expose best performance or support important usage models
  • Remove outdated or infrequently used functionality based on usage data.

Multi year/release process

  • Goal: Provide customers ample time to review, respond and adapt
    • Proactively communicate deprecation
    • Use warning and #pragma per each deprecated item
    • Over the deprecation period: collect & analyze deprecation feedback & remove APIs