Skip to content
Permalink
SYCL-2020/mast…
Switch branches/tags

Commits on May 19, 2022

  1. Merge pull request #263 from gmlueck/gmlueck/usm-pointer-queries

    Clarify get_pointer_{type,device}
    keryell committed May 19, 2022
  2. Merge pull request #261 from gmlueck/gmlueck/platform-device-stable-o…

    …rder
    
    Stable order of platform and device objects
    keryell committed May 19, 2022

Commits on May 18, 2022

  1. Rename formal parameter in synopsis

    Rename this parameter to `syclContext` to match the name we use for
    all the other `context` parameters in the USM free functions.  The
    description from my previous commit already referred to these
    parameters by this name.
    gmlueck committed May 18, 2022
  2. Clarify get_pointer_{type,device}

    Clarify several things about the USM query functions `get_pointer_type`
    and `get_pointer_device`:
    
    * The return value of `get_pointer_device` is the same `device` that
      was used to allocate the USM memory (for "device" and "shared"
      allocations).  Some readers were previously confused about the
      behavior when the allocation was made against a sub-device.
    
    * For `get_pointer_device`, the pointer need not be at the start of the
      USM memory region.  It can be any pointer within the USM memory
      region.  We said this already for `get_pointer_type`, but this
      wording was missing from `get_pointer_device`.
    
    * For both queries, the USM memory region must correspond to the
      `context` that is passed.  We didn't say this before, but it was
      clearly our intent.  Otherwise, there would be no need for these
      functions to take a `context` parameter.
    
    Closes internal issue 599.
    gmlueck committed May 18, 2022

Commits on May 16, 2022

  1. Define term "root device"

    gmlueck committed May 16, 2022

Commits on May 10, 2022

  1. Stable order of platform and device objects

    Clarify that the order of the `platform` and `device` objects is the
    same each time `get_platforms()` or `get_devices()` is called.  This
    allows an application to store the index of a platform or device and
    use that index later to identify the same platform or device.
    
    Also clarify that the `get_devices()` function returns only the root
    devices, not any sub-devices that have been created.
    
    Closes internal issue 603.
    gmlueck committed May 10, 2022

Commits on May 7, 2022

  1. Xilinx is now part of AMD

    Move Xilinx contributors into the AMD part.
    keryell committed May 7, 2022
  2. Merge pull request #257 from gmlueck/gmlueck/invalid-object

    Fix name of error code
    keryell committed May 7, 2022
  3. Merge pull request #255 from aelovikov-intel/patch-1

    Clarify wording for "device selector" in the Glossary
    keryell committed May 7, 2022
  4. Merge pull request #254 from gmlueck/gmlueck/queue-destroy

    Clarify behavior of queue destructor
    keryell committed May 7, 2022
  5. Merge pull request #253 from gmlueck/gmlueck/usm-fixes

    Fix bugs in USM API signatures
    keryell committed May 7, 2022
  6. Merge pull request #250 from gmlueck/gmlueck/remove-event-paragraph

    Remove confusing paragraph about events
    keryell committed May 7, 2022
  7. Merge pull request #249 from gmlueck/gmlueck/get-sub-group

    Add missing prototype for get_sub_group()
    keryell committed May 7, 2022
  8. Merge pull request #246 from psalz/host-task-exceptions

    Clarify that exceptions in host_task are forwarded to async handler
    keryell committed May 7, 2022

Commits on May 5, 2022

  1. Fix name of error code

    There is no error code named `invalid_object`.  This got renamed a
    while ago, and we must have missed this one.
    gmlueck committed May 5, 2022
  2. Add entry to what's changed

    gmlueck committed May 5, 2022
  3. Loosen restrictions with sub-devices and context

    After gaining some implementation experience, we've learned that
    most SYCL APIs that take both a `device` and a `context` should have
    a looser requirement on the relationship between that device and
    context.  In most cases, the spec previously said something like
    "the context must encapsulate the device".  This is a little ambiguous
    because we don't define what "encapsulate" means.
    
    If we assume a strict definition like "the device object must be one of
    the devices used to construct the context", this leads to inconvenient
    code for applications that use sub-devices.  It is very common for
    applications to create a single context that contains all of the root
    devices in a platform and then use that context throughout the
    application.  However, the strict definition does not work well for
    applications like this:
    
    ```
    void foo() {
      // Get the default device and create a context that contains all
      // of the devices in the same platform.
      sycl::device d;
      sycl::context c{d.get_platform().get_devices()};
    
      // Sometime later the application creates a sub-device.
      sycl::device sd =
        d.create_sub_devices(sycl::info::partition_affinity_domain::numa)[0];
    
      // This fails because "sd" is not contained by context "c".
      sycl::queue q{sd, c};
    
      // This fails for the same reason.
      void *p = sycl::malloc_device(N, sd, c);
    }
    ```
    
    Of course, the application could avoid the problem by creating a new
    context that contains the sub-device `sd`.  However, this is
    inconvenient if the application creates sub-devices "on the fly".  It
    also requires the application to create a new context each time it
    creates a sub-device, which could be inefficient.
    
    We think a better solution is to have a looser definition like "the
    device object must either be contained by the context or be a sub-device
    of some device contained by the context".  By adopting this
    interpretation, the example code above works without any changes.
    
    We think this is a better interpretation because it makes SYCL easier
    to use and improves efficiency by reducing the number of contexts that
    an application needs to create.  We also think this interpretation can
    be implemented by backends.
    
    This PR changes the wording of all APIs that take both a `device` and
    a `context` to clarify that the device may also be a sub-device (or
    sub-sub-device, etc.) of the context.
    
    As a side-effect of this change, the `noexcept` keyword was removed
    from two of the `usm_allocator` constructors because we want to throw
    an exception when the device parameter is not contained by the context.
    I think it was a mistake to have `noexcept` here in the first place
    because these constructors also take a `property_list` parameter, and I
    presume we would want to diagnose errors with incorrect properties by
    throwing an exception.
    
    Closes internal issue 598
    gmlueck committed May 5, 2022
  4. Merge pull request #252 from Pennycook/reducer-const

    Remove const from operator[] in reducer
    keryell committed May 5, 2022
  5. Merge pull request #248 from Pennycook/atomic_fence_order_capabilities

    Add acquire-release to minimum atomic_fence order
    keryell committed May 5, 2022
  6. Merge pull request #247 from psalz/multi-cmds-exception

    Clarify what happens when submitting more than 1 command per CGF
    keryell committed May 5, 2022
  7. Merge pull request #238 from gmlueck/gmlueck/sycl-external

    Clarify SYCL_EXTERNAL
    keryell committed May 5, 2022
  8. Merge pull request #237 from gmlueck/gmlueck/usm-alignment

    Clarify alignment behavior for USM allocations
    keryell committed May 5, 2022
  9. Merge pull request #232 from gmlueck/gmlueck/empty-accessor

    Clarify empty accessor
    keryell committed May 5, 2022
  10. Merge pull request #231 from npmiller/fix-versions

    Update device and platform version descriptions
    keryell committed May 5, 2022

Commits on Apr 29, 2022

  1. Clarify wording for "device selector" in the Glossary

    [4.6.1.1] states
    
       If the highest value is negative no device is selected.
    
    As such, be more precise about the behavior for "0" 
    in the glossary wording.
    aelovikov-intel committed Apr 29, 2022

Commits on Apr 25, 2022

  1. Clarify behavior of queue destructor

    The spec already said that the `queue` destructor does not block in
    section 3.9.8.1 "Synchronization in the SYCL application":
    
    > Note that the destructors of other SYCL objects (sycl::queue,
    > sycl::context,...) do not block.
    
    However, we never really said what happens to outstanding commands
    that have been submitted to the queue.  This PR clarifies that these
    commands just run normally, with the same behavior as though the
    queue had not been destroyed.
    
    This seems like a sensible behavior, and it also enables a use case
    similar to `std:🧵:detach`.
    gmlueck committed Apr 25, 2022
Older