Address spec generator limitation translating handles in structs #2671
Comments
|
@RossBrunton is currently working on removing the handle translation mechanism entirely in favor of a simpler approach that stores the loader metadata at the beginning of an adapter-allocated handle. See this PR. So this should go away on its own once that change goes in. |
|
I'm working on removing the handles, yes. However, it's looking like that could take longer than I'd like. I think it makes sense to hack this to work for now so that Ewan's work is unblocked, and then the hack should go away once the handle removal work is gone. |
EwanC
added a commit
to Bensuo/unified-runtime
that referenced
this issue
Feb 18, 2025
To workaround oneapi-src#2671 where the spec generator cannot translate handles inside a list of structs, add a special case to the Mako file so that we can handle the new entry-point. This is a temporary measure until the work refactoring handle translation is complete. Co-authored-by: Ross Brunton <[email protected]>
EwanC
added a commit
to reble/llvm
that referenced
this issue
Feb 19, 2025
Update the `urCommandBufferUpdateKernelLaunchExp` API for updating commands in a command-buffer to take a list of commands. The current API operates on a single command, this means that the SYCL-Graph `update(std::vector<nodes>)` API needs to serialize the list into N calls to the UR API. Given that both OpenCL `clUpdateMutableCommandsKHR` and Level-Zero `zeCommandListUpdateMutableCommandsExp` can operate on a list of commands, this serialization at the UR layer of the stack introduces extra host API calls. This PR improves the `urCommandBufferUpdateKernelLaunchExp` API so that a list of commands is passed all the way from SYCL to the native backend API. As highlighted in oneapi-src/unified-runtime#2671 this patch requires the handle translation auto generated code to be able to handle a list of structs, which is not currently the case. This is PR includes a API specific temporary workaround in the mako file which will unblock this PR until a more permanent solution is completed. Co-authored-by: Ross Brunton <[email protected]>
EwanC
added a commit
to reble/llvm
that referenced
this issue
Feb 19, 2025
Update the `urCommandBufferUpdateKernelLaunchExp` API for updating commands in a command-buffer to take a list of commands. The current API operates on a single command, this means that the SYCL-Graph `update(std::vector<nodes>)` API needs to serialize the list into N calls to the UR API. Given that both OpenCL `clUpdateMutableCommandsKHR` and Level-Zero `zeCommandListUpdateMutableCommandsExp` can operate on a list of commands, this serialization at the UR layer of the stack introduces extra host API calls. This PR improves the `urCommandBufferUpdateKernelLaunchExp` API so that a list of commands is passed all the way from SYCL to the native backend API. As highlighted in oneapi-src/unified-runtime#2671 this patch requires the handle translation auto generated code to be able to handle a list of structs, which is not currently the case. This is PR includes a API specific temporary workaround in the mako file which will unblock this PR until a more permanent solution is completed. Co-authored-by: Ross Brunton <[email protected]>
EwanC
added a commit
to reble/llvm
that referenced
this issue
Feb 21, 2025
Update the `urCommandBufferUpdateKernelLaunchExp` API for updating commands in a command-buffer to take a list of commands. The current API operates on a single command, this means that the SYCL-Graph `update(std::vector<nodes>)` API needs to serialize the list into N calls to the UR API. Given that both OpenCL `clUpdateMutableCommandsKHR` and Level-Zero `zeCommandListUpdateMutableCommandsExp` can operate on a list of commands, this serialization at the UR layer of the stack introduces extra host API calls. This PR improves the `urCommandBufferUpdateKernelLaunchExp` API so that a list of commands is passed all the way from SYCL to the native backend API. As highlighted in oneapi-src/unified-runtime#2671 this patch requires the handle translation auto generated code to be able to handle a list of structs, which is not currently the case. This is PR includes a API specific temporary workaround in the mako file which will unblock this PR until a more permanent solution is completed. Co-authored-by: Ross Brunton <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of PR #2666 I would like to define a UR entry-point that passed a list of structs, with each struct containing handles to UR objects. However the generated
ur_ldrddi.cppcode only tranlsates the UR handles of the first struct in the list, which is a limitation in https://oneapi-src.github.io/unified-runtime/core/CONTRIB.html#limitationsThis limitation is preventing UR command-buffer update from being able to take advantage of the OpenCL and Level-Zero APIs for update which let you pass a list of commands to update, currently we have to call UR update entry-point in a loop which is extra host overhead. Enabling passing a list of structs would allow more optimal native API usage.
The text was updated successfully, but these errors were encountered: