forked from KhronosGroup/OpenCL-Docs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
OpenCL_C.txt
17597 lines (14601 loc) · 657 KB
/
OpenCL_C.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
// Copyright 2017-2024 The Khronos Group.
// SPDX-License-Identifier: CC-BY-4.0
// Extensions to enable
// Must be included before the header and attribs.txt
include::{generated}/specattribs.adoc[]
= The OpenCL^(TM)^ C Specification
:R: pass:q,r[^(R)^]
Khronos{R} OpenCL Working Group
:data-uri:
:icons: font
:toc2:
:toclevels: 3
:max-width: 100%
:numbered:
:imagewidth: 800
:fullimagewidth: width="800"
:source-highlighter: rouge
:source-language: opencl_c
:rouge-style: opencl.spec
:sectnumoffset: 5
:docinfo: shared-header
:docinfodir: config
:title-logo-image: image:images/OpenCL.png[top="25%",width="55%"]
:description: OpenCL(TM) is an open, royalty-free standard for cross-platform \
parallel programming of diverse accelerators. \
This document describes the OpenCL C language.
// Various special / math symbols. This is easier to edit with than Unicode.
include::config/attribs.txt[]
// Attributes that are shared by OpenCL specifications.
include::config/opencl.asciidoc[]
// Formatting and links for API functions and enums.
include::c/dictionary.asciidoc[]
// Feature Dictionary
include::c/feature-dictionary.asciidoc[]
// External Footnotes
include::c/footnotes.asciidoc[]
<<<<
include::copyrights.txt[]
<<<
// :numbered:
:leveloffset: 1
[[the-opencl-c-programming-language]]
= The OpenCL C Programming Language
[NOTE]
====
This document starts at chapter 6 to keep the section numbers historically
consistent with previous versions of the OpenCL and OpenCL C Programming
Language specifications.
====
This section describes the OpenCL C programming language.
The OpenCL C programming language may be used to write kernels that execute
on an OpenCL device.
The OpenCL C programming language (also referred to as OpenCL C) is based
on the <<C99-spec,ISO/IEC 9899:1999 Programming languages - C>> specification
(also referred to as the C99 specification, or just C99), with extensions
and restrictions to support parallel kernels.
In addition, some features of OpenCL C are based on the <<C11-spec,ISO/IEC
9899:2011 Information technology - Programming languages - C>> specification
(also referred to as the C11 specification, or just C11).
This document describes the modifications and restrictions to C99 and C11
in OpenCL C.
Please refer to the C99 specification for a detailed description of the
language grammar.
[[unified-spec]]
== Unified Specification
This document specifies all versions of OpenCL C.
There are several ways that an OpenCL C feature may be described in terms of
what versions of OpenCL C specify that feature.
* Requires support for OpenCL C _major.minor_ or newer: Features that were
introduced in version _major.minor_.
Compilers for an earlier version of OpenCL C will not provide these
features.
** In some instances the variation of "For OpenCL C _major.minor_ or newer"
is used, it has the identical meaning.
* Requires support for OpenCL C 2.0, or OpenCL C 3.0 or newer and the
{opencl_c_feature_name} feature:
Features that were introduced in OpenCL C 2.0 as mandatory, but made
<<optional-functionality, optional>> in OpenCL C 3.0.
Compilers for versions of OpenCL C 1.2 or below will not provide these
features, compilers for OpenCL C 2.0 will provide these features,
compilers for OpenCL C 3.0 or newer may provide these features.
* Requires support for OpenCL C 3.0 or newer and the
{opencl_c_feature_name} feature: <<optional-functionality,
Optional>> features that were introduced in OpenCL C 3.0.
Compilers for an earlier version of OpenCL C will not provide these
features, compilers for OpenCL C 3.0 or newer may provide these features.
* Deprecated by OpenCL C _major.minor_: Features that were deprecated
in version _major.minor_, see the definition of deprecation in the
glossary of the main OpenCL specification.
* Universal: Features that have no mention of what version they are missing
before or deprecated by are specified for all versions of OpenCL C.
[[optional-functionality]]
== Optional functionality
Some language functionality is optional and will not be supported by all
devices. Such functionality is represented by optional language features or
language extensions. Support of optional functionality in OpenCL C is indicated
by the presence of special predefined macros.
[[features]]
=== Features
IMPORTANT: Feature test macros <<unified-spec, require>> support for OpenCL C
3.0 or newer.
Optional core language features are described in this document. They are
optional from OpenCL C 3.0 onwards and therefore are not supported by all
implementations. When an OpenCL C 3.0 optional feature is supported, an
associated __feature test macro__ will be predefined.
The following table describes OpenCL C 3.0 or newer features and their
meaning. The naming convention for the feature macros is
{opencl_c_feature_name}.
Feature macro identifiers are used as names of features in this document.
[[table-optional-lang-features]]
.Optional features in OpenCL C 3.0 or newer and their predefined macros.
[cols="1,1",options="header",]
|====
| Feature Macro/Name | Brief Description
| {opencl_c_3d_image_writes}
| The OpenCL C compiler supports built-in functions for writing to 3D image
objects.
OpenCL C compilers that define the feature macro {opencl_c_3d_image_writes}
must also define the feature macro {opencl_c_images}.
| {opencl_c_atomic_order_acq_rel}
| The OpenCL C compiler supports enumerations and built-in functions for atomic
operations with acquire and release memory consistency orders.
| {opencl_c_atomic_order_seq_cst}
| The OpenCL C compiler supports enumerations and built-in functions for atomic
operations and fences with sequentially consistent memory consistency order.
| {opencl_c_atomic_scope_device}
| The OpenCL C compiler supports enumerations and built-in functions for atomic
operations and fences with device memory scope.
| {opencl_c_atomic_scope_all_devices}
| The OpenCL C compiler supports enumerations and built-in functions for atomic
operations and fences with all with memory scope across all devices that can
share SVM memory with each other and the host process.
| {opencl_c_device_enqueue}
| The OpenCL C compiler supports built-in functions to enqueue additional work
from the device.
OpenCL C compilers that define the feature macro {opencl_c_device_enqueue} must also
define {opencl_c_generic_address_space} and {opencl_c_program_scope_global_variables}
feature macros.
| {opencl_c_generic_address_space}
| The OpenCL C compiler supports the unnamed generic address space.
| {opencl_c_fp64}
| The OpenCL C compiler supports types and built-in functions with 64-bit
floating-point types.
| {opencl_c_images}
| The OpenCL C compiler supports types and built-in functions for images.
| {opencl_c_int64}
| The OpenCL C compiler supports types and built-in functions with 64-bit
integers.
OpenCL C compilers for FULL profile devices or devices with 64-bit pointers
must always define the {opencl_c_int64} feature macro.
| {opencl_c_pipes}
| The OpenCL C compiler supports the pipe specifier and built-in functions
to read and write from a pipe.
OpenCL C compilers that define the feature macro {opencl_c_pipes} must
also define the feature macro {opencl_c_generic_address_space}.
| {opencl_c_program_scope_global_variables}
| The OpenCL C compiler supports program scope variables in the global address
space.
| {opencl_c_read_write_images}
| The OpenCL C compiler supports reading from and writing to the same image
object in a kernel.
OpenCL C compilers that define the feature macro
{opencl_c_read_write_images} must also define the feature macro
{opencl_c_images}.
| {opencl_c_subgroups}
| The OpenCL C compiler supports built-in functions operating on sub-groupings
of work-items.
| {opencl_c_work_group_collective_functions}
| The OpenCL C compiler supports built-in functions that perform collective
operations across a work-group.
ifdef::cl_khr_integer_dot_product[]
| {opencl_c_integer_dot_product_input_4x8bit_packed} +
(when the {cl_khr_integer_dot_product_EXT} extension macro is defined)
| The OpenCL C compiler supports built-in functions that perform dot
products on 4x8 bit packed integer vectors.
| {opencl_c_integer_dot_product_input_4x8bit} +
(when the {cl_khr_integer_dot_product_EXT} extension macro is defined)
| The OpenCL C compiler supports built-in functions that perform dot
products on 4x8 bit integer vectors.
endif::cl_khr_integer_dot_product[]
ifdef::cl_khr_kernel_clock[]
| {opencl_c_kernel_clock_scope_device}
| The OpenCL C compiler supports built-in functions that sample the value from a
clock shared by all work-items executing on the device.
| {opencl_c_kernel_clock_scope_work_group}
| The OpenCL C compiler supports built-in functions that sample the value from a
clock shared by all work-items executing in the same work-group.
| {opencl_c_kernel_clock_scope_sub_group}
| The OpenCL C compiler supports built-in functions that sample the value from a
clock shared by all work-items executing in the same sub-group.
endif::cl_khr_kernel_clock[]
ifdef::cl_ext_image_unorm_int_2_101010[]
| {opencl_c_ext_image_unorm_int_2_101010}
| The OpenCL C compiler supports `CLK_UNORM_INT_2_101010_EXT` and returning it
from `get_image_channel_data_type`.
endif::cl_ext_image_unorm_int_2_101010[]
|====
In OpenCL C 3.0 or newer, feature macros must expand to the value `1` if the
feature macro is defined by the OpenCL C compiler. A feature macro must not be
defined if the feature is not supported by the OpenCL C compiler. A feature
macro may expand to a different value in the future, but if this occurs the
value of the feature macro must compare greater than the prior value of the
feature macro.
As specified in <<C99-spec,section 7.1.3 of the C99 Specification>> double
underscore identifiers are reserved and therefore implementations
for earlier OpenCL C versions are allowed to define feature test macros
but they are not required to do so. This means that applications which
target earlier OpenCL C versions should not rely on the presence of
feature test macros because there is no guarantee that feature test macros
will be defined and that if defined they will indicate the presence of the
corresponding optional functionality.
[[extensions]]
=== Extensions
Other optional functionality may be described by language extensions to OpenCL
C. Extensions are described in the <<opencl-extension-spec,OpenCL Extension
Specification>>. When an OpenCL C extension is supported an associated
__extension macro__ will be predefined. Please refer to the OpenCL Extension
Specification for more information about predefined extension macros.
Prior to OpenCL C 3.0, support for some optional core language features was
indicated using predefined extension macros.
When an optional core language feature began as an extension it may have both an
associated feature macro and an associated extension macro. If an optional core
language feature was an optional extension to an earlier version of OpenCL C it
can still be used as an extension, i.e. the same predefined extension macros are
still valid in OpenCL C 3.0 or newer, however the use of feature macros is
preferred whenever possible.
ifdef::cl_khr_3d_image_writes[]
[[cl_khr_3d_image_writes,cl_khr_3d_image_writes]]
==== 3D Image Writes
The {cl_khr_3d_image_writes_EXT} extension was promoted to OpenCL 2.0, and to
OpenCL 3.0 as the {opencl_c_3d_image_writes} feature.
The extension adds <<built-in-image-write-functions, Built-in Image Write
Functions>> that allow a kernel to write to 3D image objects in addition to
2D image objects.
endif::cl_khr_3d_image_writes[]
ifdef::cl_khr_async_work_group_copy_fence[]
[[cl_khr_async_work_group_copy_fence,cl_khr_async_work_group_copy_fence]]
==== Async Work-group Copy Fence
The {cl_khr_async_work_group_copy_fence_EXT} extension supports establishing a
memory synchronization ordering of asynchronous copies.
The extension provides the `async_work_group_copy_fence` function, as
described in the <<table-builtin-async-copy, Built-in Async Copy and
Prefetch Functions>> table
endif::cl_khr_async_work_group_copy_fence[]
ifdef::cl_khr_byte_addressable_store[]
[[cl_khr_byte_addressable_store,cl_khr_byte_addressable_store]]
==== Byte-Addressable Storage
The {cl_khr_byte_addressable_store_EXT} extension was promoted to OpenCL C 1.1.
The extension relaxes <<restrictions>> on pointers to `char`, `uchar`,
`char2`, `uchar2`, `short`, `ushort` and `half`, allowing applications to
read from and write to pointers to these types.
endif::cl_khr_byte_addressable_store[]
ifdef::cl_khr_depth_images[]
[[cl_khr_depth_images,cl_khr_depth_images]]
==== Depth Images
The {cl_khr_depth_images_EXT} extension was promoted to OpenCL 2.0.
The extension provides new <<table-other-builtin-types, built-in depth image
types>>, as well as <<table-image-read, read functions>>,
<<table-image-samplerless-read, sampler-less read functions>>,
<<table-image-write, write functions>>, and <<table-image-query, image
queries>> operating on those types.
endif::cl_khr_depth_images[]
ifdef::cl_khr_device_enqueue_local_arg_types[]
[[cl_khr_device_enqueue_local_arg_types,cl_khr_device_enqueue_local_arg_types]]
==== Device Enqueue Local Argument Types
The {cl_khr_device_enqueue_local_arg_types_EXT} extension allows arguments to
blocks that are passed to the <<table-builtin-kernel-enqueue, Built-in
Kernel Enqueue Functions>> and to the <<table-builtin-kernel-query, Built-in
Kernel Query Functions>> to be pointers to any type (built-in or
user-defined) in local memory, instead of requiring arguments to blocks to
be pointers to `void` in local memory.
endif::cl_khr_device_enqueue_local_arg_types[]
ifdef::cl_khr_extended_async_copies[]
[[cl_khr_extended_async_copies,cl_khr_extended_async_copies]]
==== Extended Async Copy Functions
The {cl_khr_extended_async_copies_EXT} extension provides additional
<<extended-async-copies, Extended Async Copy Functions>> which interpret the
source and destination as 2D or 3D images.
endif::cl_khr_extended_async_copies[]
ifdef::cl_khr_extended_bit_ops[]
[[cl_khr_extended_bit_ops,cl_khr_extended_bit_ops]]
==== Extended Bit Operations
The {cl_khr_extended_bit_ops_EXT} extension provides additional
<<extended-bit-operations, Extended Bit Operations>> including bitfield
insert, bitfield extract, and bit reverse.
endif::cl_khr_extended_bit_ops[]
ifdef::cl_khr_fp16[]
[[cl_khr_fp16,cl_khr_fp16]]
==== Half-Precision Floating-Point
The {cl_khr_fp16_EXT} extension was promoted to OpenCL C 1.2 as an optional
feature, and to OpenCL 3.0 as the optional {cl_khr_fp16_EXT} feature.
The extension provides 16-bit precision scalar and vector floating-point
data types and extends many functions to accept these types.
endif::cl_khr_fp16[]
ifdef::cl_khr_fp64[]
[[cl_khr_fp64,cl_khr_fp64]]
==== Double-Precision Floating-Point
The {cl_khr_fp64_EXT} extension was promoted to OpenCL C 1.2 as an optional
feature, and to OpenCL 3.0 as the optional {cl_khr_fp64_EXT} feature.
The extension provides double-precision scalar and vector floating-point
data types and extends many functions to accept these types.
endif::cl_khr_fp64[]
ifdef::cl_khr_gl_msaa_sharing[]
[[cl_khr_gl_msaa_sharing,cl_khr_gl_msaa_sharing]]
==== Multi-Sample Shared OpenCL/OpenGL Images
The {cl_khr_gl_msaa_sharing_EXT} extension adds support for multi-sample images
shared with OpenGL multi-sample textures.
The extension provides new <<table-other-builtin-types, built-in multisample
image types>>, as well as <<table-image-samplerless-read, sampler-less read
functions>> and <<table-image-query, image queries>> operating on those
types.
endif::cl_khr_gl_msaa_sharing[]
ifdef::cl_khr_global_int32_base_atomics[]
[[cl_khr_global_int32_base_atomics,cl_khr_global_int32_base_atomics]]
==== Global 32-Bit Base Atomics
The {cl_khr_global_int32_base_atomics_EXT} extension was promoted to OpenCL C
1.1, with the supported functions renamed to use the **atomic_** prefix
rather than the **atom_** prefix.
The extension provides base atomic functions for {global} variables, as
described in the <<table-atomic-function-extensions, Atomic Function
Extensions>> table.
endif::cl_khr_global_int32_base_atomics[]
ifdef::cl_khr_global_int32_extended_atomics[]
[[cl_khr_global_int32_extended_atomics,cl_khr_global_int32_extended_atomics]]
==== Global 32-Bit Extended Atomics
The {cl_khr_global_int32_extended_atomics_EXT} extension was promoted to OpenCL
C 1.1, with the supported functions renamed to use the **atomic_** prefix
rather than the **atom_** prefix.
The extension provides extended atomic functions for {global} variables, as
described in the <<table-atomic-function-extensions, Atomic Function
Extensions>> table.
endif::cl_khr_global_int32_extended_atomics[]
ifdef::cl_khr_initialize_memory[]
[[cl_khr_initialize_memory,cl_khr_initialize_memory]]
==== Initializing Memory
The {cl_khr_initialize_memory_EXT} extension allows creating a context which
initializes specified types (local or private) of memory prior to the start
of kernel execution.
There is one <<restrictions-initialize-memory, restriction>> on the timing
of this initialization discussed in this document, although most of the
extension is defined by the OpenCL 3.0 API Specification.
endif::cl_khr_initialize_memory[]
ifdef::cl_khr_int64_base_atomics[]
[[cl_khr_int64_base_atomics,cl_khr_int64_base_atomics]]
==== 64-Bit Base Atomics
The {cl_khr_int64_base_atomics_EXT} extension provides base atomic functions for
{global} and {local} 64-bit signed and unsigned integer variables, as
described in the <<table-atomic-int64-base, Built-in 64-Bit Base Atomic
Functions>> table.
endif::cl_khr_int64_base_atomics[]
ifdef::cl_khr_int64_extended_atomics[]
[[cl_khr_int64_extended_atomics,cl_khr_int64_extended_atomics]]
==== 64-Bit Extended Atomics
The {cl_khr_int64_extended_atomics_EXT} extension provides extended atomic functions for
{global} and {local} 64-bit signed and unsigned integer variables, as
described in the <<table-atomic-int64-extended, Built-in 64-Bit Extended Atomic
Functions>> table.
endif::cl_khr_int64_extended_atomics[]
ifdef::cl_khr_integer_dot_product[]
[[cl_khr_integer_dot_product,cl_khr_integer_dot_product]]
==== Integer Dot Product
The {cl_khr_integer_dot_product_EXT} extension adds support for SPIR-V
instructions and OpenCL C built-in functions to compute the dot product of
vectors of integers.
The extension provides new <<table-builtin-functions, built-in vector
integer argument functions>> operating on these types.
endif::cl_khr_integer_dot_product[]
ifdef::cl_khr_kernel_clock[]
[[cl_khr_kernel_clock,cl_khr_kernel_clock]]
==== Kernel Clock
The `cl_khr_kernel_clock` extension adds support for SPIR-V instructions and
OpenCL C built-in functions to sample the value from one of three clocks
provided by compute units. The extension provides the following functions:
* <<table-kernel-clock-functions,Built-in Kernel Clock Functions>>
endif::cl_khr_kernel_clock[]
ifdef::cl_khr_local_int32_base_atomics[]
[[cl_khr_local_int32_base_atomics,cl_khr_local_int32_base_atomics]]
==== Local 32-Bit Base Atomics
The {cl_khr_local_int32_base_atomics_EXT} extension was promoted to OpenCL C
1.1, with the supported functions renamed to use the **atomic_** prefix
rather than the **atom_** prefix.
The extension provides base atomic functions for {local} variables, as
described in the <<table-atomic-function-extensions, Atomic Function
Extensions>> table.
endif::cl_khr_local_int32_base_atomics[]
ifdef::cl_khr_local_int32_extended_atomics[]
[[cl_khr_local_int32_extended_atomics,cl_khr_local_int32_extended_atomics]]
==== Local 32-Bit Extended Atomics
The {cl_khr_local_int32_extended_atomics_EXT} extension was promoted to OpenCL
C 1.1, with the supported functions renamed to use the **atomic_** prefix
rather than the **atom_** prefix.
The extension provides extended atomic functions for {local} variables, as
described in the <<table-atomic-function-extensions, Atomic Function
Extensions>> table.
endif::cl_khr_local_int32_extended_atomics[]
ifdef::cl_khr_mipmap_image[]
[[cl_khr_mipmap_image,cl_khr_mipmap_image]]
==== Mipmapped Image Reads and Queries
The {cl_khr_mipmap_image_EXT} extension adds support for mipmap images.
The extension provides built-in <<built-in-image-read-functions, image
read>> and <<built-in-image-query-functions, image query>> functions
operating on these images.
endif::cl_khr_mipmap_image[]
ifdef::cl_khr_mipmap_image_writes[]
[[cl_khr_mipmap_image_writes,cl_khr_mipmap_image_writes]]
==== Mipmapped Image Writes
The {cl_khr_mipmap_image_writes_EXT} extension adds support for writing to
mipmap images, and requires support for the {cl_khr_mipmap_image_EXT}
extension macro.
The extension provides built-in <<built-in-image-write-functions, image
write>> functions operating on these images.
endif::cl_khr_mipmap_image_writes[]
ifdef::cl_khr_select_fprounding_mode[]
[[cl_khr_select_fprounding_mode,cl_khr_select_fprounding_mode]]
==== Select Floating-Point Rounding Mode
The {cl_khr_select_fprounding_mode_EXT} extension allows <<select-rounding-mode,
specifying the floating-point rounding mode>> for an instruction or group of
instructions in the program source by use of a *#pragma*.
The extension was deprecated in OpenCL 1.1 and its use is not recommended.
endif::cl_khr_select_fprounding_mode[]
ifdef::cl_khr_srgb_image_writes[]
[[cl_khr_srgb_image_writes,cl_khr_srgb_image_writes]]
==== sRGB Image Write Functions
The {cl_khr_srgb_image_writes_EXT} extension adds support for writing to sRGB
images using the <<built-in-image-write-functions, *write_imagef*>>
functions. Color space conversion is performed by the function.
endif::cl_khr_srgb_image_writes[]
ifdef::cl_khr_subgroups[]
[[cl_khr_subgroups,cl_khr_subgroups]]
==== Sub-Groups
The {cl_khr_subgroups_EXT} extension was promoted to OpenCL C 2.1 as the
{opencl_c_subgroups} feature.
The extension provides the following functions:
* <<table-subgroup-work-item-functions, Built-in Work-Item Functions for
Sub-Groups>>
* <<table-synchronization-functions, Built-in Synchronization Functions
for Sub-Groups>>
* <<table-collective-functions, Built-in Collective Functions for
Sub-Groups>>
* <<table-pipe-functions, Built-in Pipe Functions for Sub-Groups>>
* <<table-kernel-query-functions, Built-in Kernel Query Functions for
Sub-Groups>>
* The <<table-memory-scopes, `memory_scope_sub_group`>> type and
<<atomic-restrictions, associated restrictions>>
endif::cl_khr_subgroups[]
ifdef::cl_khr_subgroup_ballot[]
[[cl_khr_subgroup_ballot,cl_khr_subgroup_ballot]]
==== Sub-Group Ballots
The {cl_khr_subgroup_ballot_EXT} extension adds the ability to collect and
operate on ballots from work items in a sub-group.
The extension provides the following functions:
* <<table-ballot-functions, Built-in Ballot Functions for Sub-Groups>>
endif::cl_khr_subgroup_ballot[]
ifdef::cl_khr_subgroup_clustered_reduce[]
[[cl_khr_subgroup_clustered_reduce,cl_khr_subgroup_clustered_reduce]]
==== Sub-Group Clustered Reductions
The {cl_khr_subgroup_clustered_reduce_EXT} extension adds support for clustered
reductions that operate on a subset of work items in the sub-group.
The extension provides the following functions:
* <<table-clustered-reduce-math-functions, Built-in Arithmetic Functions
for Sub-Groups>>
* <<table-clustered-reduce-bitwise-functions, Built-in Bitwise Functions
for Sub-Groups>>
* <<table-clustered-reduce-logical-functions, Built-in Logical Functions
for Sub-Groups>>
endif::cl_khr_subgroup_clustered_reduce[]
ifdef::cl_khr_subgroup_extended_types[]
[[cl_khr_subgroup_extended_types,cl_khr_subgroup_extended_types]]
==== Sub-Group Extended Types
The {cl_khr_subgroup_extended_types_EXT} extension adds <<sub-group-functions,
additional supported data types>> to the existing
<<table-collective-functions, sub-group broadcast, scan, and reduction
functions>>.
endif::cl_khr_subgroup_extended_types[]
ifdef::cl_khr_subgroup_non_uniform_arithmetic[]
[[cl_khr_subgroup_non_uniform_arithmetic,cl_khr_subgroup_non_uniform_arithmetic]]
==== Sub-Group Non-Uniform Arithmetic
The {cl_khr_subgroup_non_uniform_arithmetic_EXT} extension adds the ability to
use some sub-group functions within non-uniform flow control, including
additional scan and reduction operators.
The extension provides the following functions:
* <<table-non-uniform-math-functions, Built-in Non-Uniform Arithmetic
Functions for Sub-Groups>>
* <<table-non-uniform-bitwise-functions, Built-in Non-Uniform Bitwise
Functions for Sub-Groups>>
* <<table-non-uniform-logical-functions, Built-in Non-Uniform Logical
Functions for Sub-Groups>>
endif::cl_khr_subgroup_non_uniform_arithmetic[]
ifdef::cl_khr_subgroup_non_uniform_vote[]
[[cl_khr_subgroup_non_uniform_vote,cl_khr_subgroup_non_uniform_vote]]
==== Sub-Group Non-Uniform Vote and Election Functions
The {cl_khr_subgroup_non_uniform_vote_EXT} extension adds the ability to elect a
single work item from a sub-group to perform a task and to hold votes among
work items in a sub-group.
The extension provides the following functions:
* <<table-non-uniform-vote-functions, Built-in Non-Uniform Vote Functions
for Sub-Groups>>
endif::cl_khr_subgroup_non_uniform_vote[]
ifdef::cl_khr_subgroup_rotate[]
[[cl_khr_subgroup_rotate,cl_khr_subgroup_rotate]]
==== Sub-Group Rotation
The {cl_khr_subgroup_rotate_EXT} extension adds support for a new sub-group data
exchange operation that makes it possible to rotate values through the work
items in a sub-group.
The extension provides the following functions:
* <<table-rotate-functions, Built-in Rotation Functions for Sub-Groups>>
endif::cl_khr_subgroup_rotate[]
ifdef::cl_khr_subgroup_shuffle[]
[[cl_khr_subgroup_shuffle,cl_khr_subgroup_shuffle]]
==== Sub-Group General Purpose Shuffles
The {cl_khr_subgroup_shuffle_EXT} extension adds additional ways to exchange
data among work items in a sub-group.
The extension provides the following functions:
* <<table-shuffle-functions, Built-in Shuffle Functions for Sub-Groups>>
endif::cl_khr_subgroup_shuffle[]
ifdef::cl_khr_subgroup_shuffle_relative[]
[[cl_khr_subgroup_shuffle_relative,cl_khr_subgroup_shuffle_relative]]
==== Sub-Group Relative Shuffles
The {cl_khr_subgroup_shuffle_relative_EXT} extension adds specialized ways to
exchange data among work items in a sub-group that may perform better on
some implementations.
The extension provides the following functions:
* <<table-shuffle-relative-functions, Built-in Relative Shuffle Functions
for Sub-Groups>>
endif::cl_khr_subgroup_shuffle_relative[]
ifdef::cl_khr_work_group_uniform_arithmetic[]
[[cl_khr_work_group_uniform_arithmetic,cl_khr_work_group_uniform_arithmetic]]
==== Work-group Collective Uniform Arithmetic Functions
The {cl_khr_work_group_uniform_arithmetic_EXT} extension adds additional
work-group collective functions, including work-group scans and reductions
for the following operators:
* Logical operations (`and`, `or`, and `xor`).
* Bitwise operations (`and`, `or`, and `xor`).
* Integer multiplication (`mul`).
* Floating-point multiplication (`mul`).
The extension provides the following functions:
* <<table-builtin-work-group-logical, Built-in Work-group Logical
Arithmetic Functions>>
* <<table-builtin-work-group-bitwise-integer, Built-in Work-group Bitwise
Integer Functions>>
* <<table-builtin-work-group-multiplicative, Built-in Work-group
Multiplicative Functions>>
endif::cl_khr_work_group_uniform_arithmetic[]
[[supported-data-types]]
== Supported Data Types
The following data types are supported.
[[built-in-scalar-data-types]]
=== Built-in Scalar Data Types
[open,refpage='scalarDataTypes',desc='Built-in Scalar Data Types',type='freeform',spec='clang',anchor='built-in-scalar-data-types',xrefs='alignmentOfDataTypes halfDataType otherDataTypes reservedDataTypes vectorDataTypes']
--
The following table describes the list of built-in scalar data types.
[[table-builtin-scalar-types]]
.Built-in Scalar Data Types
[cols=",",options="header",]
|====
| Type | Description
| `bool` footnote:[{fn-bool}]
| A conditional data type which is either _true_ or _false_.
The value _true_ expands to the integer constant 1 and the value
_false_ expands to the integer constant 0.
| `char`
| A signed two's complement 8-bit integer.
| `unsigned char`, `uchar`
| An unsigned 8-bit integer.
| `short`
| A signed two's complement 16-bit integer.
| `unsigned short`, `ushort`
| An unsigned 16-bit integer.
| `int`
| A signed two's complement 32-bit integer.
| `unsigned int`, `uint`
| An unsigned 32-bit integer.
| `long` footnote:long[{fn-long}]
| A signed two's complement 64-bit integer.
| `unsigned long`, `ulong` footnote:long[]
| An unsigned 64-bit integer.
| `float`
| A 32-bit floating-point number.
The `float` data type must conform to the IEEE 754 single precision
storage format.
| `double` footnote:[{fn-double}]
| A 64-bit floating-point number.
The `double` data type must conform to the IEEE 754 double-precision
storage format.
<<unified-spec, Requires>> support for <<double-precision-support,
double-precision>>.
| `half`
| A 16-bit floating-point number.
The `half` data type must conform to the IEEE 754-2008 half-precision
storage format.
| `size_t` footnote:size_t[{fn-size_t}]
| The unsigned integer type of the result of the `sizeof` operator.
| `ptrdiff_t` footnote:size_t[]
| A signed integer type that is the result of subtracting two
pointers.
| `intptr_t` footnote:size_t[]
| A signed integer type with the property that any valid pointer to
`void` can be converted to this type, then converted back to pointer
to `void`, and the result will compare equal to the original pointer.
| `uintptr_t` footnote:size_t[]
| An unsigned integer type with the property that any valid pointer
to `void` can be converted to this type, then converted back to
pointer to `void`, and the result will compare equal to the original
pointer.
| `void`
| The `void` type comprises an empty set of values; it is an incomplete
type that cannot be completed.
|====
Most built-in scalar data types are also declared as appropriate types in
the OpenCL API (and header files) that can be used by an application.
The following table describes the built-in scalar data type in the OpenCL C
programming language and the corresponding data type available to the
application:
[cols=",",options="header",]
|====
| Type in OpenCL Language | API type for application
| `bool` | n/a
| `char` | `cl_char`
| `unsigned char`, `uchar` | `cl_uchar`
| `short` | `cl_short`
| `unsigned short`, `ushort` | `cl_ushort`
| `int` | `cl_int`
| `unsigned int`, `uint` | `cl_uint`
| `long` | `cl_long`
| `unsigned long`, `ulong` | `cl_ulong`
| `float` | `cl_float`
| `double` | `cl_double` footnote:[{fn-cl_double}]
| `half` | `cl_half`
| `size_t` | n/a
| `ptrdiff_t` | n/a
| `intptr_t` | n/a
| `uintptr_t` | n/a
| `void` | `void`
|====
--
[[double-precision-support]]
==== Double-Precision Floating-Point Support
Double-precision floating-point is supported if
ifdef::cl_khr_fp64[the {cl_khr_fp64_EXT} extension macro is supported, or if]
OpenCL 1.2 or newer is supported.
In OpenCL 3.0, it also requires support for the {opencl_c_fp64} feature,
If double-precision is not supported, implementations may
implicitly cast double-precision floating-point literals to
single-precision literals. The use of double-precision literals without
double-precision support should result in a diagnostic.
[[the-half-data-type]]
==== The `half` Data Type
[open,refpage='halfDataType',desc='The half Data Type',type='freeform',spec='clang',anchor='the-half-data-type',xrefs='alignmentOfDataTypes otherDataTypes reservedDataTypes scalarDataTypes vectorDataTypes']
--
The `half` data type must be IEEE 754-2008 compliant.
`half` numbers have 1 sign bit, 5 exponent bits, and 10 mantissa bits.
The interpretation of the sign, exponent and mantissa is analogous to IEEE
754 floating-point numbers.
The exponent bias is 15.
The `half` data type must represent finite and normal numbers, denormalized
numbers, infinities and NaN.
Denormalized numbers for the `half` data type which may be generated when
converting a `float` to a `half` using *vstore_half* and converting a `half`
to a `float` using *vload_half* cannot be flushed to zero.
Conversions from `float` to `half` correctly round the mantissa to 11 bits
of precision.
Conversions from `half` to `float` are lossless; all `half` numbers are
exactly representable as `float` values.
Conversions from `double` to `half` are correctly rounded.
Conversions from `half` to `double` are lossless.
The `half` data type can only be used to declare a pointer to a buffer that
contains `half` values.
A few valid examples are given below:
[source,opencl_c]
----------
void
bar (__global half *p)
{
...
}
__kernel void
foo (__global half *pg, __local half *pl)
{
__global half *ptr;
int offset;
ptr = pg + offset;
bar(ptr);
}
----------
Below are some examples that are not valid usage of the `half` type:
[source,opencl_c]
----------
half a;
half b[100];
half *p;
a = *p; // not allowed. must use *vload_half* function
----------
Loads from a pointer to a `half` and stores to a pointer to a `half` can be
performed using the <<vector-data-load-and-store-functions,vector data load
and store functions>> *vload_half*, *vload_half__n__*, *vloada_halfn* and
*vstore_half*, *vstore_half__n__*, and *vstorea_halfn*.
The load functions read scalar or vector `half` values from memory and
convert them to a scalar or vector `float` value.
The store functions take a scalar or vector `float` value as input, convert
it to a `half` scalar or vector value (with appropriate rounding mode) and
write the `half` scalar or vector value to memory.
--
[[built-in-vector-data-types]]
=== Built-in Vector Data Types
[open,refpage='vectorDataTypes',desc='Built-in Vector Data Types',type='freeform',spec='clang',anchor='built-in-vector-data-types',xrefs='alignmentOfDataTypes otherDataTypes reservedDataTypes scalarDataTypes']
--
The `char`, `unsigned char`, `short`, `unsigned short`, `int`, `unsigned int`,
`long`, `unsigned long`, `float` and `double` vector data types are supported.
footnote:[{fn-vector-types}]
The vector data type is defined with the type name, i.e. `char`, `uchar`,
`short`, `ushort`, `int`, `uint`, `long`, `ulong`, `float`, or `double`
followed by a literal value _n_ that defines the number of elements in the
vector.
Supported values of _n_ are 2, 3, 4, 8, and 16 for all vector data types.
NOTE: Vector types with three elements, i.e. where _n_ is 3, <<unified-spec,
require>> support for OpenCL C 1.1 or newer.
The following table describes the list of built-in vector data types.
[[table-builtin-vector-types]]
.Built-in Vector Data Types
[cols=",",options="header",]
|====
| Type | Description
| `char__n__`
| A vector of _n_ 8-bit signed two's complement integer values.
| `uchar__n__`
| A vector of _n_ 8-bit unsigned integer values.
| `short__n__`
| A vector of _n_ 16-bit signed two's complement integer values.
| `ushort__n__`
| A vector of _n_ 16-bit unsigned integer values.
| `int__n__`
| A vector of _n_ 32-bit signed two's complement integer values.
| `uint__n__`
| A vector of _n_ 32-bit unsigned integer values.
| `long__n__` footnote:long-vec[{fn-long-vec}]
| A vector of _n_ 64-bit signed two's complement integer values.
| `ulong__n__` footnote:long-vec[]
| A vector of _n_ 64-bit unsigned integer values.
ifdef::cl_khr_fp16[]
| `half__n__` footnote:[{fn-half-supported}]
| A vector of _n_ 16-bit floating-point values.
endif::cl_khr_fp16[]
| `float__n__`
| A vector of _n_ 32-bit floating-point values.
| `double__n__` footnote:[{fn-double-vec}]
| A vector of _n_ 64-bit floating-point values.
<<unified-spec, Requires>> support for <<double-precision-support,
double-precision>>.
|====
The built-in vector data types are also declared as appropriate types in the
OpenCL API (and header files) that can be used by an application.
The following table describes the built-in vector data type in the OpenCL C
programming language and the corresponding data type available to the
application:
[cols=",",options="header",]
|====
| Type in OpenCL Language | API type for application
| `char__n__` | `cl_char__n__`
| `uchar__n__` | `cl_uchar__n__`
| `short__n__` | `cl_short__n__`
| `ushort__n__` | `cl_ushort__n__`
| `int__n__` | `cl_int__n__`
| `uint__n__` | `cl_uint__n__`
| `long__n__` | `cl_long__n__`
| `ulong__n__` | `cl_ulong__n__`
ifdef::cl_khr_fp16[]
| `half__n__` | `cl_half__n__`
endif::cl_khr_fp16[]
| `float__n__` | `cl_float__n__`
| `double__n__` | `cl_double__n__`
|====