merge from master

Author: rscohn2

doc/core-teams.rst

@@ -0,0 +1,83 @@
+============
+ Core Teams
+============
+
+Leads are in **bold**.
+
+oneAPI
+======
+
+* Aristarkhov, Vasily 
+* Belyakov, Igor 
+* **Cohn, Robert**
+* Fomenko, Evarist 
+* Kinsner, Michael 
+* Kraynyuk, Maria 
+* Kukanov, Alexey 
+* Nikolaev, Andrey 
+* Patty, Spencer 
+* Shiryaev, Mikhail 
+* Smith, Timmie 
+* Waters, Zack 
+
+
+DPC++
+=====
+
+* Brodman, James 
+* **Kinsner, Michael**
+
+
+oneDPL
+======
+
+* **Kukanov, Alexey**
+* Smith, Timmie 
+
+
+oneDNN
+======
+
+* **Fomenko, Evarist**
+
+
+oneCCL
+======
+
+* **Shiryaev, Mikhail**
+
+
+Level Zero
+==========
+
+* **Waters, Zack**
+
+
+oneDAL
+======
+
+* Chernov, Mikhail
+* Grigoriev, Alexey
+* Israfilov, Ruslan
+* **Nikolaev, Andrey**
+* Smirnov, Michael
+
+
+oneTBB
+======
+
+* **Kukanov, Alexey**
+
+
+oneVPL
+======
+
+* **Aristarkhov, Vasily**
+* **Belyakov, Igor**
+
+
+oneMKL
+======
+
+* **Kraynyuk, Maria**
+* Patty, Spencer 

doc/governance.rst

@@ -0,0 +1,69 @@
+============
+ Governance
+============
+
+Roles
+=====
+
+Each oneAPI element has a **core team** and **lead** who are the
+primary authors for the specification. The community is invited to
+make feature requests or proposals, which are reviewed by the core
+team.
+
+The overall specification also has a core team and lead. The **oneAPI
+core team** is responsible for issues that involve multiple oneAPI
+elements and provides general oversight.
+
+Core Team members and leads are `published <core-teams.rst>`__.
+
+`Technical advisory boards
+<https://github.com/oneapi-src/oneapi-tab>`__ review topics related to
+specifications and provide feedback. There may be overlap between core
+team and technical advisory board.
+
+
+Decision Making
+===============
+
+Specification changes and other decisions are by `consensus
+<https://en.wikipedia.org/wiki/Wikipedia:What_is_consensus>`__ of the
+appropriate core team. The lead determines if consensus has been
+reached and what action to take when there is disagreement. Decision
+making balances the needs of the community, including: technical
+advisory boards, implementations, and users. Decision making is
+transparent, with clear explanations and constructive feedback for
+rejected proposals.
+
+
+Membership
+==========
+
+A core team may decide to add new members or designate a new
+lead. Members will typically have a history of contribution to the
+specification, contribution to an implementation, or as an end-user of
+an implementation. Membership is open to all companies, institutions,
+and implementations.
+
+
+Commit Rights
+=============
+
+Committers follow the direction of the core team. Core teams decide
+who has commit rights to the repository.
+
+
+Governance Changes
+==================
+
+Governance is intended to be informal and low overhead while
+encouraging broad participation from the community. oneAPI core team
+may change governance as the community evolves.
+
+
+Code of Conduct
+===============
+
+We follow `Contributor Covenant
+<https://www.contributor-covenant.org>`__. Contact a core team member
+or `oneAPI leadership <mailto:[email protected]>`__ with questions or
+to report an issue.

doc/versioning.rst

@@ -0,0 +1,81 @@
+========================
+Specification versioning
+========================
+
+This document describes the versioning of the specification for oneAPI
+elements (e.g. oneMKL, oneVPL) and for oneAPI, which includes all the
+elements. Specification versioning is independent of oneAPI product
+versioning.
+
+Product specification vs standard specification
+===============================================
+
+A *product specification* documents a single implementation. It is
+typically completed before implementation to get feedback, and as a
+reference for implementation, testing, and the creation of end-user
+documentation. A *standard specification* documents the standard,
+which may have multiple implementations. It is used to get feedback
+and agreement between potential implementations.  oneAPI specification
+is primarily a standard specification. An implementation may contain
+features that are not part of the standard. It may be a feature being
+considered for standardization, or features that are not suitable for
+inclusion in oneAPI standard.
+
+
+oneAPI specification versioning
+===============================
+
+Versioning is MAJOR.MINOR rev REVISION
+
+Increment the:
+
+1. MAJOR version when adding major new functionality and making
+   incompatible API changes, including removing APIs.
+     
+2. MINOR version when adding minor functionality and API changes
+   that are backwards compatible.
+     
+3. REVISION when making backwards compatible bug fixes or any editing
+   change in the document, including minor changes such as correcting
+   typos. Initial REVISION is 1.
+
+The distinction between major and minor functionality is determined by
+the core group. Latest REVISION is implicit because REVISIONs do not
+change the meaning.
+
+Element versioning
+==================
+
+By default, elements do not have independent versioning. An element
+may incorporate another specification by reference, and may include
+extensions or other features that are not part of the included
+specification. DPC++ is an example, as it includes SYCL, which is used
+independent of oneAPI and DPC++ and has its own standards body. Other
+elements can be split out and have independent versioning if the need
+arises with agreement of the oneAPI core team. An example would be
+when an element has multiple implementations, and the implementation
+does not include the rest of the elements.
+
+Specification version approval
+==============================
+
+The oneAPI specification must be approved by its `core team
+<core-teams.rst>`__. Element specifications must be approved by its
+core team and the oneAPI spec core team.  Updates which only change
+the revision may be approved by the leads.
+
+
+Provisional versions
+====================
+
+A specification may be published before approval, but must be labeled
+provisional.  Provisional specifications are published as a series of
+revisions until approval. After approval, the provisional label is
+removed and the rev is set to 1.
+
+Example
+  | oneAPI provisional 1.1 rev 1
+  | oneAPI provisional 1.1 rev 2
+  | oneAPI provisional 1.1 rev 3
+  | oneAPI 1.1 rev 1
+

roadmap.rst

@@ -14,7 +14,7 @@ Version    Date        Notes
 0.8.0_     05/28/2020  80% content
 0.8.5_     06/26/2020  85% content
 0.9.0_     07/30/2020  Final Gold Preview
-1.0.0_     08/30/2020  Gold Release
+1.0.0_     10/29/2020  Gold Release
 ========   ==========  ===========
 
 Details:
@@ -341,9 +341,8 @@ Schedule
 =========  ==========
 Date       Milestone
 =========  ==========
-8/17/2020  Cutoff date for accepting feedback for inclusion in this version
-8/28/2020  Code freeze
-8/30/2020  Release
+10/27/2020  Code freeze
+10/29/2020  Release
 =========  ==========
 
 - Overall

source/elements/oneVPL/include/onevpl/mfxdefs.h

@@ -31,8 +31,8 @@
   #define MFX_VERSION_MINOR ((MFX_VERSION) % 1000)
 #endif
 
-/*! This is correspondent version of MediaSDK Legacy API which is used as a basis 
-   for the current oneVPL API. */
+/*! This is correspondent version of the Intel(r) Media SDK legacy API that is used as a basis 
+   for the current oneAPI Video Processing Library (oneVPL) API. */
 
 #define MFX_LEGACY_VERSION 1034
 
@@ -58,7 +58,7 @@ extern "C"
 /* The general rule for alignment is following:
    - structures with pointers have 4/8 bytes alignment on 32/64 bit systems
    - structures with fields of type mfxU64/mfxF64 (unsigned long long / double)
-     have alignment 8 bytes on 64 bit and 32 bit Windows, on Linux alignment is 4 bytes
+     have alignment 8 bytes on 64 bit and 32 bit Windows*, on Linux* alignment is 4 bytes
    - all the rest structures are 4 bytes aligned
    - there are several exceptions: some structs which had 4-byte alignment were extended
      with pointer / long type fields; such structs have 4-byte alignment to keep binary
@@ -70,11 +70,11 @@ extern "C"
 #if defined(_WIN64) || defined(__LP64__)
     #define MFX_PACK_BEGIN_STRUCT_W_PTR()    MFX_PACK_BEGIN_X(8)
     #define MFX_PACK_BEGIN_STRUCT_W_L_TYPE() MFX_PACK_BEGIN_X(8)
-/* 32-bit ILP32 data model Windows (Intel architecture) */
+/* 32-bit ILP32 data model Windows* (Intel(r) architecture) */
 #elif defined(_WIN32) || defined(_M_IX86) && !defined(__linux__)
     #define MFX_PACK_BEGIN_STRUCT_W_PTR()    MFX_PACK_BEGIN_X(4)
     #define MFX_PACK_BEGIN_STRUCT_W_L_TYPE() MFX_PACK_BEGIN_X(8)
-/* 32-bit ILP32 data model Linux */
+/* 32-bit ILP32 data model Linux* */
 #elif defined(__ILP32__)
     #define MFX_PACK_BEGIN_STRUCT_W_PTR()    MFX_PACK_BEGIN_X(4)
     #define MFX_PACK_BEGIN_STRUCT_W_L_TYPE() MFX_PACK_BEGIN_X(4)

source/elements/oneVPL/include/onevpl/mfxstructures.h

@@ -2291,7 +2291,7 @@ enum {
 
     MFX_MEMTYPE_INTERNAL_FRAME  = 0x0001, /*!< Allocation request for internal frames */
     MFX_MEMTYPE_EXTERNAL_FRAME  = 0x0002, /*!< Allocation request for I/O frames */
-    MFX_MEMTYPE_EXPORT_FRAME    = 0x0008, /*!< Application requests frame handle export to some associated object. For Linux frame handle can be
+    MFX_MEMTYPE_EXPORT_FRAME    = 0x0008, /*!< Application requests frame handle export to some associated object. For Linux* frame handle can be
                                                considered to be exported to DRM Prime FD, DRM FLink or DRM FrameBuffer Handle. Specifics of export
                                                types and export procedure depends on external frame allocator implementation */
     MFX_MEMTYPE_SHARED_RESOURCE = MFX_MEMTYPE_EXPORT_FRAME, /*!< For DX11 allocation use shared resource bind flag. */