[Exp][CmdBuffer] Add specification for exp-command-buffer #591
Conversation
kbenzie
added
the
experimental
EwanC
left a comment
EwanC
left a comment
There was a problem hiding this comment.
Looks good to me for giving a high level summary for the feature.
Bensuo
force-pushed
the
ben/command-buffer-spec
branch
from
33d41a6 to
4866580
Compare
This is great! I will ensure this gets added to the template when we implement that in #600. |
Bensuo
force-pushed
the
ben/command-buffer-spec
branch
from
4866580 to
b717cec
Compare
Bensuo
force-pushed
the
ben/command-buffer-spec
branch
from
b717cec to
798d5af
Compare
- Add macro for extension string return from device query for command-buffers - Add Experimental Features section to docs navigation - Improve command-buffer extension specification
kbenzie
force-pushed
the
ben/command-buffer-spec
branch
from
798d5af to
e45d49e
Compare
| // sync-point | ||
| ${x}CommandBufferAppendKernelLaunchExp(hCommandBuffer, hKernel, workDim, pGlobalWorkOffset, pGlobalWorkSize, pLocalWorkSize, 1, &syncPoint, nullptr); | ||
|
|
||
| Enqueueing Command-Buffers |
There was a problem hiding this comment.
To join the dots, it was the DPC++ PR implementing the entry-point for L0 which raised this discussion intel/llvm#9992 (comment)
FYI that both Benie and Ben are on holiday this week.
There was a problem hiding this comment.
I think, in the context of UR which is heavily based on OpenCL, enqueue feels like the appropriate verb to me since it aligns with all of the other entry points which enqueue commands to a queue object.
5 participants
Note:
I've duplicated the experimental features warning across the new pages but I'm not sure if this is desirable or not, and if it is, if there is a way to specify this once and include it in multiple places.
Closes #583