Skip to content

Conversation

@gmlueck
Copy link
Contributor

@gmlueck gmlueck commented Oct 29, 2025

The example in the specification was using an old API that we removed in #14785. Update the example and the spec wording to use launch_config from sycl_ext_oneapi_enqueue_functions to pass the property with the size of the scratch memory.

The example in the specification was using an old API that we removed
in intel#14785.  Update the example and the spec wording to use
`launch_config` from sycl_ext_oneapi_enqueue_functions to pass the
property with the size of the scratch memory.
@gmlueck gmlueck requested a review from a team as a code owner October 29, 2025 20:13
local memory capacity as reported by `info::device::local_mem_size`
then the implementation must throw a synchronous exception with the
`errc::memory_allocation` error code from the kernel invocation command
(e.g. `parallel_for`). This check must take all APIs that allocation device

Choose a reason for hiding this comment

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

Will we have a check to confirm whether the SLM size is set for certain kernel?
Say, if a kernel calls the syclex::get_work_group_scratch_memory() in kernel body, but we do not set the syclex::work_group_scratch_size in nd_launch/parallel_for, will an exception be thrown?
I'm asking this because looks like there will be no any warning or error in current implementation.

Copy link
Contributor Author

@gmlueck gmlueck Oct 31, 2025

Choose a reason for hiding this comment

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

I think this makes sense, and it seems to me that it would be easy to implement. I think we just need a check here to see if WorkGroupMemorySize has been set by the user.

https://github.com/intel/llvm/blob/sycl/sycl/source/detail/scheduler/commands.cpp#L2474-L2481

We should be careful, though, not to throw an exception just because the user set WorkGroupMemorySize to 0. Setting the size to 0 should be allowed.

@AlexeySachkov and @steffenlarsen do you see any problem with this? I assume this code is executed synchronously by the same application thread that launches the kernel, right? Or, is this code executed asynchronously by another thread? If that is the case, the error would be an async error.

I think we could throw errc::memory_allocation in this scenario too, and we can distinguish this case from the out-of-memory case via the message string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants