Skip to content

Commit abef58c

Browse files
author
Ewan Crawford
authored
Remove command-buffer Invalid state (#885)
* Remove command-buffer Invalid state It was discovered during cl_khr_command_buffer layered extension review that the [Invalid command-buffer state](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Ext.html#_add_new_section_section_5_x_1_command_buffer_lifecycle) is undesirable. An approach more in-keeping with the OpenCL philosophy is for an OpenCL object to be able to update the reference count of the OpenCL objects it uses. Keeping those objects alive for its lifetime, rather than having a specific validity check. This change specifies that command-buffers match that behaviour. Any validity checking further than that may be expensive, and should not be mandated. There is also a clarification in this change that interleaving queue submissions with command recording to the same queue is valid. * Warning about clSetKernelArg Add non-normative text warning that objects used as arguments to kernels recorded to a command-buffer do not have their reference count updated. * American English spelling of "behavior" Change "behaviour" to "behavior" in command-buffer related specs. * Use term "attached" The term "attached" is more consistent with the existing OpenCL spec with regards to how reference counting is specified. * Expand kernel argument note about safe usage Elaborate on the note about ref counting not being done on kernel arguments, with recommendations for users not to free objects used as kernel arguments until the command-buffer is deleted. * Move mutable-dispatch note to own spec Based on working-group feedback that the information about mutable-dispatch safe usage shouldn't live in the base specification, but instead be linked to.
1 parent a25dfe2 commit abef58c

5 files changed

Lines changed: 63 additions & 463 deletions

File tree

ext/cl_khr_command_buffer.asciidoc

Lines changed: 46 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@ This extension adds the ability to record and replay buffers of OpenCL commands.
2121
| 2021-11-10 | 0.9.0 | First assigned version (provisional).
2222
| 2022-08-24 | 0.9.1 | Specify an error if a command-buffer is finalized multiple times (provisional).
2323
| 2023-03-31 | 0.9.2 | Introduce context query {CL_COMMAND_BUFFER_CONTEXT_KHR} (provisional).
24+
| 2023-04-04 | 0.9.3 | Remove Invalid command-buffer state (provisional).
2425
|====
2526

2627
==== Dependencies
@@ -399,7 +400,6 @@ CL_COMMAND_BUFFER_CAPABILITY_OUT_OF_ORDER_KHR (0x1 << 3)
399400
CL_COMMAND_BUFFER_STATE_RECORDING_KHR 0x0
400401
CL_COMMAND_BUFFER_STATE_EXECUTABLE_KHR 0x1
401402
CL_COMMAND_BUFFER_STATE_PENDING_KHR 0x2
402-
CL_COMMAND_BUFFER_STATE_INVALID_KHR 0x3
403403
----
404404

405405
Enums for base <<command-buffer, command-buffers>> functionality:
@@ -492,6 +492,36 @@ with the command-queue used on command-buffer creation. Where a _compatible_
492492
command-queue is defined as a command-queue with identical properties targeting
493493
the same device and in the same OpenCL context.
494494

495+
While constructing a command-buffer it is valid for the user to interleave calls
496+
to the same queue which create commands, such as {clCommandNDRangeKernelKHR}, with
497+
queue submission calls, such as {clEnqueueNDRangeKernel} or
498+
{clEnqueueCommandBufferKHR}. That is, there is no effect on queue state from
499+
recording commands. The purpose of the queue parameter is to define the device
500+
and properties of the command, which are constant queries on the queue object.
501+
502+
A command-buffer object should increment the reference count of attached OpenCL
503+
objects such as queues, buffers, images, and kernels referenced in commands
504+
recorded to the command-buffer. This enables correct behavior of the
505+
command-buffer when its attached objects have been released. On destruction of
506+
the command-buffer it should decrement these reference counts, allowing the
507+
attached objects to be freed if appropriate.
508+
509+
[[command-buffer-kernel-argument-ref-counting]]
510+
[NOTE]
511+
====
512+
A command-buffer object does not update the reference count of objects set as
513+
arguments on kernels recorded into the command-buffer. This is consistent with
514+
the reference counting behavior of {clSetKernelArg}.
515+
516+
Applications should ensure that objects passed as arguments to kernels recorded
517+
to a command-buffer are not deleted until the command-buffer has been released.
518+
Undefined behavior may result from the failure to follow this usage requirement
519+
for all the command-buffers an object is used as a kernel argument in.
520+
521+
If using layered extension `cl_khr_command_buffer_mutable_dispatch`,
522+
<<mutable-dispatch-kernel-argument-safe-usage,
523+
see related note on safe usage>>.
524+
====
495525

496526
==== Add new section "Section 5.X.1 - Command Buffer Lifecycle"
497527

@@ -510,14 +540,22 @@ Pending:: Once a command-buffer has been enqueued to a command-queue it enters
510540
the Pending state until completion, at which point it moves back to the
511541
<<executable, Executable>> state.
512542

513-
[[invalid]]
514-
Invalid:: A command-buffer can enter the Invalid state if a resource that was
515-
used in a command has been modified or freed. The only valid operation to
516-
perform on a command-buffer in the Invalid state is to call
517-
{clReleaseCommandBufferKHR} for each of the reference counts the application
518-
owns.
543+
////
544+
Image generated from the following mermaid diagram description using https://mermaid.live
545+
Ideally we'd use the asciidoctor-diagram extension to generate the rendered diagram, but
546+
there are issues installing the gem with ruby 2.3.3
519547
520-
image::images/commandbuffer_lifecycle.svg[align="center", title="Lifecycle of a command-buffer."]
548+
[mermaid, "Lifecycle of a command-buffer", png]
549+
....
550+
stateDiagram-v2
551+
[*] --> Recording: Create
552+
Recording -->Executable: Finalize
553+
Executable --> Pending: Enqueue
554+
Pending --> Executable: Completion
555+
....
556+
////
557+
558+
image::images/commandbuffer_lifecycle.png[align="center", title="Lifecycle of a command-buffer."]
521559

522560
[[pending_count]]
523561
The Pending Count is the number of copies of the command
@@ -622,21 +660,6 @@ include::{generated}/api/protos/clRetainCommandBufferKHR.txt[]
622660

623661
Increments the _command_buffer_ reference count.
624662

625-
[NOTE]
626-
====
627-
A command-buffer object updates the reference count for objects such as
628-
buffers, images, and kernels used as parameters for commands recorded to the
629-
command-buffer.
630-
631-
For example, recording a ND-range kernel via {clCommandNDRangeKernelKHR} into a
632-
command-buffer and then releasing the kernel object will still allow continued
633-
safe use of the command-buffer. As the reference count of the kernel object
634-
will have been incremented when the command was recorded, and then on
635-
command-buffer release the kernel reference count will be decremented. If at
636-
that point the kernel reference count reaches 0, the kernel object will be
637-
freed.
638-
====
639-
640663
_command_buffer_ Specifies the command-buffer to retain.
641664

642665
{clRetainCommandBufferKHR} returns {CL_SUCCESS} if the function is executed
@@ -1575,9 +1598,6 @@ _param_value_ by {clGetCommandBufferInfoKHR} is described in the table below.
15751598
{CL_COMMAND_BUFFER_STATE_PENDING_KHR} is returned when an instance of
15761599
_command_buffer_ has been enqueued for execution but not yet completed.
15771600

1578-
{CL_COMMAND_BUFFER_STATE_INVALID_KHR} is returned when _command_buffer_ is
1579-
in an <<invalid, Invalid>> state.
1580-
15811601
| {CL_COMMAND_BUFFER_PROPERTIES_ARRAY_KHR}
15821602
| {cl_command_buffer_properties_khr_TYPE}[]
15831603
| Return the _properties_ argument specified in {clCreateCommandBufferKHR}.

ext/cl_khr_command_buffer_mutable_dispatch.asciidoc

Lines changed: 16 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -441,6 +441,20 @@ affect on the original kernel object used when the command was recorded, and
441441
only influence the {clCommandNDRangeKernelKHR} command associated with the
442442
mutable-dispatch.
443443

444+
[[mutable-dispatch-kernel-argument-safe-usage]]
445+
[NOTE]
446+
====
447+
The base `cl_khr_command_buffer` extension
448+
<<command-buffer-kernel-argument-ref-counting, notes>> that a command-buffer
449+
does not update the reference count of objects set as arguments on kernels
450+
recorded into the command-buffer.
451+
452+
The implications for applications using {clUpdateMutableCommandsKHR} is
453+
that it is safe to delete objects used as kernel command arguments, if all the
454+
kernel commands using that object as an argument have had their arguments
455+
replaced with a different object.
456+
====
457+
444458
To facilitate performant usage for pipelined work flows, where applications
445459
repeatedly call command-buffer update then enqueue, implementations may defer
446460
some of the work to allow {clUpdateMutableCommandsKHR} to return immediately.
@@ -455,10 +469,10 @@ The function
455469
include::{generated}/api/protos/clUpdateMutableCommandsKHR.txt[]
456470

457471
Modifies the configuration of mutable-command handles returned during
458-
_command_buffer_ recording, updating the behaviour of those commands in future
472+
_command_buffer_ recording, updating the behavior of those commands in future
459473
enqueues of _command_buffer_. Using this function when _command_buffer_ is in
460474
the <<pending, pending>> state and not created with the
461-
{CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR} flag causes undefined behaviour.
475+
{CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR} flag causes undefined behavior.
462476

463477
[NOTE]
464478
====

images/commandbuffer_lifecycle.png

37.7 KB
Loading

0 commit comments

Comments
 (0)