forked from KhronosGroup/OpenCL-Docs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
OpenCL_C.txt
12986 lines (10720 loc) · 494 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-2023 The Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
= 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%"]
// 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[]
// 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.
|====
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.
[[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=",",]
|====
| *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 OpenCL C 1.2 or newer. In
OpenCL C 3.0 it requires support of the {opencl_c_fp64} feature.
Also see extension *cl_khr_fp64*.
| `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.
|====
If the double-precision floating-point extension *cl_khr_fp64* or the
{opencl_c_fp64} feature 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.
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=",",]
|====
| *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`
|====
--
[[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.
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=",",]
|====
| *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.
| `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 OpenCL C 1.2 or newer. In
OpenCL C 3.0 it requires support of the {opencl_c_fp64} feature.
Also see extension *cl_khr_fp64*.
|====
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=",",]
|====
| *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__`
| `float__n__` | `cl_float__n__`
| `double__n__` | `cl_double__n__`
|====
--
[[other-built-in-data-types]]
=== Other Built-in Data Types
[open,refpage='otherDataTypes',desc='Other Built-in Data Types',type='freeform',spec='clang',anchor='other-built-in-data-types',xrefs='alignmentOfDataTypes reservedDataTypes scalarDataTypes vectorDataTypes']
--
The following table describes the list of additional data types supported by
OpenCL.
[[table-other-builtin-types]]
.Other Built-in Data Types
[cols=",",]
|====
| *Type* | *Description*
| `image2d_t` footnote:image-functions[{fn-image-functions}]
| A 2D image.
| `image3d_t` footnote:image-functions[]
| A 3D image.
| `image2d_array_t` footnote:image-functions[]
| A 2D image array.
<<unified-spec, Requires>> support for OpenCL C 1.2 or newer.
| `image1d_t` footnote:image-functions[]
| A 1D image.
<<unified-spec, Requires>> support for OpenCL C 1.2 or newer.
| `image1d_buffer_t` footnote:image-functions[]
| A 1D image created from a buffer object.
<<unified-spec, Requires>> support for OpenCL C 1.2 or newer.
| `image1d_array_t` footnote:image-functions[]
| A 1D image array.
<<unified-spec, Requires>> support for OpenCL C 1.2 or newer.
| `image2d_depth_t` footnote:image-functions[]
| A 2D depth image.
<<unified-spec, Requires>> support for OpenCL C 2.0 or newer, also see
`cl_khr_depth_images` extension.
| `image2d_array_depth_t` footnote:image-functions[]
| A 2D depth image array.
<<unified-spec, Requires>> support for OpenCL C 2.0 or newer, also see
`cl_khr_depth_images` extension.
| `sampler_t` footnote:image-functions[]
| A sampler type.
| `queue_t`
| A device command-queue.
This queue can only be used to enqueue commands from kernels executing
on the device.
<<unifed-spec, Requires>> support for OpenCL C 2.0, or OpenCL C 3.0 or
newer and the {opencl_c_device_enqueue} feature.
| `ndrange_t`
| The N-dimensional range over which a kernel executes.
<<unified-spec, Requires>> support for OpenCL C 2.0, or OpenCL C 3.0 or
newer and the {opencl_c_device_enqueue} feature.
| `clk_event_t`
| A device-side event that identifies a command enqueued to
a device command-queue.
<<unified-spec, Requires>> support for OpenCL C 2.0, or OpenCL C 3.0 or
newer and the {opencl_c_device_enqueue} feature.
| `reserve_id_t`
| A reservation ID.
This opaque type is used to identify the reservation for
<<pipe-functions,reading and writing a pipe>>.
<<unified-spec, Requires>> support for OpenCL C 2.0, or OpenCL C 3.0 or
newer and the {opencl_c_pipes} feature.
| `event_t`
| An event.
This can be used to identify <<async-copies,async copies>> from
`global` to `local` memory and vice-versa.
| `cl_mem_fence_flags`
| This is a bitfield and can be 0 or a combination of the following
values ORed together:
`CLK_GLOBAL_MEM_FENCE` +
`CLK_LOCAL_MEM_FENCE` +
`CLK_IMAGE_MEM_FENCE`
These flags are described in detail in the
<<synchronization-functions, synchronization functions>> section.
|====
[NOTE]
====
The `image2d_t`, `image3d_t`, `image2d_array_t`, `image1d_t`,
`image1d_buffer_t`, `image1d_array_t`, `image2d_depth_t`,
`image2d_array_depth_t` and `sampler_t` types are only defined if the device
supports images, i.e. the value of the <<opencl-device-queries,
`CL_DEVICE_IMAGE_SUPPORT` device query>>) is `CL_TRUE`.
If this is the case then an OpenCL C 3.0 or newer compiler must also define
the {opencl_c_images} feature macro.
====
The C99 derived types (arrays, structs, unions, functions, and pointers),
constructed from the built-in <<built-in-scalar-data-types,scalar>>,
<<built-in-vector-data-types,vector>>, and
<<other-built-in-data-types,other>> data types are supported, with specified
<<restrictions,restrictions>>.
The following tables describe the other built-in data types in OpenCL
described in <<table-other-builtin-types>> and the corresponding data type
available to the application:
[cols=",",]
|====
| *Type in OpenCL C* | *API type for application*
| `image2d_t` | `cl_mem`
| `image3d_t` | `cl_mem`
| `image2d_array_t` | `cl_mem`
| `image1d_t` | `cl_mem`
| `image1d_buffer_t` | `cl_mem`
| `image1d_array_t` | `cl_mem`
| `image2d_depth_t` | `cl_mem`
| `image2d_array_depth_t` | `cl_mem`
| `sampler_t` | `cl_sampler`
| `queue_t` | `cl_command_queue`
| `ndrange_t` | N/A
| `clk_event_t` | N/A
| `reserve_id_t` | N/A
| `event_t` | N/A
| `cl_mem_fence_flags` | N/A
|====
--
[[reserved-data-types]]
=== Reserved Data Types
[open,refpage='reservedDataTypes',desc='Reserved Data Types',type='freeform',spec='clang',anchor='reserved-data-types',xrefs='alignmentOfDataTypes otherDataTypes scalarDataTypes vectorDataTypes']
--
The data type names described in the following table are reserved and cannot
be used by applications as type names.
The vector data type names defined in <<table-builtin-vector-types>>, but
where _n_ is any value other than 2, 3, 4, 8 and 16, are also reserved.
[[table-reserved-types]]
.Reserved Data Types
[cols=",",]
|====
| *Type* | *Description*
| `bool__n__`
| A boolean vector.
| `half__n__`
| A 16-bit floating-point vector.
| `quad`, `quad__n__`
| A 128-bit floating-point scalar and vector.
| `complex half`, `complex half__n__`
| A complex 16-bit floating-point scalar and vector.
| `imaginary half`, `imaginary half__n__`
| An imaginary 16-bit floating-point scalar and vector.
| `complex float`, `complex float__n__`
| A complex 32-bit floating-point scalar and vector.
| `imaginary float`, `imaginary float__n__`
| An imaginary 32-bit floating-point scalar and vector.
| `complex double`, `complex double__n__`
| A complex 64-bit floating-point scalar and vector.
| `imaginary double`, `imaginary double__n__`
| An imaginary 64-bit floating-point scalar and vector.
| `complex quad`, `complex quad__n__`
| A complex 128-bit floating-point scalar and vector.
| `imaginary quad`, `imaginary quad__n__`
| An imaginary 128-bit floating-point scalar and vector.
| `float__n__x__m__`
| An _n_ {times} _m_ matrix of single precision floating-point values
stored in column-major order.
| `double__n__x__m__`
| An _n_ {times} _m_ matrix of double precision floating-point values
stored in column-major order.
| `long double`, `long double__n__`
| A floating-point scalar and vector type with at least as much
precision and range as a `double` and no more precision and range than
a quad.
| `long long, long long__n__`
| A 128-bit signed integer scalar and vector.
| `unsigned long long`,
`ulong long`,
`ulong long__n__`
| A 128-bit unsigned integer scalar and vector.
|====
--
[[alignment-of-types]]
=== Alignment of Types
[open,refpage='alignmentOfDataTypes',desc='Alignment of Data Types',type='freeform',spec='clang',anchor='alignment-of-types',xrefs='otherDataTypes reservedDataTypes scalarDataTypes vectorDataTypes']
--
A data item declared to be a data type in memory is always aligned to the
size of the data type in bytes.
For example, a `float4` variable will be aligned to a 16-byte boundary, a
`char2` variable will be aligned to a 2-byte boundary.
For 3-component vector data types, the size of the data type is `4 *
sizeof(component)`.
This means that a 3-component vector data type will be aligned to a `4 *
sizeof(component)` boundary.
The *vload3* and *vstore3* built-in functions can be used to read and write,
respectively, 3-component vector data types from an array of packed scalar
data type.
A built-in data type that is not a power of two bytes in size must be
aligned to the next larger power of two.
This rule applies to built-in types only, not structs or unions.
The OpenCL compiler is responsible for aligning data items to the
appropriate alignment as required by the data type.
For arguments to a `{kernel}` function declared to be a pointer to a data
type, the OpenCL compiler can assume that the pointee is always
appropriately aligned as required by the data type.
The behavior of an unaligned load or store is undefined, except for the
<<vector-data-load-and-store-functions,vector data load and store
functions>> *vload__n__*, *vload_half__n__*, *vstore__n__*, and
*vstore_half__n__*.
The vector load functions can read a vector from an address aligned to the
element type of the vector.
The vector store functions can write a vector to an address aligned to the
element type of the vector.
--
[[vector-literals]]
=== Vector Literals
Vector literals can be used to create vectors from a list of scalars,
vectors or a mixture thereof.
A vector literal can be used either as a vector initializer or as a primary
expression.
Whether a vector literal can be used as an l-value is implementation-defined.
A vector literal is written as a parenthesized vector type followed by a
parenthesized comma delimited list of parameters.
A vector literal operates as an overloaded function.
The forms of the function that are available is the set of possible argument
lists for which all arguments have the same element type as the result
vector, and the total number of elements is equal to the number of elements
in the result vector.
In addition, a form with a single scalar of the same type as the element
type of the vector is available.
For example, the following forms are available for `float4`:
[source,opencl_c]
----------
(float4)( float, float, float, float )
(float4)( float2, float, float )
(float4)( float, float2, float )
(float4)( float, float, float2 )
(float4)( float2, float2 )
(float4)( float3, float )
(float4)( float, float3 )
(float4)( float )
----------
Operands are evaluated by standard rules for function evaluation, except
that implicit scalar widening shall not occur.
The order in which the operands are evaluated is undefined.
The operands are assigned to their respective positions in the result vector
as they appear in memory order.
That is, the first element of the first operand is assigned to `result.x`,
the second element of the first operand (or the first element of the second
operand if the first operand was a scalar) is assigned to `result.y`, etc.
In the case of the form that has a single scalar operand, the operand is
replicated across all lanes of the vector.
Examples:
[source,opencl_c]
----------
float4 f = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
uint4 u = (uint4)(1); // u will be (1, 1, 1, 1).
float4 f = (float4)((float2)(1.0f, 2.0f), (float2)(3.0f, 4.0f));
float4 f = (float4)(1.0f, (float2)(2.0f, 3.0f), 4.0f);
float4 f = (float4)(1.0f, 2.0f); // error
----------
[[vector-components]]
=== Vector Components
The components of vector data types can be addressed as
`<vector_data_type>.xyzw`.
Vector data types with two or more components, such as `char2`, can access `.xy` elements.
Vector data types with three or more components, such as `uint3`, can access `.xyz` elements.
Vector data types with four or more components, such as `ulong4` or `float8`, can access `.xyzw` elements.
In OpenCL C 3.0, the components of vector data types can also be addressed as
`<vector_data_type>.rgba`.
Vector data types with two or more components can access `.rg` elements.
Vector data types with three or more components can access `.rgb` elements.
Vector data types with four or more components can access `.rgba` elements.
Accessing components beyond those declared for the vector type is an error
so, for example:
[source,opencl_c]
----------
float2 coord;
coord.x = 1.0f; // is legal
coord.r = 1.0f; // is legal in OpenCL C 3.0
coord.z = 1.0f; // is illegal, since coord only has two components
float3 pos;
pos.z = 1.0f; // is legal
pos.b = 1.0f; // is legal in OpenCL C 3.0
pos.w = 1.0f; // is illegal, since pos only has three components
----------
The component selection syntax allows multiple components to be selected by
appending their names after the period (*.*).
[source,opencl_c]
----------
float4 c;
c.xyzw = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
c.z = 1.0f;
c.xy = (float2)(3.0f, 4.0f);
c.xyz = (float3)(3.0f, 4.0f, 5.0f);
----------
The component selection syntax also allows components to be permuted or
replicated.
[source,opencl_c]
----------
float4 pos = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
float4 swiz= pos.wzyx; // swiz = (4.0f, 3.0f, 2.0f, 1.0f)
float4 dup = pos.xxyy; // dup = (1.0f, 1.0f, 2.0f, 2.0f)
----------
The component group notation can occur on the left hand side of an
expression.
To form an l-value, swizzling must be applied to an l-value of vector type,
contain no duplicate components, and it results in an l-value of scalar or
vector type, depending on number of components specified.
Each component must be a supported scalar or vector type.
[source,opencl_c]
----------
float4 pos = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
pos.xw = (float2)(5.0f, 6.0f);// pos = (5.0f, 2.0f, 3.0f, 6.0f)
pos.wx = (float2)(7.0f, 8.0f);// pos = (8.0f, 2.0f, 3.0f, 7.0f)
pos.xyz = (float3)(3.0f, 5.0f, 9.0f); // pos = (3.0f, 5.0f, 9.0f, 4.0f)
pos.xx = (float2)(3.0f, 4.0f);// illegal - 'x' used twice
// illegal - mismatch between float2 and float4
pos.xy = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
float4 a, b, c, d;
float16 x;
x = (float16)(a, b, c, d);
x = (float16)(a.xxxx, b.xyz, c.xyz, d.xyz, a.yzw);
// illegal - component a.xxxxxxx is not a valid vector type
x = (float16)(a.xxxxxxx, b.xyz, c.xyz, d.xyz);
----------
Elements of vector data types can also be accessed using a numeric index to
refer to the appropriate element in the vector.
The numeric indices that can be used are given in the table below:
[[table-vector-indices]]
.Numeric indices for built-in vector data types
[width="100%",cols="<34%,<66%",options="header"]
|====
| *Vector Components* | *Numeric indices that can be used*
| 2-component | 0, 1
| 3-component | 0, 1, 2
| 4-component | 0, 1, 2, 3
| 8-component | 0, 1, 2, 3, 4, 5, 6, 7
| 16-component | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
a, A, b, B, c, C, d, D, e, E, f, F
|====
The numeric indices must be preceded by the letter `s` or `S`.
In the following example
[source,opencl_c]
----------
float8 f;
----------
`f.s0` refers to the 1^st^ element of the `float8` variable `f` and `f.s7`
refers to the 8^th^ element of the `float8` variable `f`.
In the following example
[source,opencl_c]
----------
float16 x;
----------
`x.sa` (or `x.sA`) refers to the 11^th^ element of the `float16` variable
`x` and `x.sf` (or `x.sF`) refers to the 16^th^ element of the `float16`
variable `x`.
The numeric indices used to refer to an appropriate element in the vector
cannot be intermixed with `.xyzw` notation used to access elements of a 1 ..
4 component vector.
For example
[source,opencl_c]
----------
float4 f, a;
a = f.x12w; // illegal use of numeric indices with .xyzw
a.xyzw = f.s0123; // valid
----------
Vector data types can use the `.lo` (or `.even`) and `.hi` (or `.odd`)
suffixes to get smaller vector types or to combine smaller vector types to a
larger vector type.
Multiple levels of `.lo` (or `.even`) and `.hi` (or `.odd`) suffixes can be
used until they refer to a scalar term.
The `.lo` suffix refers to the lower half of a given vector.
The `.hi` suffix refers to the upper half of a given vector.
The `.even` suffix refers to the even elements of a vector.
The `.odd` suffix refers to the odd elements of a vector.
Some examples to help illustrate this are given below:
[source,opencl_c]
----------
float4 vf;
float2 low = vf.lo; // returns vf.xy
float2 high = vf.hi; // returns vf.zw
float2 even = vf.even; // returns vf.xz
float2 odd = vf.odd; // returns vf.yw
----------
The suffixes `.lo` (or `.even`) and `.hi` (or `.odd`) for a 3-component
vector type operate as if the 3-component vector type is a 4-component
vector type with the value in the `w` component undefined.
Some examples are given below:
[source,opencl_c]
----------
float8 vf;
float4 odd = vf.odd;
float4 even = vf.even;
float2 high = vf.even.hi;
float2 low = vf.odd.lo;
// interleave LR stereo stream
float4 left, right;
float8 interleaved;
interleaved.even = left;
interleaved.odd = right;
// deinterleave
left = interleaved.even;
right = interleaved.odd;
// transpose a 4x4 matrix
void transpose( float4 m[4] )
{
// read matrix into a float16 vector
float16 x = (float16)( m[0], m[1], m[2], m[3] );
float16 t;
// transpose
t.even = x.lo;
t.odd = x.hi;
x.even = t.lo;
x.odd = t.hi;
// write back
m[0] = x.lo.lo; // { m[0][0], m[1][0], m[2][0], m[3][0] }
m[1] = x.lo.hi; // { m[0][1], m[1][1], m[2][1], m[3][1] }
m[2] = x.hi.lo; // { m[0][2], m[1][2], m[2][2], m[3][2] }
m[3] = x.hi.hi; // { m[0][3], m[1][3], m[2][3], m[3][3] }
}
float3 vf = (float3)(1.0f, 2.0f, 3.0f);
float2 low = vf.lo; // (1.0f, 2.0f);
float2 high = vf.hi; // (3.0f, _undefined_);
----------
It is illegal to take the address of a vector element and will result in a
compilation error.
For example: