[UR][L0] Add support for passing device list to urProgramBuild #919
Conversation
|
Also please re-base these changes on top of 3c6f02c |
piProgramBuild receives a list of devices, while urProgramBuild does not. This produces a series of issues when a UR program needs to be created for a specific device. So define a new API, called urProgramBuildExp to pass this list. Authored-by: [email protected]
kbenzie
force-pushed
the
multi_dev_build_0.7
branch
from
be089af to
50271d4
Compare
Since 3c6f02c isn't based on any release branch there's no branch to base a PR on, so I've created the multi-device-compile-hotfix branch containing the changes which include This PR will continue to target the v0.7.x branch since we can actually review it. We'll also need to pull the changes into main. I did have to update the registry values in this PR to increment on top of the latest entry-point ID on main. I will create a PR for this. |
kbenzie
force-pushed
the
multi_dev_build_0.7
branch
from
50271d4 to
4f73008
Compare
|
Expand upon the introduction of `urProgramBuildExp` and include `urProgramCompileExp` and `urProgramLinkExp` which include a device-list in place of a context. These more closely align with the PI/OpenCL analogues but only to introduce device-lists, not all extant arguments from those entry-points. This patch also moves the `urProgramBuildExp` definition into an experimental feature file and introduces a brief document containing motivation.
kbenzie
force-pushed
the
multi_dev_build_0.7
branch
from
4f73008 to
13aaca7
Compare
Thanks much! I think we were able to address the multi-device issues in 2024.0 without needing these UR loader changes. Remember, that the default SYCL plugin is still a direct L0 plugin (bypassing UR loader), and UR plugin (that does require UR loader) is still an experimental feature. So, we made L0 plugin work while UR plugin would fallback to the old APIs. This should be good enough for 2024.0 release. So that might be a short-living branch. Keep it around for a while, but otherwise we need these multiple-device APIs into the main trunk UR for 2024.1. Thanks all for the quick help! |
see #924 (comment) |
| UR_APIEXPORT ur_result_t UR_APICALL | ||
| urProgramBuildExp( | ||
| ur_program_handle_t hProgram, ///< [in] Handle of the program to build. | ||
| uint32_t numDevices, ///< [in] number of devices |
There was a problem hiding this comment.
we could say here that if numDevices is 0, then urProgramBuildExp would be have the same as urProgramBuild, where the program is built for all the devices in the context.
There was a problem hiding this comment.
In order to match the OpenCL/PI interface, there is no context paramter in urProgramBuildExp.
| UR_APIEXPORT ur_result_t UR_APICALL | ||
| urProgramCompileExp( | ||
| ur_program_handle_t hProgram, ///< [in][out] handle of the program to compile. | ||
| uint32_t numDevices, ///< [in] number of devices |
There was a problem hiding this comment.
In order to match the OpenCL/PI interface, there is no context paramter in urProgramCompileExp.
| UR_APIEXPORT ur_result_t UR_APICALL | ||
| urProgramLinkExp( | ||
| ur_context_handle_t hContext, ///< [in] handle of the context instance. | ||
| uint32_t numDevices, ///< [in] number of devices |
|
Now available in v0.7.2 |
piProgramBuild receives a list of devices, while urProgramBuild does not. This produces a series of issues when a UR program needs to be created for a specific device.
So define a new API, called urProgramBuildExp to pass this list.
Authored-by: [email protected]