Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create extensions directory. #81

Merged
merged 3 commits into from
Apr 18, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions sycl/doc/extensions/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Extensions

This is where documents can be found that propose extensions to the SYCL specification.
18 changes: 18 additions & 0 deletions sycl/doc/extensions/ordered_queue/ordered_queue.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
= SYCL Proposals: Ordered Queue
James Brodman <james.brodman@intel.com>
v0.1
:source-highlighter: pygments
:icons: font
== Introduction
This document presents an addition proposed for a future version of the SYCL Specification. The goal of this proposal is to reduce the complexity and verbosity of using SYCL for programmers.

== Ordered Queue
Queues in SYCL are out-of-order by default. SYCL constructs directed acyclic graphs to ensure tasks are properly ordered based on their data dependences. However, many programs only require linear DAGs. The overheads of constructing and managing DAGs are unnecessary for this class of program. The `ordered_queue` class exists to serve this class of programs by providing simple in-order semantics. `ordered_queue` otherwise functions identically to the normal SYCL `queue`. Due to the simpler semantics and task dependences of an in-order queue, additional programming simplifications are also possible.
[source,cpp]
----
include::ordered_queue.h[]
----

=== API Simplifications
Since `ordered_queue` has simpler in-order semantics, programmers do not need to specify dependences between tasks by building DAGs based on data dependences. Command group scope for tasks submitted to `ordered_queue` only needs to contain kernel definitions or explicit memory operations in order to define valid execution. Consequently, the `single_task` and `parallel_for` APIs, normally used on the command group `handler` class, are available directly on the `ordered_queue` class.

73 changes: 73 additions & 0 deletions sycl/doc/extensions/ordered_queue/ordered_queue.h
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
namespace sycl {
class ordered_queue {
public:
explicit ordered_queue(const property_list &propList = {});

ordered_queue(const async_handler &asyncHandler,
const property_list &propList = {});

ordered_queue(const device_selector &deviceSelector,
const property_list &propList = {});

ordered_queue(const device_selector &deviceSelector,
const async_handler &asyncHandler, const property_list &propList = {});

ordered_queue(const device &syclDevice, const property_list &propList = {});

ordered_queue(const device &syclDevice, const async_handler &asyncHandler,
const property_list &propList = {});

ordered_queue(const context &syclContext, const device_selector &deviceSelector,
const property_list &propList = {});

ordered_queue(const context &syclContext, const device_selector &deviceSelector,
const async_handler &asyncHandler, const property_list &propList = {});

ordered_queue(cl_command_queue clQueue, const context& syclContext,
const async_handler &asyncHandler = {});

/* -- common interface members -- */

/* -- property interface members -- */

cl_command_queue get() const;

context get_context() const;

device get_device() const;

bool is_host() const;

template <info::queue param>
typename info::param_traits<info::queue, param>::return_type get_info() const;

template <typename T>
event submit(T cgf);

template <typename T>
event submit(T cgf, const queue &secondaryQueue);

void wait();

void wait_and_throw();

void throw_asynchronous();

/* -- API simplifications -- */

template <typename KernelName, typename KernelType>
event single_task(KernelType kernelFunc);

template <typename KernelName, typename KernelType, int dimensions>
event parallel_for(range<dimensions> numWorkItems, kernelType kernelFunc);

template <typename KernelName, typename KernelType, int dimensions>
event parallel_for(range<dimensions> numWorkItems,
id<dimensions> workItemOffset, kernelType kernelFunc);

template <typename KernelName, typename KernelType, int dimensions>
event parallel_for(nd_range<dimensions> executionRange, kernelType kernelFunc);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are not interested in the hierarchical parallelism of SYCL instead of the one with nd_range?


};
} // namespace sycl

3 changes: 3 additions & 0 deletions sycl/doc/extensions/usm/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Unified Shared Memory

Unified Shared Memory - an extension to bring pointer-based programming to SYCL
Loading