-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove command-buffer command handle ref counting #2578
Remove command-buffer command handle ref counting #2578
Conversation
be8b4fc
to
ef1de22
Compare
Reflects UR change from oneapi-src/unified-runtime#2578 where we no longer need to manually manage the lifetimes of the individual commands in a UR command-buffer.
Reflects UR change from oneapi-src/unified-runtime#2578 where we no longer need to manually manage the lifetimes of the individual commands in a UR command-buffer.
ef1de22
to
460eac2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
460eac2
to
49fb7a9
Compare
49fb7a9
to
924569c
Compare
924569c
to
eb23fe5
Compare
ping @oneapi-src/unified-runtime-native-cpu-write & @oneapi-src/unified-runtime-level-zero-write for review |
@EwanC please pull in the changes from main branch and run |
eb23fe5
to
7fba037
Compare
The handles to individual commands returned from command-buffer append entry-points currently need reference counted by the user. However this isn't a model that maps to OpenCL/CUDA/HIP/Level-Zero where the lifetime of commands is tied to the lifetime of the parent command-buffer/graph/command-list. Remove this idiom from the command-buffer UR API, adapters, and CTS. The APIs that are removed are * `urCommandBufferCommandGetInfoExp` * `urCommandBufferReleaseCommandExp` * `urCommandBufferRetainCommandExp`
7fba037
to
df1de2d
Compare
Done, thanks for the heads-up on the conflict |
Reflects UR change from oneapi-src/unified-runtime#2578 where we no longer need to manually manage the lifetimes of the individual commands in a UR command-buffer.
Reflects UR change from oneapi-src/unified-runtime#2578 where we no longer need to manually manage the lifetimes of the individual commands in a UR command-buffer.
The handles to individual commands returned from command-buffer append entry-points currently need reference counted by the user. However this isn't a model that maps to OpenCL/CUDA/HIP/Level-Zero where the lifetime of commands is tied to the lifetime of the parent command-buffer/graph/command-list.
Remove this idiom from the command-buffer UR API, adapters, and CTS. The APIs that are removed are:
urCommandBufferCommandGetInfoExp
urCommandBufferReleaseCommandExp
urCommandBufferRetainCommandExp
DPC++ PR - intel/llvm#16670