Adding Info Objects or hints to SYCL

MPI supports info objects, see MPI 4.0 standard chapter 10. They are hints to the implementation and may be ignored. SQL supports a similar mechanism. I am wondering whether adding hints to SYCL would provide further optimisation opportunities.

let mut queue = Queue::new();

let buffer = Buffer::<f64, 3>::new3(N, N, N);

let range = Range::new2(N, N);
let accessor = DeviceAccessor::new(&buffer, AccessMode::Write,

let command_group = CommandGroup::builder()
    .add_accessor("A", Rc::new(accessor))
    .add_parallel_for("index", &range, "A[index] = index[0] * 2 + index[1];")

enum class AccessorInfo {

In my first attempt, I am adding hints to accessors. You can specify the memory access pattern.

Most of the SYCL objects accept properties to somehow tweak the behavior as you suggest.
There are a few properties SYCL™ 2020 Specification (revision 5) defined in the standard but many more are in use as extensions in the various implementations (for example to specify on which FPGA memory bank a buffer is viewed through an accessor, etc.).
So, globally, I would say that what you propose is useful.
But do you think we need another kind of objects like “hint” beyond the property lists we have already?
Otherwise, we could start a SYCL Rust TSG (Task Sub-Group) inside the SYCL working group if you are motivated. :slight_smile:

Maybe hints and property lists have different semantics. Saying that the access pattern of this accessor is streaming and it would benefit from HBM as a hint may be ignored by the runtime. I believe a property list is more assertive and may not be ignored.

In most cases, it would change the semantics of the program, if you would ignore property lists. Hints are different.

It depends on what you put in the semantics. At the end this is the choice of the property implementer.
For example we want AMD FPGA properties to be ignored when running on CPU such as if there is no HBM or DDR bank the program can still run.

Totally agreed. These are neither vendor nor device specific hints. I just says would benefit from HBM. Implementations are free to ignore this hint even if they have HBM.

Scenario 1: The first accessor has a hint low latency. The second accessor has a hint high bandwidth.
Scenario 2: No hints at all.

I guess there are cases where the first scenario is faster because the implementation can make more informed decisions.

Globally I would say this is always good to have more information as you propose.
But at the same time it has to be driven by the current implementations for some existing hardware.
Looking at chapter 10, this is similar to SYCL properties, just that in SYCL this is simpler since it relies on modern C++ and not C or Fortran.

Note that I used an enum class for hints to limit the number of possible values.