@@ -9,7 +9,7 @@ include::{generated}/meta/{refprefix}cl_khr_icd.txt[]
99=== Other Extension Metadata
1010
1111*Last Modified Date*::
12- 2020 -04-21
12+ 2025 -04-01
1313*IP Status*::
1414 No known IP claims.
1515
@@ -48,6 +48,8 @@ An object is said to be ICD compatible if it is of the following structure:
4848struct _cl_<object>
4949{
5050 struct _cl_icd_dispatch *dispatch;
51+ // Since version 2.0.0
52+ void *dispatch_data;
5153 // ... remainder of internal data
5254};
5355----
@@ -67,6 +69,13 @@ can be appended.
6769Functions which do not have an argument from which the vendor implementation
6870may be inferred have been deprecated and may be ignored.
6971
72+ New in version 2.0.0, object that are ICD 2 compatible should also contain
73+ a `dispatch_data` field of type `void *` that the loader is free to modify
74+ for a platform through the {clIcdSetPlatformDispatchDataKHR} new API entry
75+ point. In order to distinguish ICD 1 and ICD 2 objects, the pointers to
76+ `clGetPlatformIDs` and `clUnloadCompiler` in the dispatch structure must be
77+ set to `CL_ICD2_TAG_KHR`. The vendor driver is responsible for propagating
78+ the `dispatch_data` value when returning objects to users.
7079
7180=== ICD Data
7281
@@ -230,10 +239,31 @@ value {CL_PLATFORM_ICD_SUFFIX_KHR}.
230239If any of these steps fail, the ICD Loader will ignore the Vendor ICD and
231240continue on to the next.
232241
242+ New in version 2.0.0, the ICD Loader will also query the following functions
243+ from the library: {clIcdGetFunctionAddressForPlatformKHR} and
244+ {clIcdSetPlatformDispatchDataKHR}. If these two functions are present and the
245+ pointers to `clGetPlatformIDs` and `clUnloadCompiler` in the dispatch
246+ structure of a platform is set to `CL_ICD2_TAG_KHR` the platform will be
247+ deemed ICD 2 compatible and dispatch will be managed by the ICD Loader. If the
248+ `CL_ICD2_TAG_KHR` tag is present but one of the two functions above is
249+ missing or it the tag is present in only one of the pointers, the ICD Loader
250+ will ignore the Vendor ICD and continue on to the next.
251+
252+ During initialization, after calling {clIcdGetPlatformIDsKHR} to query the
253+ available platforms, the ICD Loader will, for each ICD 2 compatible platform,
254+ query dispatchable entry points using {clIcdGetFunctionAddressForPlatformKHR}
255+ and then set the platform dispatch data using
256+ {clIcdSetPlatformDispatchDataKHR}.
257+
233258=== New Commands
234259
235260 * {clIcdGetPlatformIDsKHR}
236261
262+ New in version 2.0.0:
263+
264+ * {clIcdGetFunctionAddressForPlatformKHR}
265+ * {clIcdSetPlatformDispatchDataKHR}
266+
237267=== New Enums
238268
239269Accepted as _param_name_ to the function {clGetPlatformInfo}:
@@ -244,6 +274,11 @@ Returned by {clGetPlatformIDs} when no platforms are found:
244274
245275 * {CL_PLATFORM_NOT_FOUND_KHR}
246276
277+ New in version 2.0.0, used as a value in the pointers to `clGetPlatformIDs`
278+ and `clUnloadCompiler` in the dispatch structure:
279+
280+ * `CL_ICD2_TAG_KHR`
281+
247282=== Issues
248283
249284 . Some OpenCL functions do not take an object argument from which their
@@ -286,9 +321,31 @@ obtaining the ICD dispatch table.
286321On detecting a `NULL` object it will return one of the an invalid object
287322error values (e.g. {CL_INVALID_DEVICE} corresponding to the object in
288323question.
324+ --
325+
326+ . How will the ICD loader avoid calling entry points outside of the dispatch
327+ table of old implementations, potentially causing segfaults?
328+ +
329+ --
330+ *RESOLVED*: From versions 2.0.0 and above, the loader will be responsible for
331+ managing dispatch data information per platform. The content of the dispatch
332+ table is obtained through a dedicated entry point, and missing entry points are
333+ replaced by stubs that return {CL_INVALID_OPERATION}.
334+ --
335+
336+ . How will the ICD loader set the loader managed dispatch information in new
337+ objects? Some of these objects may be created by extension functions that
338+ the loader is unaware of.
339+ +
340+ --
341+ *RESOLVED*: During initialization, the loader will set the platform dispatch
342+ information through a new entry point. The implementation will be responsible
343+ for propagating this information to new objects.
289344--
290345
291346=== Version History
292347
293348 * Revision 1.0.0, 2020-04-21
294349 ** First assigned version.
350+ * Revision 2.0.0, 2025-04-01
351+ ** Loader managed dispatch.
0 commit comments