-
Notifications
You must be signed in to change notification settings - Fork 116
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
[UR] Initial spec for the enqueue allocation API #2295
base: main
Are you sure you want to change the base?
Conversation
af9b768
to
d0c58ef
Compare
d0c58ef
to
697d6f7
Compare
2ba7bc6
to
bc9d8a4
Compare
First basic work in progress spec.
bc9d8a4
to
c854119
Compare
@oneapi-src/unified-runtime-native-cpu-write, @oneapi-src/unified-runtime-opencl-write, @oneapi-src/unified-runtime-hip-write, @oneapi-src/unified-runtime-cuda-write, @oneapi-src/unified-runtime-level-zero-write. |
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, just a couple of typos
UR command enqueues without forcing synchronization points in the asynchronous | ||
command DAG associated with a queue. This can allow applications to compose | ||
memory allocation and command execution asynchronously, which can improve | ||
performancet. |
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.
performancet. | |
performance. |
name: hQueue | ||
desc: "[in] handle of the queue object" | ||
- type: $x_usm_pool_handle_t | ||
desc: "[in][optional] handle of the USM memory pooliptor" |
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.
desc: "[in][optional] handle of the USM memory pooliptor" | |
desc: "[in][optional] handle of the USM memory pool" |
- type: $x_queue_handle_t | ||
name: hQueue | ||
desc: "[in] handle of the queue object" | ||
- type: $x_usm_pool_handle_t |
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.
Just to make sure, are we using the same pool handle as for regular allocations, instead of introducing a new pool type? I don't remember what was decided.
Those changes are based on the initial PR (#2180) with minor changes, wording and CI testing fixes.