Skip to content

Reconsider mutable command-buffer structure pointer chaining #1041

@EwanC

Description

@EwanC

The cl_command_buffer_mutable_dispatch extension introduced structure pointer chains used as part of the update API

cl_int clUpdateMutableCommandsKHR(
    cl_command_buffer_khr command_buffer,
    const cl_mutable_base_config_khr* mutable_config);

The advantages of pointer chaining are extensibility without API breakages, and also the ability for layers to inject structs into the linked list. However, because the structure pointer chaining design is limited to one corner of the OpenCL standard, there are no layers using it, and the API may be more complicated than necessary as it also throws up the issues highlighted in #990 .

An alternative approach that would keep the benefit of extensibility without API breakages, but drop the extra complexity, is an API that uses an array approach rather than a linked list. Credit to @bashbaug for this idea:

cl_int clUpdateMutableCommandsKHR(
    cl_command_buffer_khr command_buffer,
    cl_uint num_configs,                    /* the number of configs in the arrays */
    const cl_config_type_khr* config_types, /* the type of each config */
    const void** configs) ;                 /* the config data, interpreted using the type */

This would be a breaking change to existing cl_khr_command_buffer_mutable_dispatch implementations and code, but this is allowed due to the provisional nature of the extension. I think this is a better final design, as in future layered extensions it's not unlikely that we might want to have more than one instance of a struct, which is forbidden in Vulkan pointer chaining semantics, and defining our own pointer chaining semantics separate from Vulkan seems like more effort than it's worth when pointer chaining isn't giving us tons of value.

In summary, I'd like to propose removing the pointer chaining update API and replace it with the proposed update API entry-point.

PRs containing proposed changes

Metadata

Metadata

Assignees

No one assigned

    Labels

    cl_khr_command_bufferRelating to the command-buffer family of extension

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions