The WebCL extension registry contains specifications for extensions to the
core WebCL API. Most of these extensions are incorporated
directly from the OpenCL extension registry, and refer to
those extensions for their behavioral definition. Because WebCL extensions are specified as
Web IDL interfaces, each specification also includes the IDL to which each implementation
will comply.
An extension template is available for the submission of
new proposed extensions. New extension proposals should be emailed to the
public WebCL mailing list.
When writing a new extension specification, it is recommended to check out
the public WebCL repository. See the
WebCL wiki page Using
Github to contribute. The extension registry files are located
under extensions/.
Each extension can be enabled at the WebCL,
WebCLPlatform, or WebCLDevice level through
the enableExtension API by passing the name of
the extension as an argument, e.g., WebCL.enableExtension("KHR_fp64"). The
method returns true if the extension was successfully enabled.
Naming conventions
WebCL extensions are prefixed with a name string indicating the
origins and level of support of that extension.
The KHR prefix is used when mirroring an OpenCL
extension that is ratified by Khronos.
The EXT prefix is used when mirroring an OpenCL
extension that is supported by multiple vendors, but is not
ratified by Khronos.
The WEBCL prefix is used for WebCL-specific
extensions, as well as extensions that originate from OpenCL,
but whose behavior has been significantly altered. Extensions
prefixed with WEBCL are intended to be compatible
with any web browser.
Extension Development Process
Extensions move through four states during their
development: proposed, draft, community approved, and Khronos
ratified.
Proposed extensions are intended for discussion on the public WebCL mailing
list, in order to move to draft status; they should not be implemented, even under
a vendor prefix. If consensus is reached in the community, the extension can be moved
to draft status.
Draft extensions may be implemented under a vendor prefix for experimentation
purposes, in order to gain experience with the extension before finalizing it. Once
consensus is reached in the community, the extension can be moved to community approved
status.
Community approved extensions should be implemented without a vendor
prefix. When a draft extension moves to community approved status, any existing
implementation should immediately remove support for the vendor-prefixed extension
name. Once implemented by a vendor, support should not be removed unless there is a serious
issue with the extension, such as a security flaw.
Khronos ratified extensions are those community approved extensions which have
been voted upon by the Khronos Board of Promoters.
Recent Revisions