The Khronos® Group announces the ratification and public release of the SYCL™ 2020 Provisional Specification. SYCL is a standard C++ based heterogeneous parallel programming framework for accelerating High Performance Computing (HPC), machine learning, embedded computing, and compute-intensive desktop applications on a wide range of processor architectures, including CPUs, GPUs, FPGAs, and AI processors.The SYCL 2020 Provisional Specification is publicly available today to enable feedback from developers and implementers before the eventual specification finalization and release of the SYCL 2020 Adopters Program, which will enable implementers to be officially conformant—tentatively expected by the end of the year.

Khronos invites you to give feedback on this thread.


A small thing I just noticed; in section 4.14.4 “Rules for parameter passing to kernels” it says that

It is illegal to pass a pointer or reference argument to a kernel.

…which I’m pretty sure is at odds with USM.

1 Like

Thank you. I have opened an internal issue in our gitlab issue 436 for this.


Table 4.31 gives constructors for a buffer object.

With c++17 there is proper support std::shared_ptr<T[]>. It looks like that cl::sycl::buffer could use new constructors with type buffer(const std::shared_ptr<T[]>& hostData, […]). It could probably even replace the ones with a std::shared_ptr<T> parameter but this would be backward incompatible.

What do you think?

In section, the code samples are as follows:

buffer<int, 1> b { ptr, range<2>{10, 10} };

It should be buffer<int, 2> or range<1>

Hi Isix, thank you. I have opened internal issue 445 for this.

Hi there. I’ve just been perusing the SYCL 2020 provisional spec and noticed that the buffer interface doesn’t provide size() and byte_size() member functions like the accessor interfaces do, only get_count() and get_size(). Having to specialise my code for the latter two was my most common frustration with 1.2.1 so I was delighted to see it being addressed in 2020. I was just wondering why this ‘fix’ wasn’t applied to buffers too? Is this something that could be added to the final 2020 spec?

Thanks for all your hard work with SYCL!

Thank you for all your kind words, James ‘invexed’. The SYCL WG is a group of crazy smart people who has been meeting 2x a week to improve the provisional to final for the last 7 months. These feedbacks are very useful and we also noticed this inconsistency issue during our drive to final spec review. IP rules prevent me from revealing anything at this point but rest assured we will look into fixing this if it is still missing.

Just to check, is this what you are looking for in the buffer interface:
size_t byte_size() const noexcept;
size_t size() const noexcept

Thank you.;

Wow, I didn’t realise there was that much work going on behind the scenes! I look forward to the final spec being released and being able to use all the new features.

Yes that is indeed what I meant. Thanks again.

P.S. I wasn’t sure if here or GitHub was the best place to submit feedback so in the end I did both. I’ll close the GitHub issue and link to your above reply.

Just to confirm that this has been already fixed in the to-be-final version.
Thanks for your feedback and sharp eyes!

In table 4.116, I believe

T load(
    memory_order order = default_read_order
    memory_odrer scope = default_scope)const

should be

T load(
    memory_order order = default_read_order
    memory_scope scope = default_scope)const
1 Like

Actually it has been already fixed in the final specification to be published soon.
But I realize we have also forgotten a noexcept in the specification…
Thank you for pointing the problem.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.