specs/3.0-unified/html/OpenCL_API.html - external/github.com/KhronosGroup/OpenCL-Registry - Git at Google

 <!DOCTYPE html>
 <html lang="en">
 <head>
 <meta charset="UTF-8">
 <!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta name="generator" content="Asciidoctor 1.5.8">
 <meta name="author" content="Khronos&#174; OpenCL Working Group">
 <title>The OpenCL&#8482; Specification</title>
 <style>
 /*! normalize.css v2.1.2 | MIT License | git.io/normalize */
 /* ========================================================================== HTML5 display definitions ========================================================================== */
 /** Correct `block` display not defined in IE 8/9. */
 article, aside, details, figcaption, figure, footer, header, hgroup, main, nav, section, summary { display: block; }

 /** Correct `inline-block` display not defined in IE 8/9. */
 audio, canvas, video { display: inline-block; }

 /** Prevent modern browsers from displaying `audio` without controls. Remove excess height in iOS 5 devices. */
 audio:not([controls]) { display: none; height: 0; }

 /** Address `[hidden]` styling not present in IE 8/9. Hide the `template` element in IE, Safari, and Firefox < 22. */
 [hidden], template { display: none; }

 script { display: none !important; }

 /* ========================================================================== Base ========================================================================== */
 /** 1. Set default font family to sans-serif. 2. Prevent iOS text size adjust after orientation change, without disabling user zoom. */
 html { font-family: sans-serif; /* 1 */ -ms-text-size-adjust: 100%; /* 2 */ -webkit-text-size-adjust: 100%; /* 2 */ }

 /** Remove default margin. */
 body { margin: 0; }

 /* ========================================================================== Links ========================================================================== */
 /** Remove the gray background color from active links in IE 10. */
 a { background: transparent; }

 /** Address `outline` inconsistency between Chrome and other browsers. */
 a:focus { outline: thin dotted; }

 /** Improve readability when focused and also mouse hovered in all browsers. */
 a:active, a:hover { outline: 0; }

 /* ========================================================================== Typography ========================================================================== */
 /** Address variable `h1` font-size and margin within `section` and `article` contexts in Firefox 4+, Safari 5, and Chrome. */
 h1 { font-size: 2em; margin: 0.67em 0; }

 /** Address styling not present in IE 8/9, Safari 5, and Chrome. */
 abbr[title] { border-bottom: 1px dotted; }

 /** Address style set to `bolder` in Firefox 4+, Safari 5, and Chrome. */
 b, strong { font-weight: bold; }

 /** Address styling not present in Safari 5 and Chrome. */
 dfn { font-style: italic; }

 /** Address differences between Firefox and other browsers. */
 hr { -moz-box-sizing: content-box; box-sizing: content-box; height: 0; }

 /** Address styling not present in IE 8/9. */
 mark { background: #ff0; color: #000; }

 /** Correct font family set oddly in Safari 5 and Chrome. */
 code, kbd, pre, samp { font-family: monospace, serif; font-size: 1em; }

 /** Improve readability of pre-formatted text in all browsers. */
 pre { white-space: pre-wrap; }

 /** Set consistent quote types. */
 q { quotes: "\201C" "\201D" "\2018" "\2019"; }

 /** Address inconsistent and variable font size in all browsers. */
 small { font-size: 80%; }

 /** Prevent `sub` and `sup` affecting `line-height` in all browsers. */
 sub, sup { font-size: 75%; line-height: 0; position: relative; vertical-align: baseline; }

 sup { top: -0.5em; }

 sub { bottom: -0.25em; }

 /* ========================================================================== Embedded content ========================================================================== */
 /** Remove border when inside `a` element in IE 8/9. */
 img { border: 0; }

 /** Correct overflow displayed oddly in IE 9. */
 svg:not(:root) { overflow: hidden; }

 /* ========================================================================== Figures ========================================================================== */
 /** Address margin not present in IE 8/9 and Safari 5. */
 figure { margin: 0; }

 /* ========================================================================== Forms ========================================================================== */
 /** Define consistent border, margin, and padding. */
 fieldset { border: 1px solid #c0c0c0; margin: 0 2px; padding: 0.35em 0.625em 0.75em; }

 /** 1. Correct `color` not being inherited in IE 8/9. 2. Remove padding so people aren't caught out if they zero out fieldsets. */
 legend { border: 0; /* 1 */ padding: 0; /* 2 */ }

 /** 1. Correct font family not being inherited in all browsers. 2. Correct font size not being inherited in all browsers. 3. Address margins set differently in Firefox 4+, Safari 5, and Chrome. */
 button, input, select, textarea { font-family: inherit; /* 1 */ font-size: 100%; /* 2 */ margin: 0; /* 3 */ }

 /** Address Firefox 4+ setting `line-height` on `input` using `!important` in the UA stylesheet. */
 button, input { line-height: normal; }

 /** Address inconsistent `text-transform` inheritance for `button` and `select`. All other form control elements do not inherit `text-transform` values. Correct `button` style inheritance in Chrome, Safari 5+, and IE 8+. Correct `select` style inheritance in Firefox 4+ and Opera. */
 button, select { text-transform: none; }

 /** 1. Avoid the WebKit bug in Android 4.0.* where (2) destroys native `audio` and `video` controls. 2. Correct inability to style clickable `input` types in iOS. 3. Improve usability and consistency of cursor style between image-type `input` and others. */
 button, html input[type="button"], input[type="reset"], input[type="submit"] { -webkit-appearance: button; /* 2 */ cursor: pointer; /* 3 */ }

 /** Re-set default cursor for disabled elements. */
 button[disabled], html input[disabled] { cursor: default; }

 /** 1. Address box sizing set to `content-box` in IE 8/9. 2. Remove excess padding in IE 8/9. */
 input[type="checkbox"], input[type="radio"] { box-sizing: border-box; /* 1 */ padding: 0; /* 2 */ }

 /** 1. Address `appearance` set to `searchfield` in Safari 5 and Chrome. 2. Address `box-sizing` set to `border-box` in Safari 5 and Chrome (include `-moz` to future-proof). */
 input[type="search"] { -webkit-appearance: textfield; /* 1 */ -moz-box-sizing: content-box; -webkit-box-sizing: content-box; /* 2 */ box-sizing: content-box; }

 /** Remove inner padding and search cancel button in Safari 5 and Chrome on OS X. */
 input[type="search"]::-webkit-search-cancel-button, input[type="search"]::-webkit-search-decoration { -webkit-appearance: none; }

 /** Remove inner padding and border in Firefox 4+. */
 button::-moz-focus-inner, input::-moz-focus-inner { border: 0; padding: 0; }

 /** 1. Remove default vertical scrollbar in IE 8/9. 2. Improve readability and alignment in all browsers. */
 textarea { overflow: auto; /* 1 */ vertical-align: top; /* 2 */ }

 /* ========================================================================== Tables ========================================================================== */
 /** Remove most spacing between table cells. */
 table { border-collapse: collapse; border-spacing: 0; }

 meta.foundation-mq-small { font-family: "only screen and (min-width: 768px)"; width: 768px; }

 meta.foundation-mq-medium { font-family: "only screen and (min-width:1280px)"; width: 1280px; }

 meta.foundation-mq-large { font-family: "only screen and (min-width:1440px)"; width: 1440px; }

 *, *:before, *:after { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

 html, body { font-size: 100%; }

 body { background: white; color: #222222; padding: 0; margin: 0; font-family: "Helvetica Neue", "Helvetica", Helvetica, Arial, sans-serif; font-weight: normal; font-style: normal; line-height: 1; position: relative; cursor: auto; }

 a:hover { cursor: pointer; }

 img, object, embed { max-width: 100%; height: auto; }

 object, embed { height: 100%; }

 img { -ms-interpolation-mode: bicubic; }

 #map_canvas img, #map_canvas embed, #map_canvas object, .map_canvas img, .map_canvas embed, .map_canvas object { max-width: none !important; }

 .left { float: left !important; }

 .right { float: right !important; }

 .text-left { text-align: left !important; }

 .text-right { text-align: right !important; }

 .text-center { text-align: center !important; }

 .text-justify { text-align: justify !important; }

 .hide { display: none; }

 .antialiased { -webkit-font-smoothing: antialiased; }

 img { display: inline-block; vertical-align: middle; }

 textarea { height: auto; min-height: 50px; }

 select { width: 100%; }

 object, svg { display: inline-block; vertical-align: middle; }

 .center { margin-left: auto; margin-right: auto; }

 .spread { width: 100%; }

 p.lead, .paragraph.lead > p, #preamble > .sectionbody > .paragraph:first-of-type p { font-size: 1.21875em; line-height: 1.6; }

 .subheader, .admonitionblock td.content > .title, .audioblock > .title, .exampleblock > .title, .imageblock > .title, .listingblock > .title, .literalblock > .title, .stemblock > .title, .openblock > .title, .paragraph > .title, .quoteblock > .title, table.tableblock > .title, .verseblock > .title, .videoblock > .title, .dlist > .title, .olist > .title, .ulist > .title, .qlist > .title, .hdlist > .title { line-height: 1.4; color: black; font-weight: 300; margin-top: 0.2em; margin-bottom: 0.5em; }

 /* Typography resets */
 div, dl, dt, dd, ul, ol, li, h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6, pre, form, p, blockquote, th, td { margin: 0; padding: 0; direction: ltr; }

 /* Default Link Styles */
 a { color: #0068b0; text-decoration: none; line-height: inherit; }
 a:hover, a:focus { color: #333333; }
 a img { border: none; }

 /* Default paragraph styles */
 p { font-family: Noto, sans-serif; font-weight: normal; font-size: 1em; line-height: 1.6; margin-bottom: 0.75em; text-rendering: optimizeLegibility; }
 p aside { font-size: 0.875em; line-height: 1.35; font-style: italic; }

 /* Default header styles */
 h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { font-family: Noto, sans-serif; font-weight: normal; font-style: normal; color: black; text-rendering: optimizeLegibility; margin-top: 0.5em; margin-bottom: 0.5em; line-height: 1.2125em; }
 h1 small, h2 small, h3 small, #toctitle small, .sidebarblock > .content > .title small, h4 small, h5 small, h6 small { font-size: 60%; color: #4d4d4d; line-height: 0; }

 h1 { font-size: 2.125em; }

 h2 { font-size: 1.6875em; }

 h3, #toctitle, .sidebarblock > .content > .title { font-size: 1.375em; }

 h4 { font-size: 1.125em; }

 h5 { font-size: 1.125em; }

 h6 { font-size: 1em; }

 hr { border: solid #dddddd; border-width: 1px 0 0; clear: both; margin: 1.25em 0 1.1875em; height: 0; }

 /* Helpful Typography Defaults */
 em, i { font-style: italic; line-height: inherit; }

 strong, b { font-weight: bold; line-height: inherit; }

 small { font-size: 60%; line-height: inherit; }

 code { font-family: Consolas, "Liberation Mono", Courier, monospace; font-weight: normal; color: #264357; }

 /* Lists */
 ul, ol, dl { font-size: 1em; line-height: 1.6; margin-bottom: 0.75em; list-style-position: outside; font-family: Noto, sans-serif; }

 ul, ol { margin-left: 1.5em; }
 ul.no-bullet, ol.no-bullet { margin-left: 1.5em; }

 /* Unordered Lists */
 ul li ul, ul li ol { margin-left: 1.25em; margin-bottom: 0; font-size: 1em; /* Override nested font-size change */ }
 ul.square li ul, ul.circle li ul, ul.disc li ul { list-style: inherit; }
 ul.square { list-style-type: square; }
 ul.circle { list-style-type: circle; }
 ul.disc { list-style-type: disc; }
 ul.no-bullet { list-style: none; }

 /* Ordered Lists */
 ol li ul, ol li ol { margin-left: 1.25em; margin-bottom: 0; }

 /* Definition Lists */
 dl dt { margin-bottom: 0.3em; font-weight: bold; }
 dl dd { margin-bottom: 0.75em; }

 /* Abbreviations */
 abbr, acronym { text-transform: uppercase; font-size: 90%; color: black; border-bottom: 1px dotted #dddddd; cursor: help; }

 abbr { text-transform: none; }

 /* Blockquotes */
 blockquote { margin: 0 0 0.75em; padding: 0.5625em 1.25em 0 1.1875em; border-left: 1px solid #dddddd; }
 blockquote cite { display: block; font-size: 0.8125em; color: #5e93b8; }
 blockquote cite:before { content: "\2014 \0020"; }
 blockquote cite a, blockquote cite a:visited { color: #5e93b8; }

 blockquote, blockquote p { line-height: 1.6; color: #333333; }

 /* Microformats */
 .vcard { display: inline-block; margin: 0 0 1.25em 0; border: 1px solid #dddddd; padding: 0.625em 0.75em; }
 .vcard li { margin: 0; display: block; }
 .vcard .fn { font-weight: bold; font-size: 0.9375em; }

 .vevent .summary { font-weight: bold; }
 .vevent abbr { cursor: auto; text-decoration: none; font-weight: bold; border: none; padding: 0 0.0625em; }

 @media only screen and (min-width: 768px) { h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { line-height: 1.4; }
   h1 { font-size: 2.75em; }
   h2 { font-size: 2.3125em; }
   h3, #toctitle, .sidebarblock > .content > .title { font-size: 1.6875em; }
   h4 { font-size: 1.4375em; } }
 /* Tables */
 table { background: white; margin-bottom: 1.25em; border: solid 1px #d8d8ce; }
 table thead, table tfoot { background: -webkit-linear-gradient(top, #add386, #90b66a); font-weight: bold; }
 table thead tr th, table thead tr td, table tfoot tr th, table tfoot tr td { padding: 0.5em 0.625em 0.625em; font-size: inherit; color: white; text-align: left; }
 table tr th, table tr td { padding: 0.5625em 0.625em; font-size: inherit; color: #6d6e71; }
 table tr.even, table tr.alt, table tr:nth-of-type(even) { background: #edf2f2; }
 table thead tr th, table tfoot tr th, table tbody tr td, table tr td, table tfoot tr td { display: table-cell; line-height: 1.4; }

 body { -moz-osx-font-smoothing: grayscale; -webkit-font-smoothing: antialiased; tab-size: 4; }

 h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { line-height: 1.4; }

 a:hover, a:focus { text-decoration: underline; }

 .clearfix:before, .clearfix:after, .float-group:before, .float-group:after { content: " "; display: table; }
 .clearfix:after, .float-group:after { clear: both; }

 *:not(pre) > code { font-size: inherit; font-style: normal !important; letter-spacing: 0; padding: 0; background-color: white; -webkit-border-radius: 0; border-radius: 0; line-height: inherit; word-wrap: break-word; }
 *:not(pre) > code.nobreak { word-wrap: normal; }
 *:not(pre) > code.nowrap { white-space: nowrap; }

 pre, pre > code { line-height: 1.6; color: #264357; font-family: Consolas, "Liberation Mono", Courier, monospace; font-weight: normal; }

 em em { font-style: normal; }

 strong strong { font-weight: normal; }

 .keyseq { color: #333333; }

 kbd { font-family: Consolas, "Liberation Mono", Courier, monospace; display: inline-block; color: black; font-size: 0.65em; line-height: 1.45; background-color: #f7f7f7; border: 1px solid #ccc; -webkit-border-radius: 3px; border-radius: 3px; -webkit-box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 0.1em white inset; box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 0.1em white inset; margin: 0 0.15em; padding: 0.2em 0.5em; vertical-align: middle; position: relative; top: -0.1em; white-space: nowrap; }

 .keyseq kbd:first-child { margin-left: 0; }

 .keyseq kbd:last-child { margin-right: 0; }

 .menuseq, .menuref { color: #000; }

 .menuseq b:not(.caret), .menuref { font-weight: inherit; }

 .menuseq { word-spacing: -0.02em; }
 .menuseq b.caret { font-size: 1.25em; line-height: 0.8; }
 .menuseq i.caret { font-weight: bold; text-align: center; width: 0.45em; }

 b.button:before, b.button:after { position: relative; top: -1px; font-weight: normal; }

 b.button:before { content: "["; padding: 0 3px 0 2px; }

 b.button:after { content: "]"; padding: 0 2px 0 3px; }

 #header, #content, #footnotes, #footer { width: 100%; margin-left: auto; margin-right: auto; margin-top: 0; margin-bottom: 0; max-width: 62.5em; *zoom: 1; position: relative; padding-left: 1.5em; padding-right: 1.5em; }
 #header:before, #header:after, #content:before, #content:after, #footnotes:before, #footnotes:after, #footer:before, #footer:after { content: " "; display: table; }
 #header:after, #content:after, #footnotes:after, #footer:after { clear: both; }

 #content { margin-top: 1.25em; }

 #content:before { content: none; }

 #header > h1:first-child { color: black; margin-top: 2.25rem; margin-bottom: 0; }
 #header > h1:first-child + #toc { margin-top: 8px; border-top: 1px solid #dddddd; }
 #header > h1:only-child, body.toc2 #header > h1:nth-last-child(2) { border-bottom: 1px solid #dddddd; padding-bottom: 8px; }
 #header .details { border-bottom: 1px solid #dddddd; line-height: 1.45; padding-top: 0.25em; padding-bottom: 0.25em; padding-left: 0.25em; color: #5e93b8; display: -ms-flexbox; display: -webkit-flex; display: flex; -ms-flex-flow: row wrap; -webkit-flex-flow: row wrap; flex-flow: row wrap; }
 #header .details span:first-child { margin-left: -0.125em; }
 #header .details span.email a { color: #333333; }
 #header .details br { display: none; }
 #header .details br + span:before { content: "\00a0\2013\00a0"; }
 #header .details br + span.author:before { content: "\00a0\22c5\00a0"; color: #333333; }
 #header .details br + span#revremark:before { content: "\00a0|\00a0"; }
 #header #revnumber { text-transform: capitalize; }
 #header #revnumber:after { content: "\00a0"; }

 #content > h1:first-child:not([class]) { color: black; border-bottom: 1px solid #dddddd; padding-bottom: 8px; margin-top: 0; padding-top: 1rem; margin-bottom: 1.25rem; }

 #toc { border-bottom: 0 solid #dddddd; padding-bottom: 0.5em; }
 #toc > ul { margin-left: 0.125em; }
 #toc ul.sectlevel0 > li > a { font-style: italic; }
 #toc ul.sectlevel0 ul.sectlevel1 { margin: 0.5em 0; }
 #toc ul { font-family: Noto, sans-serif; list-style-type: none; }
 #toc li { line-height: 1.3334; margin-top: 0.3334em; }
 #toc a { text-decoration: none; }
 #toc a:active { text-decoration: underline; }

 #toctitle { color: black; font-size: 1.2em; }

 @media only screen and (min-width: 768px) { #toctitle { font-size: 1.375em; }
   body.toc2 { padding-left: 15em; padding-right: 0; }
   #toc.toc2 { margin-top: 0 !important; background-color: white; position: fixed; width: 15em; left: 0; top: 0; border-right: 1px solid #dddddd; border-top-width: 0 !important; border-bottom-width: 0 !important; z-index: 1000; padding: 1.25em 1em; height: 100%; overflow: auto; }
   #toc.toc2 #toctitle { margin-top: 0; margin-bottom: 0.8rem; font-size: 1.2em; }
   #toc.toc2 > ul { font-size: 0.9em; margin-bottom: 0; }
   #toc.toc2 ul ul { margin-left: 0; padding-left: 1em; }
   #toc.toc2 ul.sectlevel0 ul.sectlevel1 { padding-left: 0; margin-top: 0.5em; margin-bottom: 0.5em; }
   body.toc2.toc-right { padding-left: 0; padding-right: 15em; }
   body.toc2.toc-right #toc.toc2 { border-right-width: 0; border-left: 1px solid #dddddd; left: auto; right: 0; } }
 @media only screen and (min-width: 1280px) { body.toc2 { padding-left: 20em; padding-right: 0; }
   #toc.toc2 { width: 20em; }
   #toc.toc2 #toctitle { font-size: 1.375em; }
   #toc.toc2 > ul { font-size: 0.95em; }
   #toc.toc2 ul ul { padding-left: 1.25em; }
   body.toc2.toc-right { padding-left: 0; padding-right: 20em; } }
 #content #toc { border-style: solid; border-width: 1px; border-color: #e6e6e6; margin-bottom: 1.25em; padding: 1.25em; background: white; -webkit-border-radius: 0; border-radius: 0; }
 #content #toc > :first-child { margin-top: 0; }
 #content #toc > :last-child { margin-bottom: 0; }

 #footer { max-width: 100%; background-color: none; padding: 1.25em; }

 #footer-text { color: black; line-height: 1.44; }

 #content { margin-bottom: 0.625em; }

 .sect1 { padding-bottom: 0.625em; }

 @media only screen and (min-width: 768px) { #content { margin-bottom: 1.25em; }
   .sect1 { padding-bottom: 1.25em; } }
 .sect1:last-child { padding-bottom: 0; }

 .sect1 + .sect1 { border-top: 0 solid #dddddd; }

 #content h1 > a.anchor, h2 > a.anchor, h3 > a.anchor, #toctitle > a.anchor, .sidebarblock > .content > .title > a.anchor, h4 > a.anchor, h5 > a.anchor, h6 > a.anchor { position: absolute; z-index: 1001; width: 1.5ex; margin-left: -1.5ex; display: block; text-decoration: none !important; visibility: hidden; text-align: center; font-weight: normal; }
 #content h1 > a.anchor:before, h2 > a.anchor:before, h3 > a.anchor:before, #toctitle > a.anchor:before, .sidebarblock > .content > .title > a.anchor:before, h4 > a.anchor:before, h5 > a.anchor:before, h6 > a.anchor:before { content: "\00A7"; font-size: 0.85em; display: block; padding-top: 0.1em; }
 #content h1:hover > a.anchor, #content h1 > a.anchor:hover, h2:hover > a.anchor, h2 > a.anchor:hover, h3:hover > a.anchor, #toctitle:hover > a.anchor, .sidebarblock > .content > .title:hover > a.anchor, h3 > a.anchor:hover, #toctitle > a.anchor:hover, .sidebarblock > .content > .title > a.anchor:hover, h4:hover > a.anchor, h4 > a.anchor:hover, h5:hover > a.anchor, h5 > a.anchor:hover, h6:hover > a.anchor, h6 > a.anchor:hover { visibility: visible; }
 #content h1 > a.link, h2 > a.link, h3 > a.link, #toctitle > a.link, .sidebarblock > .content > .title > a.link, h4 > a.link, h5 > a.link, h6 > a.link { color: black; text-decoration: none; }
 #content h1 > a.link:hover, h2 > a.link:hover, h3 > a.link:hover, #toctitle > a.link:hover, .sidebarblock > .content > .title > a.link:hover, h4 > a.link:hover, h5 > a.link:hover, h6 > a.link:hover { color: black; }

 .audioblock, .imageblock, .literalblock, .listingblock, .stemblock, .videoblock { margin-bottom: 1.25em; }

 .admonitionblock td.content > .title, .audioblock > .title, .exampleblock > .title, .imageblock > .title, .listingblock > .title, .literalblock > .title, .stemblock > .title, .openblock > .title, .paragraph > .title, .quoteblock > .title, table.tableblock > .title, .verseblock > .title, .videoblock > .title, .dlist > .title, .olist > .title, .ulist > .title, .qlist > .title, .hdlist > .title { text-rendering: optimizeLegibility; text-align: left; }

 table.tableblock > caption.title { white-space: nowrap; overflow: visible; max-width: 0; }

 .paragraph.lead > p, #preamble > .sectionbody > .paragraph:first-of-type p { color: black; }

 table.tableblock #preamble > .sectionbody > .paragraph:first-of-type p { font-size: inherit; }

 .admonitionblock > table { border-collapse: separate; border: 0; background: none; width: 100%; }
 .admonitionblock > table td.icon { text-align: center; width: 80px; }
 .admonitionblock > table td.icon img { max-width: initial; }
 .admonitionblock > table td.icon .title { font-weight: bold; font-family: Noto, sans-serif; text-transform: uppercase; }
 .admonitionblock > table td.content { padding-left: 1.125em; padding-right: 1.25em; border-left: 1px solid #dddddd; color: #5e93b8; }
 .admonitionblock > table td.content > :last-child > :last-child { margin-bottom: 0; }

 .exampleblock > .content { border-style: solid; border-width: 1px; border-color: #e6e6e6; margin-bottom: 1.25em; padding: 1.25em; background: white; -webkit-border-radius: 0; border-radius: 0; }
 .exampleblock > .content > :first-child { margin-top: 0; }
 .exampleblock > .content > :last-child { margin-bottom: 0; }

 .sidebarblock { border-style: solid; border-width: 1px; border-color: #e6e6e6; margin-bottom: 1.25em; padding: 1.25em; background: white; -webkit-border-radius: 0; border-radius: 0; }
 .sidebarblock > :first-child { margin-top: 0; }
 .sidebarblock > :last-child { margin-bottom: 0; }
 .sidebarblock > .content > .title { color: black; margin-top: 0; }

 .exampleblock > .content > :last-child > :last-child, .exampleblock > .content .olist > ol > li:last-child > :last-child, .exampleblock > .content .ulist > ul > li:last-child > :last-child, .exampleblock > .content .qlist > ol > li:last-child > :last-child, .sidebarblock > .content > :last-child > :last-child, .sidebarblock > .content .olist > ol > li:last-child > :last-child, .sidebarblock > .content .ulist > ul > li:last-child > :last-child, .sidebarblock > .content .qlist > ol > li:last-child > :last-child { margin-bottom: 0; }

 .literalblock pre, .listingblock pre:not(.highlight), .listingblock pre[class="highlight"], .listingblock pre[class^="highlight "], .listingblock pre.CodeRay, .listingblock pre.prettyprint { background: #eeeeee; }
 .sidebarblock .literalblock pre, .sidebarblock .listingblock pre:not(.highlight), .sidebarblock .listingblock pre[class="highlight"], .sidebarblock .listingblock pre[class^="highlight "], .sidebarblock .listingblock pre.CodeRay, .sidebarblock .listingblock pre.prettyprint { background: #f2f1f1; }

 .literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { border: 1px hidden #666666; -webkit-border-radius: 0; border-radius: 0; word-wrap: break-word; padding: 1.25em 1.5625em 1.125em 1.5625em; font-size: 0.8125em; }
 .literalblock pre.nowrap, .literalblock pre[class].nowrap, .listingblock pre.nowrap, .listingblock pre[class].nowrap { overflow-x: auto; white-space: pre; word-wrap: normal; }
 @media only screen and (min-width: 768px) { .literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { font-size: 0.90625em; } }
 @media only screen and (min-width: 1280px) { .literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { font-size: 1em; } }

 .literalblock.output pre { color: #eeeeee; background-color: #264357; }

 .listingblock pre.highlightjs { padding: 0; }
 .listingblock pre.highlightjs > code { padding: 1.25em 1.5625em 1.125em 1.5625em; -webkit-border-radius: 0; border-radius: 0; }

 .listingblock > .content { position: relative; }

 .listingblock code[data-lang]:before { display: none; content: attr(data-lang); position: absolute; font-size: 0.75em; top: 0.425rem; right: 0.5rem; line-height: 1; text-transform: uppercase; color: #999; }

 .listingblock:hover code[data-lang]:before { display: block; }

 .listingblock.terminal pre .command:before { content: attr(data-prompt); padding-right: 0.5em; color: #999; }

 .listingblock.terminal pre .command:not([data-prompt]):before { content: "$"; }

 table.pyhltable { border-collapse: separate; border: 0; margin-bottom: 0; background: none; }

 table.pyhltable td { vertical-align: top; padding-top: 0; padding-bottom: 0; line-height: 1.6; }

 table.pyhltable td.code { padding-left: .75em; padding-right: 0; }

 pre.pygments .lineno, table.pyhltable td:not(.code) { color: #999; padding-left: 0; padding-right: .5em; border-right: 1px solid #dddddd; }

 pre.pygments .lineno { display: inline-block; margin-right: .25em; }

 table.pyhltable .linenodiv { background: none !important; padding-right: 0 !important; }

 .quoteblock { margin: 0 1em 0.75em 1.5em; display: table; }
 .quoteblock > .title { margin-left: -1.5em; margin-bottom: 0.75em; }
 .quoteblock blockquote, .quoteblock blockquote p { color: #333333; font-size: 1.15rem; line-height: 1.75; word-spacing: 0.1em; letter-spacing: 0; font-style: italic; text-align: justify; }
 .quoteblock blockquote { margin: 0; padding: 0; border: 0; }
 .quoteblock blockquote:before { content: "\201c"; float: left; font-size: 2.75em; font-weight: bold; line-height: 0.6em; margin-left: -0.6em; color: black; text-shadow: 0 1px 2px rgba(0, 0, 0, 0.1); }
 .quoteblock blockquote > .paragraph:last-child p { margin-bottom: 0; }
 .quoteblock .attribution { margin-top: 0.5em; margin-right: 0.5ex; text-align: right; }
 .quoteblock .quoteblock { margin-left: 0; margin-right: 0; padding: 0.5em 0; border-left: 3px solid #5e93b8; }
 .quoteblock .quoteblock blockquote { padding: 0 0 0 0.75em; }
 .quoteblock .quoteblock blockquote:before { display: none; }

 .verseblock { margin: 0 1em 0.75em 1em; }
 .verseblock pre { font-family: "Open Sans", "DejaVu Sans", sans; font-size: 1.15rem; color: #333333; font-weight: 300; text-rendering: optimizeLegibility; }
 .verseblock pre strong { font-weight: 400; }
 .verseblock .attribution { margin-top: 1.25rem; margin-left: 0.5ex; }

 .quoteblock .attribution, .verseblock .attribution { font-size: 0.8125em; line-height: 1.45; font-style: italic; }
 .quoteblock .attribution br, .verseblock .attribution br { display: none; }
 .quoteblock .attribution cite, .verseblock .attribution cite { display: block; letter-spacing: -0.025em; color: #5e93b8; }

 .quoteblock.abstract { margin: 0 0 0.75em 0; display: block; }
 .quoteblock.abstract blockquote, .quoteblock.abstract blockquote p { text-align: left; word-spacing: 0; }
 .quoteblock.abstract blockquote:before, .quoteblock.abstract blockquote p:first-of-type:before { display: none; }

 table.tableblock { max-width: 100%; border-collapse: separate; }
 table.tableblock td > .paragraph:last-child p > p:last-child, table.tableblock th > p:last-child, table.tableblock td > p:last-child { margin-bottom: 0; }

 table.tableblock, th.tableblock, td.tableblock { border: 0 solid #d8d8ce; }

 table.grid-all > thead > tr > .tableblock, table.grid-all > tbody > tr > .tableblock { border-width: 0 1px 1px 0; }

 table.grid-all > tfoot > tr > .tableblock { border-width: 1px 1px 0 0; }

 table.grid-cols > * > tr > .tableblock { border-width: 0 1px 0 0; }

 table.grid-rows > thead > tr > .tableblock, table.grid-rows > tbody > tr > .tableblock { border-width: 0 0 1px 0; }

 table.grid-rows > tfoot > tr > .tableblock { border-width: 1px 0 0 0; }

 table.grid-all > * > tr > .tableblock:last-child, table.grid-cols > * > tr > .tableblock:last-child { border-right-width: 0; }

 table.grid-all > tbody > tr:last-child > .tableblock, table.grid-all > thead:last-child > tr > .tableblock, table.grid-rows > tbody > tr:last-child > .tableblock, table.grid-rows > thead:last-child > tr > .tableblock { border-bottom-width: 0; }

 table.frame-all { border-width: 1px; }

 table.frame-sides { border-width: 0 1px; }

 table.frame-topbot { border-width: 1px 0; }

 th.halign-left, td.halign-left { text-align: left; }

 th.halign-right, td.halign-right { text-align: right; }

 th.halign-center, td.halign-center { text-align: center; }

 th.valign-top, td.valign-top { vertical-align: top; }

 th.valign-bottom, td.valign-bottom { vertical-align: bottom; }

 th.valign-middle, td.valign-middle { vertical-align: middle; }

 table thead th, table tfoot th { font-weight: bold; }

 tbody tr th { display: table-cell; line-height: 1.4; background: -webkit-linear-gradient(top, #add386, #90b66a); }

 tbody tr th, tbody tr th p, tfoot tr th, tfoot tr th p { color: white; font-weight: bold; }

 p.tableblock > code:only-child { background: none; padding: 0; }

 p.tableblock { font-size: 1em; }

 td > div.verse { white-space: pre; }

 ol { margin-left: 1.75em; }

 ul li ol { margin-left: 1.5em; }

 dl dd { margin-left: 1.125em; }

 dl dd:last-child, dl dd:last-child > :last-child { margin-bottom: 0; }

 ol > li p, ul > li p, ul dd, ol dd, .olist .olist, .ulist .ulist, .ulist .olist, .olist .ulist { margin-bottom: 0.375em; }

 ul.checklist, ul.none, ol.none, ul.no-bullet, ol.no-bullet, ol.unnumbered, ul.unstyled, ol.unstyled { list-style-type: none; }

 ul.no-bullet, ol.no-bullet, ol.unnumbered { margin-left: 0.625em; }

 ul.unstyled, ol.unstyled { margin-left: 0; }

 ul.checklist { margin-left: 0.625em; }

 ul.checklist li > p:first-child > .fa-square-o:first-child, ul.checklist li > p:first-child > .fa-check-square-o:first-child { width: 1.25em; font-size: 0.8em; position: relative; bottom: 0.125em; }

 ul.checklist li > p:first-child > input[type="checkbox"]:first-child { margin-right: 0.25em; }

 ul.inline { display: -ms-flexbox; display: -webkit-box; display: flex; -ms-flex-flow: row wrap; -webkit-flex-flow: row wrap; flex-flow: row wrap; list-style: none; margin: 0 0 0.375em -0.75em; }

 ul.inline > li { margin-left: 0.75em; }

 .unstyled dl dt { font-weight: normal; font-style: normal; }

 ol.arabic { list-style-type: decimal; }

 ol.decimal { list-style-type: decimal-leading-zero; }

 ol.loweralpha { list-style-type: lower-alpha; }

 ol.upperalpha { list-style-type: upper-alpha; }

 ol.lowerroman { list-style-type: lower-roman; }

 ol.upperroman { list-style-type: upper-roman; }

 ol.lowergreek { list-style-type: lower-greek; }

 .hdlist > table, .colist > table { border: 0; background: none; }
 .hdlist > table > tbody > tr, .colist > table > tbody > tr { background: none; }

 td.hdlist1, td.hdlist2 { vertical-align: top; padding: 0 0.625em; }

 td.hdlist1 { font-weight: bold; padding-bottom: 0.75em; }

 .literalblock + .colist, .listingblock + .colist { margin-top: -0.5em; }

 .colist > table tr > td:first-of-type { padding: 0.4em 0.75em 0 0.75em; line-height: 1; vertical-align: top; }
 .colist > table tr > td:first-of-type img { max-width: initial; }
 .colist > table tr > td:last-of-type { padding: 0.25em 0; }

 .thumb, .th { line-height: 0; display: inline-block; border: solid 4px white; -webkit-box-shadow: 0 0 0 1px #dddddd; box-shadow: 0 0 0 1px #dddddd; }

 .imageblock.left, .imageblock[style*="float: left"] { margin: 0.25em 0.625em 1.25em 0; }
 .imageblock.right, .imageblock[style*="float: right"] { margin: 0.25em 0 1.25em 0.625em; }
 .imageblock > .title { margin-bottom: 0; }
 .imageblock.thumb, .imageblock.th { border-width: 6px; }
 .imageblock.thumb > .title, .imageblock.th > .title { padding: 0 0.125em; }

 .image.left, .image.right { margin-top: 0.25em; margin-bottom: 0.25em; display: inline-block; line-height: 0; }
 .image.left { margin-right: 0.625em; }
 .image.right { margin-left: 0.625em; }

 a.image { text-decoration: none; display: inline-block; }
 a.image object { pointer-events: none; }

 sup.footnote, sup.footnoteref { font-size: 0.875em; position: static; vertical-align: super; }
 sup.footnote a, sup.footnoteref a { text-decoration: none; }
 sup.footnote a:active, sup.footnoteref a:active { text-decoration: underline; }

 #footnotes { padding-top: 0.75em; padding-bottom: 0.75em; margin-bottom: 0.625em; }
 #footnotes hr { width: 20%; min-width: 6.25em; margin: -0.25em 0 0.75em 0; border-width: 1px 0 0 0; }
 #footnotes .footnote { padding: 0 0.375em 0 0.225em; line-height: 1.3334; font-size: 0.875em; margin-left: 1.2em; margin-bottom: 0.2em; }
 #footnotes .footnote a:first-of-type { font-weight: bold; text-decoration: none; margin-left: -1.05em; }
 #footnotes .footnote:last-of-type { margin-bottom: 0; }
 #content #footnotes { margin-top: -0.625em; margin-bottom: 0; padding: 0.75em 0; }

 .gist .file-data > table { border: 0; background: #fff; width: 100%; margin-bottom: 0; }
 .gist .file-data > table td.line-data { width: 99%; }

 div.unbreakable { page-break-inside: avoid; }

 .big { font-size: larger; }

 .small { font-size: smaller; }

 .underline { text-decoration: underline; }

 .overline { text-decoration: overline; }

 .line-through { text-decoration: line-through; }

 .aqua { color: #00bfbf; }

 .aqua-background { background-color: #00fafa; }

 .black { color: black; }

 .black-background { background-color: black; }

 .blue { color: #0000bf; }

 .blue-background { background-color: #0000fa; }

 .fuchsia { color: #bf00bf; }

 .fuchsia-background { background-color: #fa00fa; }

 .gray { color: #606060; }

 .gray-background { background-color: #7d7d7d; }

 .green { color: #006000; }

 .green-background { background-color: #007d00; }

 .lime { color: #00bf00; }

 .lime-background { background-color: #00fa00; }

 .maroon { color: #600000; }

 .maroon-background { background-color: #7d0000; }

 .navy { color: #000060; }

 .navy-background { background-color: #00007d; }

 .olive { color: #606000; }

 .olive-background { background-color: #7d7d00; }

 .purple { color: #600060; }

 .purple-background { background-color: #7d007d; }

 .red { color: #bf0000; }

 .red-background { background-color: #fa0000; }

 .silver { color: #909090; }

 .silver-background { background-color: #bcbcbc; }

 .teal { color: #006060; }

 .teal-background { background-color: #007d7d; }

 .white { color: #bfbfbf; }

 .white-background { background-color: #fafafa; }

 .yellow { color: #bfbf00; }

 .yellow-background { background-color: #fafa00; }

 span.icon > .fa { cursor: default; }
 a span.icon > .fa { cursor: inherit; }

 .admonitionblock td.icon [class^="fa icon-"] { font-size: 2.5em; text-shadow: 1px 1px 2px rgba(0, 0, 0, 0.5); cursor: default; }
 .admonitionblock td.icon .icon-note:before { content: "\f05a"; color: #29475c; }
 .admonitionblock td.icon .icon-tip:before { content: "\f0eb"; text-shadow: 1px 1px 2px rgba(155, 155, 0, 0.8); color: #111; }
 .admonitionblock td.icon .icon-warning:before { content: "\f071"; color: #bf6900; }
 .admonitionblock td.icon .icon-caution:before { content: "\f06d"; color: #bf3400; }
 .admonitionblock td.icon .icon-important:before { content: "\f06a"; color: #bf0000; }

 .conum[data-value] { display: inline-block; color: #fff !important; background-color: black; -webkit-border-radius: 100px; border-radius: 100px; text-align: center; font-size: 0.75em; width: 1.67em; height: 1.67em; line-height: 1.67em; font-family: "Open Sans", "DejaVu Sans", sans-serif; font-style: normal; font-weight: bold; }
 .conum[data-value] * { color: #fff !important; }
 .conum[data-value] + b { display: none; }
 .conum[data-value]:after { content: attr(data-value); }
 pre .conum[data-value] { position: relative; top: -0.125em; }

 b.conum * { color: inherit !important; }

 .conum:not([data-value]):empty { display: none; }

 h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { border-bottom: 1px solid #dddddd; }

 .sect1 { padding-bottom: 0; }

 #toctitle { color: #00406F; font-weight: normal; margin-top: 1.5em; }

 .sidebarblock { border-color: #aaa; }

 code { -webkit-border-radius: 4px; border-radius: 4px; }

 p.tableblock.header { color: #6d6e71; }

 .literalblock pre, .listingblock pre { background: #eeeeee; }

 </style>
 <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css">
 <style>
 /* Stylesheet for CodeRay to match GitHub theme | MIT License | http://foundation.zurb.com */
 /*pre.CodeRay {background-color:#f7f7f8;}*/
 .CodeRay .line-numbers{border-right:1px solid #d8d8d8;padding:0 0.5em 0 .25em}
 .CodeRay span.line-numbers{display:inline-block;margin-right:.5em;color:rgba(0,0,0,.3)}
 .CodeRay .line-numbers strong{color:rgba(0,0,0,.4)}
 table.CodeRay{border-collapse:separate;border-spacing:0;margin-bottom:0;border:0;background:none}
 table.CodeRay td{vertical-align: top;line-height:1.45}
 table.CodeRay td.line-numbers{text-align:right}
 table.CodeRay td.line-numbers>pre{padding:0;color:rgba(0,0,0,.3)}
 table.CodeRay td.code{padding:0 0 0 .5em}
 table.CodeRay td.code>pre{padding:0}
 .CodeRay .debug{color:#fff !important;background:#000080 !important}
 .CodeRay .annotation{color:#007}
 .CodeRay .attribute-name{color:#000080}
 .CodeRay .attribute-value{color:#700}
 .CodeRay .binary{color:#509}
 .CodeRay .comment{color:#998;font-style:italic}
 .CodeRay .char{color:#04d}
 .CodeRay .char .content{color:#04d}
 .CodeRay .char .delimiter{color:#039}
 .CodeRay .class{color:#458;font-weight:bold}
 .CodeRay .complex{color:#a08}
 .CodeRay .constant,.CodeRay .predefined-constant{color:#008080}
 .CodeRay .color{color:#099}
 .CodeRay .class-variable{color:#369}
 .CodeRay .decorator{color:#b0b}
 .CodeRay .definition{color:#099}
 .CodeRay .delimiter{color:#000}
 .CodeRay .doc{color:#970}
 .CodeRay .doctype{color:#34b}
 .CodeRay .doc-string{color:#d42}
 .CodeRay .escape{color:#666}
 .CodeRay .entity{color:#800}
 .CodeRay .error{color:#808}
 .CodeRay .exception{color:inherit}
 .CodeRay .filename{color:#099}
 .CodeRay .function{color:#900;font-weight:bold}
 .CodeRay .global-variable{color:#008080}
 .CodeRay .hex{color:#058}
 .CodeRay .integer,.CodeRay .float{color:#099}
 .CodeRay .include{color:#555}
 .CodeRay .inline{color:#000}
 .CodeRay .inline .inline{background:#ccc}
 .CodeRay .inline .inline .inline{background:#bbb}
 .CodeRay .inline .inline-delimiter{color:#d14}
 .CodeRay .inline-delimiter{color:#d14}
 .CodeRay .important{color:#555;font-weight:bold}
 .CodeRay .interpreted{color:#b2b}
 .CodeRay .instance-variable{color:#008080}
 .CodeRay .label{color:#970}
 .CodeRay .local-variable{color:#963}
 .CodeRay .octal{color:#40e}
 .CodeRay .predefined{color:#369}
 .CodeRay .preprocessor{color:#579}
 .CodeRay .pseudo-class{color:#555}
 .CodeRay .directive{font-weight:bold}
 .CodeRay .type{font-weight:bold}
 .CodeRay .predefined-type{color:inherit}
 .CodeRay .reserved,.CodeRay .keyword {color:#000;font-weight:bold}
 .CodeRay .key{color:#808}
 .CodeRay .key .delimiter{color:#606}
 .CodeRay .key .char{color:#80f}
 .CodeRay .value{color:#088}
 .CodeRay .regexp .delimiter{color:#808}
 .CodeRay .regexp .content{color:#808}
 .CodeRay .regexp .modifier{color:#808}
 .CodeRay .regexp .char{color:#d14}
 .CodeRay .regexp .function{color:#404;font-weight:bold}
 .CodeRay .string{color:#d20}
 .CodeRay .string .string .string{background:#ffd0d0}
 .CodeRay .string .content{color:#d14}
 .CodeRay .string .char{color:#d14}
 .CodeRay .string .delimiter{color:#d14}
 .CodeRay .shell{color:#d14}
 .CodeRay .shell .delimiter{color:#d14}
 .CodeRay .symbol{color:#990073}
 .CodeRay .symbol .content{color:#a60}
 .CodeRay .symbol .delimiter{color:#630}
 .CodeRay .tag{color:#008080}
 .CodeRay .tag-special{color:#d70}
 .CodeRay .variable{color:#036}
 .CodeRay .insert{background:#afa}
 .CodeRay .delete{background:#faa}
 .CodeRay .change{color:#aaf;background:#007}
 .CodeRay .head{color:#f8f;background:#505}
 .CodeRay .insert .insert{color:#080}
 .CodeRay .delete .delete{color:#800}
 .CodeRay .change .change{color:#66f}
 .CodeRay .head .head{color:#f4f}
 </style>
 <link rel="stylesheet" href="../katex/katex.min.css">
 <script src="../katex/katex.min.js"></script>
 <script src="../katex/contrib/auto-render.min.js"></script>
     <!-- Use KaTeX to render math once document is loaded, see
          https://github.com/Khan/KaTeX/tree/master/contrib/auto-render -->
 <script>
     document.addEventListener("DOMContentLoaded", function () {
         renderMathInElement(
             document.body,
             {
                 delimiters: [
                     { left: "$$", right: "$$", display: true},
                     { left: "\\[", right: "\\]", display: true},
                     { left: "$", right: "$", display: false},
                     { left: "\\(", right: "\\)", display: false}
                 ]
             }
         );
     });
 </script></head>
 <body class="book toc2 toc-left" style="max-width: 100;">
 <div id="header">
 <h1>The OpenCL<sup>&#8482;</sup> Specification</h1>
 <div class="details">
 <span id="author" class="author">Khronos<sup>&#174;</sup> OpenCL Working Group</span><br>
 <span id="revnumber">version v3.0.6,</span>
 <span id="revdate">Fri, 18 Dec 2020 12:00:00 +0000</span>
 <br><span id="revremark">from git branch: master commit: e9a4d468b1a0a38c1e10b8af484bb2bbb495e2b7</span>
 </div>
 <div id="toc" class="toc2">
 <div id="toctitle">Table of Contents</div>
 <ul class="sectlevel1">
 <li><a href="#_introduction">1. Introduction</a>
 <ul class="sectlevel2">
 <li><a href="#_normative_references">1.1. Normative References</a></li>
 <li><a href="#_version_numbers">1.2. Version Numbers</a></li>
 <li><a href="#unified-spec">1.3. Unified Specification</a></li>
 </ul>
 </li>
 <li><a href="#_glossary">2. Glossary</a></li>
 <li><a href="#_the_opencl_architecture">3. The OpenCL Architecture</a>
 <ul class="sectlevel2">
 <li><a href="#_platform_model">3.1. Platform Model</a></li>
 <li><a href="#_execution_model">3.2. Execution Model</a>
 <ul class="sectlevel3">
 <li><a href="#_mapping_work_items_onto_an_ndrange">3.2.1. Mapping work-items onto an NDRange</a></li>
 <li><a href="#_execution_of_kernel_instances">3.2.2. Execution of kernel-instances</a></li>
 <li><a href="#device-side-enqueue">3.2.3. Device-side enqueue</a></li>
 <li><a href="#execution-model-sync">3.2.4. Synchronization</a></li>
 <li><a href="#_categories_of_kernels">3.2.5. Categories of Kernels</a></li>
 </ul>
 </li>
 <li><a href="#_memory_model">3.3. Memory Model</a>
 <ul class="sectlevel3">
 <li><a href="#_fundamental_memory_regions">3.3.1. Fundamental Memory Regions</a></li>
 <li><a href="#_memory_objects">3.3.2. Memory Objects</a></li>
 <li><a href="#shared-virtual-memory">3.3.3. Shared Virtual Memory</a></li>
 <li><a href="#_memory_consistency_model_for_opencl_1_x">3.3.4. Memory Consistency Model for OpenCL 1.x</a></li>
 <li><a href="#memory-consistency-model">3.3.5. Memory Consistency Model for OpenCL 2.x</a></li>
 <li><a href="#_overview_of_atomic_and_fence_operations">3.3.6. Overview of atomic and fence operations</a></li>
 <li><a href="#memory-ordering-rules">3.3.7. Memory Ordering Rules</a></li>
 </ul>
 </li>
 <li><a href="#opencl-framework">3.4. The OpenCL Framework</a>
 <ul class="sectlevel3">
 <li><a href="#_mixed_version_support">3.4.1. Mixed Version Support</a></li>
 <li><a href="#_backwards_compatibility">3.4.2. Backwards Compatibility</a></li>
 <li><a href="#_versioning">3.4.3. Versioning</a></li>
 </ul>
 </li>
 </ul>
 </li>
 <li><a href="#opencl-platform-layer">4. The OpenCL Platform Layer</a>
 <ul class="sectlevel2">
 <li><a href="#_querying_platform_info">4.1. Querying Platform Info</a></li>
 <li><a href="#platform-querying-devices">4.2. Querying Devices</a></li>
 <li><a href="#_partitioning_a_device">4.3. Partitioning a Device</a></li>
 <li><a href="#_contexts">4.4. Contexts</a></li>
 </ul>
 </li>
 <li><a href="#opencl-runtime">5. The OpenCL Runtime</a>
 <ul class="sectlevel2">
 <li><a href="#_command_queues">5.1. Command Queues</a></li>
 <li><a href="#_buffer_objects">5.2. Buffer Objects</a>
 <ul class="sectlevel3">
 <li><a href="#_creating_buffer_objects">5.2.1. Creating Buffer Objects</a></li>
 <li><a href="#_reading_writing_and_copying_buffer_objects">5.2.2. Reading, Writing and Copying Buffer Objects</a></li>
 <li><a href="#_filling_buffer_objects">5.2.3. Filling Buffer Objects</a></li>
 <li><a href="#_mapping_buffer_objects">5.2.4. Mapping Buffer Objects</a></li>
 </ul>
 </li>
 <li><a href="#_image_objects">5.3. Image Objects</a>
 <ul class="sectlevel3">
 <li><a href="#_creating_image_objects">5.3.1. Creating Image Objects</a></li>
 <li><a href="#_querying_list_of_supported_image_formats">5.3.2. Querying List of Supported Image Formats</a></li>
 <li><a href="#_reading_writing_and_copying_image_objects">5.3.3. Reading, Writing and Copying Image Objects</a></li>
 <li><a href="#_filling_image_objects">5.3.4. Filling Image Objects</a></li>
 <li><a href="#_copying_between_image_and_buffer_objects">5.3.5. Copying between Image and Buffer Objects</a></li>
 <li><a href="#_mapping_image_objects">5.3.6. Mapping Image Objects</a></li>
 <li><a href="#image-object-queries">5.3.7. Image Object Queries</a></li>
 </ul>
 </li>
 <li><a href="#_pipes">5.4. Pipes</a>
 <ul class="sectlevel3">
 <li><a href="#_creating_pipe_objects">5.4.1. Creating Pipe Objects</a></li>
 <li><a href="#_pipe_object_queries">5.4.2. Pipe Object Queries</a></li>
 </ul>
 </li>
 <li><a href="#_querying_unmapping_migrating_retaining_and_releasing_memory_objects">5.5. Querying, Unmapping, Migrating, Retaining and Releasing Memory Objects</a>
 <ul class="sectlevel3">
 <li><a href="#_retaining_and_releasing_memory_objects">5.5.1. Retaining and Releasing Memory Objects</a></li>
 <li><a href="#unmapping-mapped-memory">5.5.2. Unmapping Mapped Memory Objects</a></li>
 <li><a href="#accessing-mapped-regions">5.5.3. Accessing mapped regions of a memory object</a></li>
 <li><a href="#_migrating_memory_objects">5.5.4. Migrating Memory Objects</a></li>
 <li><a href="#memory-object-queries">5.5.5. Memory Object Queries</a></li>
 </ul>
 </li>
 <li><a href="#_shared_virtual_memory">5.6. Shared Virtual Memory</a>
 <ul class="sectlevel3">
 <li><a href="#_svm_sharing_granularity_coarse_and_fine_grained_sharing">5.6.1. SVM sharing granularity: coarse- and fine- grained sharing</a></li>
 <li><a href="#_memory_consistency_for_svm_allocations">5.6.2. Memory consistency for SVM allocations</a></li>
 </ul>
 </li>
 <li><a href="#_sampler_objects">5.7. Sampler Objects</a>
 <ul class="sectlevel3">
 <li><a href="#_creating_sampler_objects">5.7.1. Creating Sampler Objects</a></li>
 <li><a href="#_sampler_object_queries">5.7.2. Sampler Object Queries</a></li>
 </ul>
 </li>
 <li><a href="#_program_objects">5.8. Program Objects</a>
 <ul class="sectlevel3">
 <li><a href="#_creating_program_objects">5.8.1. Creating Program Objects</a></li>
 <li><a href="#_retaining_and_releasing_program_objects">5.8.2. Retaining and Releasing Program Objects</a></li>
 <li><a href="#_setting_spir_v_specialization_constants">5.8.3. Setting SPIR-V specialization constants</a></li>
 <li><a href="#_building_program_executables">5.8.4. Building Program Executables</a></li>
 <li><a href="#_separate_compilation_and_linking_of_programs">5.8.5. Separate Compilation and Linking of Programs</a></li>
 <li><a href="#compiler-options">5.8.6. Compiler Options</a></li>
 <li><a href="#linker-options">5.8.7. Linker Options</a></li>
 <li><a href="#_unloading_the_opencl_compiler">5.8.8. Unloading the OpenCL Compiler</a></li>
 <li><a href="#_program_object_queries">5.8.9. Program Object Queries</a></li>
 </ul>
 </li>
 <li><a href="#_kernel_objects">5.9. Kernel Objects</a>
 <ul class="sectlevel3">
 <li><a href="#_creating_kernel_objects">5.9.1. Creating Kernel Objects</a></li>
 <li><a href="#_setting_kernel_arguments">5.9.2. Setting Kernel Arguments</a></li>
 <li><a href="#_copying_kernel_objects">5.9.3. Copying Kernel Objects</a></li>
 <li><a href="#_kernel_object_queries">5.9.4. Kernel Object Queries</a></li>
 </ul>
 </li>
 <li><a href="#_executing_kernels">5.10. Executing Kernels</a></li>
 <li><a href="#event-objects">5.11. Event Objects</a></li>
 <li><a href="#markers-barriers-waiting-for-events">5.12. Markers, Barriers and Waiting for Events</a></li>
 <li><a href="#_out_of_order_execution_of_kernels_and_memory_object_commands">5.13. Out-of-order Execution of Kernels and Memory Object Commands</a></li>
 <li><a href="#profiling-operations">5.14. Profiling Operations on Memory Objects and Kernels</a></li>
 <li><a href="#_flush_and_finish">5.15. Flush and Finish</a></li>
 </ul>
 </li>
 <li><a href="#_associated_opencl_specification">6. Associated OpenCL specification</a>
 <ul class="sectlevel2">
 <li><a href="#spirv-il">6.1. SPIR-V Intermediate Language</a></li>
 <li><a href="#opencl-extensions">6.2. Extensions to OpenCL</a></li>
 <li><a href="#opencl-c-kernel-language">6.3. The OpenCL C Kernel Language</a></li>
 </ul>
 </li>
 <li><a href="#opencl-embedded-profile">7. OpenCL Embedded Profile</a></li>
 <li><a href="#_host_environment_and_thread_safety">Appendix A: Host environment and thread safety</a>
 <ul class="sectlevel2">
 <li><a href="#shared-opencl-objects">Shared OpenCL Objects</a></li>
 <li><a href="#_multiple_host_threads">Multiple Host Threads</a></li>
 <li><a href="#_global_constructors_and_destructors">Global constructors and destructors</a></li>
 </ul>
 </li>
 <li><a href="#_portability">Appendix B: Portability</a></li>
 <li><a href="#data-types">Appendix C: Application Data Types</a>
 <ul class="sectlevel2">
 <li><a href="#scalar-data-types">Supported Application Scalar Data Types</a></li>
 <li><a href="#vector-data-types">Supported Application Vector Data Types</a></li>
 <li><a href="#alignment-app-data-types">Alignment of Application Data Types</a></li>
 <li><a href="#_vector_literals">Vector Literals</a></li>
 <li><a href="#vector-components">Vector Components</a>
 <ul class="sectlevel3">
 <li><a href="#_named_vector_components_notation">Named vector components notation</a></li>
 <li><a href="#_highlow_vector_component_notation">High/Low vector component notation</a></li>
 <li><a href="#_native_vector_type_notation">Native vector type notation</a></li>
 </ul>
 </li>
 <li><a href="#_implicit_conversions">Implicit Conversions</a></li>
 <li><a href="#_explicit_casts">Explicit Casts</a></li>
 <li><a href="#_other_operators_and_functions">Other operators and functions</a></li>
 <li><a href="#_application_constant_definitions">Application constant definitions</a></li>
 </ul>
 </li>
 <li><a href="#check-copy-overlap">Appendix D: Checking for Memory Copy Overlap</a></li>
 <li><a href="#changes_to_opencl">Appendix E: Changes to OpenCL</a>
 <ul class="sectlevel2">
 <li><a href="#_summary_of_changes_from_opencl_1_0_to_opencl_1_1">Summary of changes from OpenCL 1.0 to OpenCL 1.1</a></li>
 <li><a href="#_summary_of_changes_from_opencl_1_1_to_opencl_1_2">Summary of changes from OpenCL 1.1 to OpenCL 1.2</a></li>
 <li><a href="#_summary_of_changes_from_opencl_1_2_to_opencl_2_0">Summary of changes from OpenCL 1.2 to OpenCL 2.0</a></li>
 <li><a href="#_summary_of_changes_from_opencl_2_0_to_opencl_2_1">Summary of changes from OpenCL 2.0 to OpenCL 2.1</a></li>
 <li><a href="#_summary_of_changes_from_opencl_2_1_to_opencl_2_2">Summary of changes from OpenCL 2.1 to OpenCL 2.2</a></li>
 <li><a href="#_summary_of_changes_from_opencl_2_2_to_opencl_3_0">Summary of changes from OpenCL 2.2 to OpenCL 3.0</a></li>
 </ul>
 </li>
 <li><a href="#error_codes">Appendix F: Error Codes</a></li>
 <li><a href="#error_other_misc_enums">Appendix G: Other Miscellaneous Enums</a></li>
 <li><a href="#opencl-3.0-backwards-compatibility">Appendix H: OpenCL 3.0 Backwards Compatibility</a>
 <ul class="sectlevel2">
 <li><a href="#_shared_virtual_memory_2">Shared Virtual Memory</a></li>
 <li><a href="#_memory_consistency_model">Memory Consistency Model</a></li>
 <li><a href="#_device_side_enqueue">Device-Side Enqueue</a></li>
 <li><a href="#_pipes_2">Pipes</a></li>
 <li><a href="#_program_scope_global_variables">Program Scope Global Variables</a></li>
 <li><a href="#_non_uniform_work_groups">Non-Uniform Work Groups</a></li>
 <li><a href="#_read_write_images">Read-Write Images</a></li>
 <li><a href="#_creating_2d_images_from_buffers">Creating 2D Images from Buffers</a></li>
 <li><a href="#_srgb_images">sRGB Images</a></li>
 <li><a href="#_depth_images">Depth Images</a></li>
 <li><a href="#_device_and_host_timer_synchronization">Device and Host Timer Synchronization</a></li>
 <li><a href="#_intermediate_language_programs">Intermediate Language Programs</a></li>
 <li><a href="#_subgroups">Subgroups</a></li>
 <li><a href="#_program_initialization_and_clean_up_kernels">Program Initialization and Clean-Up Kernels</a></li>
 <li><a href="#_3d_image_writes">3D Image Writes</a></li>
 <li><a href="#_work_group_collective_functions">Work Group Collective Functions</a></li>
 <li><a href="#_generic_address_space">Generic Address Space</a></li>
 <li><a href="#_language_features_that_were_already_optional">Language Features that Were Already Optional</a></li>
 </ul>
 </li>
 <li><a href="#_acknowledgements">Acknowledgements</a></li>
 </ul>
 </div>
 </div>
 <div id="content">
 <div id="preamble">
 <div class="sectionbody">
 <div style="page-break-after: always;"></div>
 <div class="paragraph">
 <p>Copyright 2008-2020 The Khronos Group.</p>
 </div>
 <div class="paragraph">
 <p>This specification is protected by copyright laws and contains material proprietary
 to the Khronos Group, Inc. Except as described by these terms, it or any components
 may not be reproduced, republished, distributed, transmitted, displayed, broadcast
 or otherwise exploited in any manner without the express prior written permission
 of Khronos Group.</p>
 </div>
 <div class="paragraph">
 <p>Khronos Group grants a conditional copyright license to use and reproduce the
 unmodified specification for any purpose, without fee or royalty, EXCEPT no licenses
 to any patent, trademark or other intellectual property rights are granted under
 these terms. Parties desiring to implement the specification and make use of
 Khronos trademarks in relation to that implementation, and receive reciprocal patent
 license protection under the Khronos IP Policy must become Adopters and confirm the
 implementation as conformant under the process defined by Khronos for this
 specification; see <a href="https://www.khronos.org/adopters" class="bare">https://www.khronos.org/adopters</a>.</p>
 </div>
 <div class="paragraph">
 <p>Khronos Group makes no, and expressly disclaims any, representations or warranties,
 express or implied, regarding this specification, including, without limitation:
 merchantability, fitness for a particular purpose, non-infringement of any
 intellectual property, correctness, accuracy, completeness, timeliness, and
 reliability. Under no circumstances will the Khronos Group, or any of its Promoters,
 Contributors or Members, or their respective partners, officers, directors,
 employees, agents or representatives be liable for any damages, whether direct,
 indirect, special or consequential damages for lost revenues, lost profits, or
 otherwise, arising from or in connection with these materials.</p>
 </div>
 <div class="paragraph">
 <p>Vulkan and Khronos are registered trademarks, and OpenXR, SPIR, SPIR-V, SYCL, WebGL,
 WebCL, OpenVX, OpenVG, EGL, COLLADA, glTF, NNEF, OpenKODE, OpenKCAM, StreamInput,
 OpenWF, OpenSL ES, OpenMAX, OpenMAX AL, OpenMAX IL, OpenMAX DL, OpenML and DevU are
 trademarks of the Khronos Group Inc. ASTC is a trademark of ARM Holdings PLC,
 OpenCL is a trademark of Apple Inc. and OpenGL and OpenML are registered trademarks
 and the OpenGL ES and OpenGL SC logos are trademarks of Silicon Graphics
 International used under license by Khronos. All other product names, trademarks,
 and/or company names are used solely for identification and belong to their
 respective owners.</p>
 </div>
 <div style="page-break-after: always;"></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_introduction"><a class="anchor" href="#_introduction"></a>1. Introduction</h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>Modern processor architectures have embraced parallelism as an important
 pathway to increased performance.
 Facing technical challenges with higher clock speeds in a fixed power
 envelope, Central Processing Units (CPUs) now improve performance by adding
 multiple cores.
 Graphics Processing Units (GPUs) have also evolved from fixed function
 rendering devices into programmable parallel processors.
 As todays computer systems often include highly parallel CPUs, GPUs and
 other types of processors, it is important to enable software developers to
 take full advantage of these heterogeneous processing platforms.</p>
 </div>
 <div class="paragraph">
 <p>Creating applications for heterogeneous parallel processing platforms is
 challenging as traditional programming approaches for multi-core CPUs and
 GPUs are very different.
 CPU-based parallel programming models are typically based on standards but
 usually assume a shared address space and do not encompass vector
 operations.
 General purpose GPU programming models address complex memory hierarchies
 and vector operations but are traditionally platform-, vendor- or
 hardware-specific.
 These limitations make it difficult for a developer to access the compute
 power of heterogeneous CPUs, GPUs and other types of processors from a
 single, multi-platform source code base.
 More than ever, there is a need to enable software developers to effectively
 take full advantage of heterogeneous processing platforms from high
 performance compute servers, through desktop computer systems to handheld
 devices - that include a diverse mix of parallel CPUs, GPUs and other
 processors such as DSPs and the Cell/B.E.
 processor.</p>
 </div>
 <div class="paragraph">
 <p><strong>OpenCL</strong> (Open Computing Language) is an open royalty-free standard for
 general purpose parallel programming across CPUs, GPUs and other processors,
 giving software developers portable and efficient access to the power of
 these heterogeneous processing platforms.</p>
 </div>
 <div class="paragraph">
 <p>OpenCL supports a wide range of applications, ranging from embedded and
 consumer software to HPC solutions, through a low-level, high-performance,
 portable abstraction.
 By creating an efficient, close-to-the-metal programming interface, OpenCL
 will form the foundation layer of a parallel computing ecosystem of
 platform-independent tools, middleware and applications.
 OpenCL is particularly suited to play an increasingly significant role in
 emerging interactive graphics applications that combine general parallel
 compute algorithms with graphics rendering pipelines.</p>
 </div>
 <div class="paragraph">
 <p>OpenCL consists of an API for coordinating parallel computation across
 heterogeneous processors, a cross-platform programming language, and a
 cross-platform intermediate language with a well-specified computation
 environment.
 The OpenCL standard:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Supports both data- and task-based parallel programming models</p>
 </li>
 <li>
 <p>Supports kernels written using a subset of ISO C99 with extensions
 for parallel execution</p>
 </li>
 <li>
 <p>Supports kernels represented by a portable and self-contained
 intermediate language (e.g. SPIR-V) with support for parallel execution</p>
 </li>
 <li>
 <p>Defines consistent numerical requirements based on IEEE 754</p>
 </li>
 <li>
 <p>Defines a configuration profile for handheld and embedded devices</p>
 </li>
 <li>
 <p>Supports efficient interop with OpenGL, OpenGL ES and other APIs</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>This document begins with an overview of basic concepts and the architecture
 of OpenCL, followed by a detailed description of its execution model, memory
 model and synchronization support.
 It then discusses the OpenCL platform and runtime API.
 Some examples are given that describe sample compute use-cases and how they
 would be written in OpenCL.
 The specification is divided into a core specification that any OpenCL
 compliant implementation must support; a handheld/embedded profile which
 relaxes the OpenCL compliance requirements for handheld and embedded
 devices; and a set of optional extensions that are likely to move into the
 core specification in later revisions of the OpenCL specification.</p>
 </div>
 <div class="sect2">
 <h3 id="_normative_references"><a class="anchor" href="#_normative_references"></a>1.1. Normative References</h3>
 <div class="paragraph">
 <p>Normative references are references to external documents or resources to
 which implementers of OpenCL must comply with all, or specified portions of,
 as described in this specification.</p>
 </div>
 <div id="iso-c11" class="paragraph">
 <p><em>ISO/IEC 9899:2011 - Information technology - Programming languages - C</em>,
 <a href="https://www.iso.org/standard/57853.html" class="bare">https://www.iso.org/standard/57853.html</a> (final specification),
 <a href="http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf" class="bare">http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf</a> (last public
 draft).</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="_version_numbers"><a class="anchor" href="#_version_numbers"></a>1.2. Version Numbers</h3>
 <div class="paragraph">
 <p>The OpenCL version number follows a <em>major.minor-revision</em> scheme.  When this
 version number is used within the API it generally only includes the
 <em>major.minor</em> components of the version number.</p>
 </div>
 <div class="paragraph">
 <p>A difference in the <em>major</em> or <em>minor</em> version number indicates that some
 amount of new functionality has been added to the specification, and may also
 include behavior changes and bug fixes.
 Functionality may also be deprecated or removed when the <em>major</em> or <em>minor</em>
 version changes.</p>
 </div>
 <div class="paragraph">
 <p>A difference in the <em>revision</em> number indicates small changes to the
 specification, typically to fix a bug or to clarify language.
 When the <em>revision</em> number changes there may be an impact on the behavior of
 existing functionality, but this should not affect backwards compatibility.
 Functionality should not be added or removed when the <em>revision</em> number
 changes.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="unified-spec"><a class="anchor" href="#unified-spec"></a>1.3. Unified Specification</h3>
 <div class="paragraph">
 <p>This document specifies all versions of the OpenCL API.</p>
 </div>
 <div class="paragraph">
 <p>There are three ways that an OpenCL feature may be described in terms of what
 versions of OpenCL support that feature.</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Missing before <em>major.minor</em>: Features that were introduced in
 version <em>major.minor</em>.  Implementations of an earlier version of OpenCL
 will not provide these features.</p>
 </li>
 <li>
 <p>Deprecated by <em>major.minor</em>: Features that were deprecated
 in version <em>major.minor</em>, see the definition of deprecation in the
 glossary.</p>
 </li>
 <li>
 <p>Universal: Features that have no mention of what version they are missing
 before or deprecated by are available in all versions of OpenCL.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_glossary"><a class="anchor" href="#_glossary"></a>2. Glossary</h2>
 <div class="sectionbody">
 <div class="dlist">
 <dl>
 <dt class="hdlist1">Application </dt>
 <dd>
 <p>The combination of the program running on the host and OpenCL devices.</p>
 </dd>
 <dt class="hdlist1">Acquire semantics </dt>
 <dd>
 <p>One of the memory order semantics defined for synchronization
 operations.
 Acquire semantics apply to atomic operations that load from memory.
 Given two units of execution, <strong>A</strong> and <strong>B</strong>, acting on a shared atomic
 object <strong>M</strong>, if <strong>A</strong> uses an atomic load of <strong>M</strong> with acquire semantics to
 synchronize-with an atomic store to <strong>M</strong> by <strong>B</strong> that used release
 semantics, then <strong>A</strong>'s atomic load will occur before any subsequent
 operations by <strong>A</strong>.
 Note that the memory orders <em>release</em>, <em>sequentially consistent</em>, and
 <em>acquire_release</em> all include <em>release semantics</em> and effectively pair
 with a load using acquire semantics.</p>
 </dd>
 <dt class="hdlist1">Acquire release semantics </dt>
 <dd>
 <p>A memory order semantics for synchronization operations (such as atomic
 operations) that has the properties of both acquire and release memory
 orders.
 It is used with read-modify-write operations.</p>
 </dd>
 <dt class="hdlist1">Atomic operations </dt>
 <dd>
 <p>Operations that at any point, and from any perspective, have either
 occurred completely, or not at all.
 Memory orders associated with atomic operations may constrain the
 visibility of loads and stores with respect to the atomic operations
 (see <em>relaxed semantics</em>, <em>acquire semantics</em>, <em>release semantics</em> or
 <em>acquire release semantics</em>).</p>
 </dd>
 <dt class="hdlist1">Blocking and Non-Blocking Enqueue API calls </dt>
 <dd>
 <p>A <em>non-blocking enqueue API call</em> places a <em>command</em> on a
 <em>command-queue</em> and returns immediately to the host.
 The <em>blocking-mode enqueue API calls</em> do not return to the host until
 the command has completed.</p>
 </dd>
 <dt class="hdlist1">Barrier </dt>
 <dd>
 <p>There are three types of <em>barriers</em> a command-queue barrier, a
 work-group barrier and a sub-group barrier.</p>
 <div class="openblock">
 <div class="content">
 <div class="ulist">
 <ul>
 <li>
 <p>The OpenCL API provides a function to enqueue a <em>command-queue</em>
 <em>barrier</em> command.
 This <em>barrier</em> command ensures that all previously enqueued commands to
 a command-queue have finished execution before any following <em>commands</em>
 enqueued in the <em>command-queue</em> can begin execution.</p>
 </li>
 <li>
 <p>The OpenCL kernel execution model provides built-in <em>work-group barrier</em>
 functionality.
 This <em>barrier</em> built-in function can be used by a <em>kernel</em> executing on
 a <em>device</em> to perform synchronization between <em>work-items</em> in a
 <em>work-group</em> executing the <em>kernel</em>.
 All the <em>work-items</em> of a <em>work-group</em> must execute the <em>barrier</em>
 construct before any are allowed to continue execution beyond the
 <em>barrier</em>.</p>
 </li>
 <li>
 <p>The OpenCL kernel execution model provides built-in <em>sub-group barrier</em>
 functionality.
 This <em>barrier</em> built-in function can be used by a <em>kernel</em> executing on
 a <em>device</em> to perform synchronization between <em>work-items</em> in a
 <em>sub-group</em> executing the <em>kernel</em>.
 All the <em>work-items</em> of a <em>sub-group</em> must execute the <em>barrier</em>
 construct before any are allowed to continue execution beyond the
 <em>barrier</em>.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 </dd>
 <dt class="hdlist1">Buffer Object </dt>
 <dd>
 <p>A memory object that stores a linear collection of bytes.
 Buffer objects are accessible using a pointer in a <em>kernel</em> executing on
 a <em>device</em>.
 Buffer objects can be manipulated by the host using OpenCL API calls.
 A <em>buffer object</em> encapsulates the following information:</p>
 <div class="openblock">
 <div class="content">
 <div class="ulist">
 <ul>
 <li>
 <p>Size in bytes.</p>
 </li>
 <li>
 <p>Properties that describe usage information and which region to allocate
 from.</p>
 </li>
 <li>
 <p>Buffer data.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 </dd>
 <dt class="hdlist1">Built-in Kernel </dt>
 <dd>
 <p>A <em>built-in kernel</em> is a <em>kernel</em> that is executed on an OpenCL <em>device</em>
 or <em>custom device</em> by fixed-function hardware or in firmware.
 <em>Applications</em> can query the <em>built-in kernels</em> supported by a <em>device</em>
 or <em>custom device</em>.
 A <em>program object</em> can only contain <em>kernels</em> written in OpenCL C or
 <em>built-in kernels</em> but not both.
 See also <em>Kernel</em> and <em>Program</em>.</p>
 </dd>
 <dt class="hdlist1">Child kernel </dt>
 <dd>
 <p>See <em>Device-side enqueue</em>.</p>
 </dd>
 <dt class="hdlist1">Command </dt>
 <dd>
 <p>The OpenCL operations that are submitted to a <em>command-queue</em> for
 execution.
 For example, OpenCL commands issue kernels for execution on a compute
 device, manipulate memory objects, etc.</p>
 </dd>
 <dt class="hdlist1">Command-queue </dt>
 <dd>
 <p>An object that holds <em>commands</em> that will be executed on a specific
 <em>device</em>.
 The <em>command-queue</em> is created on a specific <em>device</em> in a <em>context</em>.
 <em>Commands</em> to a <em>command-queue</em> are queued in-order but may be executed
 in-order or out-of-order.
 <em>Refer to In-order Execution_and_Out-of-order Execution</em>.</p>
 </dd>
 <dt class="hdlist1">Command-queue Barrier </dt>
 <dd>
 <p>See <em>Barrier</em>.</p>
 </dd>
 <dt class="hdlist1">Command synchronization </dt>
 <dd>
 <p>Constraints on the order that commands are launched for execution on a
 device defined in terms of the synchronization points that occur between
 commands in host command-queues and between commands in device-side
 command-queues.
 See <em>synchronization points</em>.</p>
 </dd>
 <dt class="hdlist1">Complete </dt>
 <dd>
 <p>The final state in the six state model for the execution of a command.
 The transition into this state occurs is signaled through event objects
 or callback functions associated with a command.</p>
 </dd>
 <dt class="hdlist1">Compute Device Memory </dt>
 <dd>
 <p>This refers to one or more memories attached to the compute device.</p>
 </dd>
 <dt class="hdlist1">Compute Unit </dt>
 <dd>
 <p>An OpenCL <em>device</em> has one or more <em>compute units</em>.
 A <em>work-group</em> executes on a single <em>compute unit</em>.
 A <em>compute unit</em> is composed of one or more <em>processing elements</em> and
 <em>local memory</em>.
 A <em>compute unit</em> may also include dedicated texture filter units that
 can be accessed by its processing elements.</p>
 </dd>
 <dt class="hdlist1">Concurrency </dt>
 <dd>
 <p>A property of a system in which a set of tasks in a system can remain
 active and make progress at the same time.
 To utilize concurrent execution when running a program, a programmer
 must identify the concurrency in their problem, expose it within the
 source code, and then exploit it using a notation that supports
 concurrency.</p>
 </dd>
 <dt class="hdlist1">Constant Memory </dt>
 <dd>
 <p>A region of <em>global memory</em> that remains constant during the execution
 of a <em>kernel</em>.
 The <em>host</em> allocates and initializes memory objects placed into
 <em>constant memory</em>.</p>
 </dd>
 <dt class="hdlist1">Context </dt>
 <dd>
 <p>The environment within which the kernels execute and the domain in which
 synchronization and memory management is defined.
 The <em>context</em> includes a set of <em>devices</em>, the memory accessible to
 those <em>devices</em>, the corresponding memory properties and one or more
 <em>command-queues</em> used to schedule execution of a <em>kernel(s)</em> or
 operations on <em>memory objects</em>.</p>
 </dd>
 <dt class="hdlist1">Control flow </dt>
 <dd>
 <p>The flow of instructions executed by a work-item.
 Multiple logically related work-items may or may not execute the same
 control flow.
 The control flow is said to be <em>converged</em> if all the work-items in the
 set execution the same stream of instructions.
 In a <em>diverged</em> control flow, the work-items in the set execute
 different instructions.
 At a later point, if a diverged control flow becomes converged, it is
 said to be a re-converged control flow.</p>
 </dd>
 <dt class="hdlist1">Converged control flow </dt>
 <dd>
 <p>See <em>Control flow</em>.</p>
 </dd>
 <dt class="hdlist1">Custom Device </dt>
 <dd>
 <p>An OpenCL <em>device</em> that fully implements the OpenCL Runtime but does not
 support <em>programs</em> written in OpenCL C.
 A custom device may be specialized non-programmable hardware that is
 very power efficient and performant for directed tasks or hardware with
 limited programmable capabilities such as specialized DSPs.
 Custom devices are not OpenCL conformant.
 Custom devices may support an online compiler.
 Programs for custom devices can be created using the OpenCL runtime APIs
 that allow OpenCL programs to be created from source (if an online
 compiler is supported) and/or binary, or from <em>built-in kernels</em>
 supported by the <em>device</em>.
 See also <em>Device</em>.</p>
 </dd>
 <dt class="hdlist1">Data Parallel Programming Model </dt>
 <dd>
 <p>Traditionally, this term refers to a programming model where concurrency
 is expressed as instructions from a single program applied to multiple
 elements within a set of data structures.
 The term has been generalized in OpenCL to refer to a model wherein a
 set of instructions from a single program are applied concurrently to
 each point within an abstract domain of indices.</p>
 </dd>
 <dt class="hdlist1">Data race </dt>
 <dd>
 <p>The execution of a program contains a data race if it contains two
 actions in different work-items or host threads where (1) one action
 modifies a memory location and the other action reads or modifies the
 same memory location, and (2) at least one of these actions is not
 atomic, or the corresponding memory scopes are not inclusive, and (3)
 the actions are global actions unordered by the global-happens-before
 relation or are local actions unordered by the local-happens before
 relation.</p>
 </dd>
 <dt class="hdlist1">Deprecation </dt>
 <dd>
 <p>Existing features are marked as deprecated if their usage is not
 recommended as that feature is being de-emphasized, superseded and may
 be removed from a future version of the specification.</p>
 </dd>
 <dt class="hdlist1">Device </dt>
 <dd>
 <p>A <em>device</em> is a collection of <em>compute units</em>.
 A <em>command-queue</em> is used to queue <em>commands</em> to a <em>device</em>.
 Examples of <em>commands</em> include executing <em>kernels</em>, or reading and
 writing <em>memory objects</em>.
 OpenCL devices typically correspond to a GPU, a multi-core CPU, and
 other processors such as DSPs and the Cell/B.E.
 processor.</p>
 </dd>
 <dt class="hdlist1">Device-side enqueue </dt>
 <dd>
 <p>A mechanism whereby a kernel-instance is enqueued by a kernel-instance
 running on a device without direct involvement by the host program.
 This produces <em>nested parallelism</em>; i.e. additional levels of
 concurrency are nested inside a running kernel-instance.
 The kernel-instance executing on a device (the <em>parent kernel</em>) enqueues
 a kernel-instance (the <em>child kernel</em>) to a device-side command queue.
 Child and parent kernels execute asynchronously though a parent kernel
 does not complete until all of its child-kernels have completed.</p>
 </dd>
 <dt class="hdlist1">Diverged control flow </dt>
 <dd>
 <p>See <em>Control flow</em>.</p>
 </dd>
 <dt class="hdlist1">Ended </dt>
 <dd>
 <p>The fifth state in the six state model for the execution of a command.
 The transition into this state occurs when execution of a command has
 ended.
 When a Kernel-enqueue command ends, all of the work-groups associated
 with that command have finished their execution.</p>
 </dd>
 <dt class="hdlist1">Event Object </dt>
 <dd>
 <p>An <em>event object</em> encapsulates the status of an operation such as a
 <em>command</em>.
 It can be used to synchronize operations in a context.</p>
 </dd>
 <dt class="hdlist1">Event Wait List </dt>
 <dd>
 <p>An <em>event wait list</em> is a list of <em>event objects</em> that can be used to
 control when a particular <em>command</em> begins execution.</p>
 </dd>
 <dt class="hdlist1">Fence </dt>
 <dd>
 <p>A memory ordering operation without an associated atomic object.
 A fence can use the <em>acquire semantics, release semantics</em>, or <em>acquire
 release semantics</em>.</p>
 </dd>
 <dt class="hdlist1">Framework </dt>
 <dd>
 <p>A software system that contains the set of components to support
 software development and execution.
 A <em>framework</em> typically includes libraries, APIs, runtime systems,
 compilers, etc.</p>
 </dd>
 <dt class="hdlist1">Generic address space </dt>
 <dd>
 <p>An address space that include the <em>private</em>, <em>local</em>, and <em>global</em>
 address spaces available to a device.
 The generic address space supports conversion of pointers to and from
 private, local and global address spaces, and hence lets a programmer
 write a single function that at compile time can take arguments from any
 of the three named address spaces.</p>
 </dd>
 <dt class="hdlist1">Global Happens before </dt>
 <dd>
 <p>See <em>Happens before</em>.</p>
 </dd>
 <dt class="hdlist1">Global ID </dt>
 <dd>
 <p>A <em>global ID</em> is used to uniquely identify a <em>work-item</em> and is derived
 from the number of <em>global work-items</em> specified when executing a
 <em>kernel</em>.
 The <em>global ID</em> is a N-dimensional value that starts at (0, 0, &#8230;&#8203; 0).
 See also <em>Local ID</em>.</p>
 </dd>
 <dt class="hdlist1">Global Memory </dt>
 <dd>
 <p>A memory region accessible to all <em>work-items</em> executing in a <em>context</em>.
 It is accessible to the <em>host</em> using <em>commands</em> such as read, write and
 map.
 <em>Global memory</em> is included within the <em>generic address space</em> that
 includes the private and local address spaces.</p>
 </dd>
 <dt class="hdlist1">GL share group </dt>
 <dd>
 <p>A <em>GL share group</em> object manages shared OpenGL or OpenGL ES resources
 such as textures, buffers, framebuffers, and renderbuffers and is
 associated with one or more GL context objects.
 The <em>GL share group</em> is typically an opaque object and not directly
 accessible.</p>
 </dd>
 <dt class="hdlist1">Handle </dt>
 <dd>
 <p>An opaque type that references an <em>object</em> allocated by OpenCL.
 Any operation on an <em>object</em> occurs by reference to that objects handle.</p>
 </dd>
 <dt class="hdlist1">Happens before </dt>
 <dd>
 <p>An ordering relationship between operations that execute on multiple
 units of execution.
 If an operation A happens-before operation B then A must occur before B;
 in particular, any value written by A will be visible to B.
 We define two separate happens before relations: <em>global-happens-before</em>
 and <em>local-happens-before</em>.
 These are defined in <a href="#memory-ordering-rules">Memory Ordering Rules</a>.</p>
 </dd>
 <dt class="hdlist1">Host </dt>
 <dd>
 <p>The <em>host</em> interacts with the <em>context</em> using the OpenCL API.</p>
 </dd>
 <dt class="hdlist1">Host-thread </dt>
 <dd>
 <p>The unit of execution that executes the statements in the host program.</p>
 </dd>
 <dt class="hdlist1">Host pointer </dt>
 <dd>
 <p>A pointer to memory that is in the virtual address space on the <em>host</em>.</p>
 </dd>
 <dt class="hdlist1">Illegal </dt>
 <dd>
 <p>Behavior of a system that is explicitly not allowed and will be reported
 as an error when encountered by OpenCL.</p>
 </dd>
 <dt class="hdlist1">Image Object </dt>
 <dd>
 <p>A <em>memory object</em> that stores a two- or three-dimensional structured
 array.
 Image data can only be accessed with read and write functions.
 The read functions use a <em>sampler</em>.</p>
 <div class="openblock">
 <div class="content">
 <div class="paragraph">
 <p>The <em>image object</em> encapsulates the following information:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Dimensions of the image.</p>
 </li>
 <li>
 <p>Description of each element in the image.</p>
 </li>
 <li>
 <p>Properties that describe usage information and which region to allocate
 from.</p>
 </li>
 <li>
 <p>Image data.</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>The elements of an image are selected from a list of predefined image
 formats.</p>
 </div>
 </div>
 </div>
 </dd>
 <dt class="hdlist1">Implementation Defined </dt>
 <dd>
 <p>Behavior that is explicitly allowed to vary between conforming
 implementations of OpenCL.
 An OpenCL implementor is required to document the implementation-defined
 behavior.</p>
 </dd>
 <dt class="hdlist1">Independent Forward Progress </dt>
 <dd>
 <p>If an entity supports independent forward progress, then if it is
 otherwise not dependent on any actions due to be performed by any other
 entity (for example it does not wait on a lock held by, and thus that
 must be released by, any other entity), then its execution cannot be
 blocked by the execution of any other entity in the system (it will not
 be starved).
 Work-items in a subgroup, for example, typically do not support
 independent forward progress, so one work-item in a subgroup may be
 completely blocked (starved) if a different work-item in the same
 subgroup enters a spin loop.</p>
 </dd>
 <dt class="hdlist1">In-order Execution </dt>
 <dd>
 <p>A model of execution in OpenCL where the <em>commands</em> in a <em>command-queue</em>
 are executed in order of submission with each <em>command</em> running to
 completion before the next one begins.
 See Out-of-order Execution.</p>
 </dd>
 <dt class="hdlist1">Intermediate Language </dt>
 <dd>
 <p>A lower-level language that may be used to create programs.
 SPIR-V is a required intermediate language (IL) for OpenCL 2.1 and 2.2 devices.
 Other OpenCL devices may optionally support SPIR-V or other ILs.</p>
 </dd>
 <dt class="hdlist1">Kernel </dt>
 <dd>
 <p>A <em>kernel</em> is a function declared in a <em>program</em> and executed on an
 OpenCL <em>device</em>.
 A <em>kernel</em> is identified by the <code>__kernel</code> or <code>kernel</code> qualifier applied to
 any function defined in a <em>program</em>.</p>
 </dd>
 <dt class="hdlist1">Kernel-instance </dt>
 <dd>
 <p>The work carried out by an OpenCL program occurs through the execution
 of kernel-instances on devices.
 The kernel instance is the <em>kernel object</em>, the values associated with
 the arguments to the kernel, and the parameters that define the
 <em>NDRange</em> index space.</p>
 </dd>
 <dt class="hdlist1">Kernel Object </dt>
 <dd>
 <p>A <em>kernel object</em> encapsulates a specific <em>kernel</em> function declared
 in a <em>program</em> and the argument values to be used when executing this
 <em>kernel</em> function.</p>
 </dd>
 <dt class="hdlist1">Kernel Language </dt>
 <dd>
 <p>A language that is used to represent source code for kernel.
 Kernels may be directly created from OpenCL C kernel language
 source strings.
 Other kernel languages may be supported by compiling to SPIR-V,
 another supported Intermediate Language, or to a device-specific
 program binary format.</p>
 </dd>
 <dt class="hdlist1">Launch </dt>
 <dd>
 <p>The transition of a command from the <em>submitted</em> state to the <em>ready</em>
 state.
 See <em>Ready</em>.</p>
 </dd>
 <dt class="hdlist1">Local ID </dt>
 <dd>
 <p>A <em>local ID</em> specifies a unique <em>work-item ID</em> within a given
 <em>work-group</em> that is executing a <em>kernel</em>.
 The <em>local ID</em> is a N-dimensional value that starts at (0, 0, &#8230;&#8203; 0).
 See also <em>Global ID</em>.</p>
 </dd>
 <dt class="hdlist1">Local Memory </dt>
 <dd>
 <p>A memory region associated with a <em>work-group</em> and accessible only by
 <em>work-items</em> in that <em>work-group</em>.
 <em>Local memory</em> is included within the <em>generic address space</em> that
 includes the private and global address spaces.</p>
 </dd>
 <dt class="hdlist1">Marker </dt>
 <dd>
 <p>A <em>command</em> queued in a <em>command-queue</em> that can be used to tag all
 <em>commands</em> queued before the <em>marker</em> in the <em>command-queue</em>.
 The <em>marker</em> command returns an <em>event</em> which can be used by the
 <em>application</em> to queue a wait on the marker event i.e. wait for all
 commands queued before the <em>marker</em> command to complete.</p>
 </dd>
 <dt class="hdlist1">Memory Consistency Model </dt>
 <dd>
 <p>Rules that define which values are observed when multiple units of
 execution load data from any shared memory plus the synchronization
 operations that constrain the order of memory operations and define
 synchronization relationships.
 The memory consistency model in OpenCL is based on the memory model from
 the ISO C11 programming language.</p>
 </dd>
 <dt class="hdlist1">Memory Objects </dt>
 <dd>
 <p>A <em>memory object</em> is a handle to a reference counted region of <em>Global
 Memory</em>.
 Also see <em>Buffer Object</em> and <em>Image Object</em>.</p>
 </dd>
 <dt class="hdlist1">Memory Regions (or Pools) </dt>
 <dd>
 <p>A distinct address space in OpenCL.
 <em>Memory regions</em> may overlap in physical memory though OpenCL will treat
 them as logically distinct.
 The <em>memory regions</em> are denoted as <em>private</em>, <em>local</em>, <em>constant,</em> and
 <em>global</em>.</p>
 </dd>
 <dt class="hdlist1">Memory Scopes </dt>
 <dd>
 <p>These memory scopes define a hierarchy of visibilities when analyzing
 the ordering constraints of memory operations.
 They are defined by the values of the <strong>memory_scope</strong> enumeration
 constant.
 Current values are <strong>memory_scope_work_item</strong> (memory constraints only
 apply to a single work-item and in practice apply only to image
 operations), <strong>memory_scope_sub_group</strong> (memory-ordering constraints only
 apply to work-items executing in a sub-group), <strong>memory_scope_work_group</strong>
 (memory-ordering constraints only apply to work-items executing in a
 work-group), <strong>memory_scope_device</strong> (memory-ordering constraints only
 apply to work-items executing on a single device) and
 <strong>memory_scope_all_svm_devices</strong> (memory-ordering constraints only apply
 to work-items executing across multiple devices and when using shared
 virtual memory).</p>
 </dd>
 <dt class="hdlist1">Modification Order </dt>
 <dd>
 <p>All modifications to a particular atomic object M occur in some
 particular <em>total order</em>, called the <em>modification order</em> of M.
 If A and B are modifications of an atomic object M, and A happens-before
 B, then A shall precede B in the modification order of M.
 Note that the modification order of an atomic object M is independent of
 whether M is in local or global memory.</p>
 </dd>
 <dt class="hdlist1">Nested Parallelism </dt>
 <dd>
 <p>See <em>device-side enqueue</em>.</p>
 </dd>
 <dt class="hdlist1">Object </dt>
 <dd>
 <p>Objects are abstract representation of the resources that can be
 manipulated by the OpenCL API.
 Examples include <em>program objects</em>, <em>kernel objects</em>, and <em>memory
 objects</em>.</p>
 </dd>
 <dt class="hdlist1">Out-of-Order Execution </dt>
 <dd>
 <p>A model of execution in which <em>commands</em> placed in the <em>work queue</em> may
 begin and complete execution in any order consistent with constraints
 imposed by <em>event wait lists_and_command-queue barrier</em>.
 See <em>In-order Execution</em>.</p>
 </dd>
 <dt class="hdlist1">Parent device </dt>
 <dd>
 <p>The OpenCL <em>device</em> which is partitioned to create <em>sub-devices</em>.
 Not all <em>parent devices</em> are <em>root devices</em>.
 A <em>root device</em> might be partitioned and the <em>sub-devices</em> partitioned
 again.
 In this case, the first set of <em>sub-devices</em> would be <em>parent devices</em>
 of the second set, but not the <em>root devices</em>.
 Also see <em>Device</em>, <em>parent device</em> and <em>root device</em>.</p>
 </dd>
 <dt class="hdlist1">Parent kernel </dt>
 <dd>
 <p>see <em>Device-side enqueue</em>.</p>
 </dd>
 <dt class="hdlist1">Pipe </dt>
 <dd>
 <p>The <em>pipe</em> memory object conceptually is an ordered sequence of data
 items.
 A pipe has two endpoints: a write endpoint into which data items are
 inserted, and a read endpoint from which data items are removed.
 At any one time, only one kernel instance may write into a pipe, and
 only one kernel instance may read from a pipe.
 To support the producer consumer design pattern, one kernel instance
 connects to the write endpoint (the producer) while another kernel
 instance connects to the reading endpoint (the consumer).</p>
 </dd>
 <dt class="hdlist1">Platform </dt>
 <dd>
 <p>The <em>host</em> plus a collection of <em>devices</em> managed by the OpenCL
 <em>framework</em> that allow an application to share <em>resources</em> and execute
 <em>kernels</em> on <em>devices</em> in the <em>platform</em>.</p>
 </dd>
 <dt class="hdlist1">Private Memory </dt>
 <dd>
 <p>A region of memory private to a <em>work-item</em>.
 Variables defined in one <em>work-items</em> <em>private memory</em> are not visible
 to another <em>work-item</em>.</p>
 </dd>
 <dt class="hdlist1">Processing Element </dt>
 <dd>
 <p>A virtual scalar processor.
 A work-item may execute on one or more processing elements.</p>
 </dd>
 <dt class="hdlist1">Program </dt>
 <dd>
 <p>An OpenCL <em>program</em> consists of a set of <em>kernels</em>.
 <em>Programs</em> may also contain auxiliary functions called by the
 <em>kernel</em> functions and constant data.</p>
 </dd>
 <dt class="hdlist1">Program Object </dt>
 <dd>
 <p>A <em>program object</em> encapsulates the following information:</p>
 <div class="openblock">
 <div class="content">
 <div class="ulist">
 <ul>
 <li>
 <p>A reference to an associated <em>context</em>.</p>
 </li>
 <li>
 <p>A <em>program</em> source or binary.</p>
 </li>
 <li>
 <p>The latest successfully built program executable, the list of <em>devices</em>
 for which the program executable is built, the build options used and a
 build log.</p>
 </li>
 <li>
 <p>The number of <em>kernel objects</em> currently attached.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 </dd>
 <dt class="hdlist1">Queued </dt>
 <dd>
 <p>The first state in the six state model for the execution of a command.
 The transition into this state occurs when the command is enqueued into
 a command-queue.</p>
 </dd>
 <dt class="hdlist1">Ready </dt>
 <dd>
 <p>The third state in the six state model for the execution of a command.
 The transition into this state occurs when pre-requisites constraining
 execution of a command have been met; i.e. the command has been
 launched.
 When a kernel-enqueue command is launched, work-groups associated with
 the command are placed in a devices work-pool from which they are
 scheduled for execution.</p>
 </dd>
 <dt class="hdlist1">Re-converged Control Flow </dt>
 <dd>
 <p>see <em>Control flow</em>.</p>
 </dd>
 <dt class="hdlist1">Reference Count </dt>
 <dd>
 <p>The life span of an OpenCL object is determined by its <em>reference
 count</em>, an internal count of the number of references to the object.
 When you create an object in OpenCL, its <em>reference count</em> is set to
 one.
 Subsequent calls to the appropriate <em>retain</em> API (such as
 <a href="#clRetainContext"><strong>clRetainContext</strong></a>, <a href="#clRetainCommandQueue"><strong>clRetainCommandQueue</strong></a>) increment the <em>reference
 count</em>.
 Calls to the appropriate <em>release</em> API (such as <a href="#clReleaseContext"><strong>clReleaseContext</strong></a>,
 <a href="#clReleaseCommandQueue"><strong>clReleaseCommandQueue</strong></a>) decrement the <em>reference count</em>.
 Implementations may also modify the <em>reference count</em>, e.g. to track
 attached objects or to ensure correct operation of in-progress or
 scheduled activities.
 The object becomes inaccessible to host code when the number of
 <em>release</em> operations performed matches the number of <em>retain</em> operations
 plus the allocation of the object.
 At this point the reference count may be zero but this is not
 guaranteed.</p>
 </dd>
 <dt class="hdlist1">Relaxed Consistency </dt>
 <dd>
 <p>A memory consistency model in which the contents of memory visible to
 different <em>work-items</em> or <em>commands</em> may be different except at a
 <em>barrier</em> or other explicit synchronization points.</p>
 </dd>
 <dt class="hdlist1">Relaxed Semantics </dt>
 <dd>
 <p>A memory order semantics for atomic operations that implies no order
 constraints.
 The operation is <em>atomic</em> but it has no impact on the order of memory
 operations.</p>
 </dd>
 <dt class="hdlist1">Release Semantics </dt>
 <dd>
 <p>One of the memory order semantics defined for synchronization
 operations.
 Release semantics apply to atomic operations that store to memory.
 Given two units of execution, <strong>A</strong> and <strong>B</strong>, acting on a shared atomic
 object <strong>M</strong>, if <strong>A</strong> uses an atomic store of <strong>M</strong> with release semantics to
 synchronize-with an atomic load to <strong>M</strong> by <strong>B</strong> that used acquire
 semantics, then <strong>A</strong>'s atomic store will occur <em>after</em> any prior
 operations by <strong>A</strong>.
 Note that the memory orders <em>acquire</em>, <em>sequentially consistent</em>, and
 <em>acquire_release</em> all include <em>acquire semantics</em> and effectively pair
 with a store using release semantics.</p>
 </dd>
 <dt class="hdlist1">Remainder work-groups </dt>
 <dd>
 <p>When the work-groups associated with a kernel-instance are defined, the
 sizes of a work-group in each dimension may not evenly divide the size
 of the NDRange in the corresponding dimensions.
 The result is a collection of work-groups on the boundaries of the
 NDRange that are smaller than the base work-group size.
 These are known as <em>remainder work-groups</em>.</p>
 </dd>
 <dt class="hdlist1">Running </dt>
 <dd>
 <p>The fourth state in the six state model for the execution of a command.
 The transition into this state occurs when the execution of the command
 starts.
 When a Kernel-enqueue command starts, one or more work-groups associated
 with the command start to execute.</p>
 </dd>
 <dt class="hdlist1">Root device </dt>
 <dd>
 <p>A <em>root device</em> is an OpenCL <em>device</em> that has not been partitioned.
 Also see <em>Device</em>, <em>Parent device</em> and <em>Root device</em>.</p>
 </dd>
 <dt class="hdlist1">Resource </dt>
 <dd>
 <p>A class of <em>objects</em> defined by OpenCL.
 An instance of a <em>resource</em> is an <em>object</em>.
 The most common <em>resources</em> are the <em>context</em>, <em>command-queue</em>, <em>program
 objects</em>, <em>kernel objects</em>, and <em>memory objects</em>.
 Computational resources are hardware elements that participate in the
 action of advancing a program counter.
 Examples include the <em>host</em>, <em>devices</em>, <em>compute units</em> and <em>processing
 elements</em>.</p>
 </dd>
 <dt class="hdlist1">Retain, Release </dt>
 <dd>
 <p>The action of incrementing (retain) and decrementing (release) the
 reference count using an OpenCL <em>object</em>.
 This is a book keeping functionality to make sure the system doesn&#8217;t
 remove an <em>object</em> before all instances that use this <em>object</em> have
 finished.
 Refer to <em>Reference Count</em>.</p>
 </dd>
 <dt class="hdlist1">Sampler </dt>
 <dd>
 <p>An <em>object</em> that describes how to sample an image when the image is read
 in the <em>kernel</em>.
 The image read functions take a <em>sampler</em> as an argument.
 The <em>sampler</em> specifies the image addressing-mode i.e. how out-of-range
 image coordinates are handled, the filter mode, and whether the input
 image coordinate is a normalized or unnormalized value.</p>
 </dd>
 <dt class="hdlist1">Scope inclusion </dt>
 <dd>
 <p>Two actions <strong>A</strong> and <strong>B</strong> are defined to have an inclusive scope if they
 have the same scope <strong>P</strong> such that: (1) if <strong>P</strong> is
 <strong>memory_scope_sub_group</strong>, and <strong>A</strong> and <strong>B</strong> are executed by work-items
 within the same sub-group, or (2) if <strong>P</strong> is <strong>memory_scope_work_group</strong>,
 and <strong>A</strong> and <strong>B</strong> are executed by work-items within the same work-group,
 or (3) if <strong>P</strong> is <strong>memory_scope_device</strong>, and <strong>A</strong> and <strong>B</strong> are executed by
 work-items on the same device, or (4) if <strong>P</strong> is
 <strong>memory_scope_all_svm_devices</strong>, if <strong>A</strong> and <strong>B</strong> are executed by host
 threads or by work-items on one or more devices that can share SVM
 memory with each other and the host process.</p>
 </dd>
 <dt class="hdlist1">Sequenced before </dt>
 <dd>
 <p>A relation between evaluations executed by a single unit of execution.
 Sequenced-before is an asymmetric, transitive, pair-wise relation that
 induces a partial order between evaluations.
 Given any two evaluations A and B, if A is sequenced-before B, then the
 execution of A shall precede the execution of B.</p>
 </dd>
 <dt class="hdlist1">Sequential consistency </dt>
 <dd>
 <p>Sequential consistency interleaves the steps executed by each unit of
 execution.
 Each access to a memory location sees the last assignment to that
 location in that interleaving.</p>
 </dd>
 <dt class="hdlist1">Sequentially consistent semantics </dt>
 <dd>
 <p>One of the memory order semantics defined for synchronization
 operations.
 When using sequentially-consistent synchronization operations, the loads
 and stores within one unit of execution appear to execute in program
 order (i.e., the sequenced-before order), and loads and stores from
 different units of execution appear to be simply interleaved.</p>
 </dd>
 <dt class="hdlist1">Shared Virtual Memory (SVM) </dt>
 <dd>
 <p>An address space exposed to both the host and the devices within a
 context.
 SVM causes addresses to be meaningful between the host and all of the
 devices within a context and therefore supports the use of pointer based
 data structures in OpenCL kernels.
 It logically extends a portion of the global memory into the host
 address space therefore giving work-items access to the host address
 space.
 There are three types of SVM in OpenCL:</p>
 <div class="openblock">
 <div class="content">
 <div class="dlist">
 <dl>
 <dt class="hdlist1"><em>Coarse-Grained buffer SVM</em> </dt>
 <dd>
 <p>Sharing occurs at the granularity of regions of OpenCL buffer memory
 objects.</p>
 </dd>
 <dt class="hdlist1"><em>Fine-Grained buffer SVM</em> </dt>
 <dd>
 <p>Sharing occurs at the granularity of individual loads/stores into bytes
 within OpenCL buffer memory objects.</p>
 </dd>
 <dt class="hdlist1"><em>Fine-Grained system SVM</em> </dt>
 <dd>
 <p>Sharing occurs at the granularity of individual loads/stores into bytes
 occurring anywhere within the host memory.</p>
 </dd>
 </dl>
 </div>
 </div>
 </div>
 </dd>
 <dt class="hdlist1">SIMD </dt>
 <dd>
 <p>Single Instruction Multiple Data.
 A programming model where a <em>kernel</em> is executed concurrently on
 multiple <em>processing elements</em> each with its own data and a shared
 program counter.
 All <em>processing elements</em> execute a strictly identical set of
 instructions.</p>
 </dd>
 <dt class="hdlist1">Specialization constants </dt>
 <dd>
 <p>Specialization constants are special constant objects that do not
 have known constant values in an intermediate language (e.g. SPIR-V).
 Applications may provide updated values for the specialization constants
 before a program is built.
 Specialization constants that do not receive a value from an application
 shall use the default specialization constant value.</p>
 </dd>
 <dt class="hdlist1">SPMD </dt>
 <dd>
 <p>Single Program Multiple Data.
 A programming model where a <em>kernel</em> is executed concurrently on
 multiple <em>processing elements</em> each with its own data and its own
 program counter.
 Hence, while all computational resources run the same <em>kernel</em> they
 maintain their own instruction counter and due to branches in a
 <em>kernel</em>, the actual sequence of instructions can be quite different
 across the set of <em>processing elements</em>.</p>
 </dd>
 <dt class="hdlist1">Sub-device </dt>
 <dd>
 <p>An OpenCL <em>device</em> can be partitioned into multiple <em>sub-devices</em>.
 The new <em>sub-devices</em> alias specific collections of compute units within
 the parent <em>device</em>, according to a partition scheme.
 The <em>sub-devices</em> may be used in any situation that their parent
 <em>device</em> may be used.
 Partitioning a <em>device</em> does not destroy the parent <em>device</em>, which may
 continue to be used along side and intermingled with its child
 <em>sub-devices</em>.
 Also see <em>Device</em>, <em>Parent device</em> and <em>Root device</em>.</p>
 </dd>
 <dt class="hdlist1">Sub-group </dt>
 <dd>
 <p>Sub-groups are an implementation-dependent grouping of work-items within
 a work-group.
 The size and number of sub-groups is implementation-defined.</p>
 </dd>
 <dt class="hdlist1">Sub-group Barrier </dt>
 <dd>
 <p>See <em>Barrier</em>.</p>
 </dd>
 <dt class="hdlist1">Submitted </dt>
 <dd>
 <p>The second state in the six state model for the execution of a command.
 The transition into this state occurs when the command is flushed from
 the command-queue and submitted for execution on the device.
 Once submitted, a programmer can assume a command will execute once its
 prerequisites have been met.</p>
 </dd>
 <dt class="hdlist1">SVM Buffer </dt>
 <dd>
 <p>A memory allocation enabled to work with <em>Shared Virtual Memory (SVM)</em>.
 Depending on how the SVM buffer is created, it can be a coarse-grained
 or fine-grained SVM buffer.
 Optionally it may be wrapped by a <em>Buffer Object</em>.
 See <em>Shared Virtual Memory (SVM)</em>.</p>
 </dd>
 <dt class="hdlist1">Synchronization </dt>
 <dd>
 <p>Synchronization refers to mechanisms that constrain the order of
 execution and the visibility of memory operations between two or more
 units of execution.</p>
 </dd>
 <dt class="hdlist1">Synchronization operations </dt>
 <dd>
 <p>Operations that define memory order constraints in a program.
 They play a special role in controlling how memory operations in one
 unit of execution (such as work-items or, when using SVM a host thread)
 are made visible to another.
 Synchronization operations in OpenCL include <em>atomic operations</em> and
 <em>fences</em>.</p>
 </dd>
 <dt class="hdlist1">Synchronization point </dt>
 <dd>
 <p>A synchronization point between a pair of commands (A and B) assures
 that results of command A happens-before command B is launched (i.e.
 enters the ready state) .</p>
 </dd>
 <dt class="hdlist1">Synchronizes with </dt>
 <dd>
 <p>A relation between operations in two different units of execution that
 defines a memory order constraint in global memory
 (<em>global-synchronizes-with</em>) or local memory
 (<em>local-synchronizes-with</em>).</p>
 </dd>
 <dt class="hdlist1">Task Parallel Programming Model </dt>
 <dd>
 <p>A programming model in which computations are expressed in terms of
 multiple concurrent tasks executing in one or more <em>command-queues</em>.
 The concurrent tasks can be running different <em>kernels</em>.</p>
 </dd>
 <dt class="hdlist1">Thread-safe </dt>
 <dd>
 <p>An OpenCL API call is considered to be <em>thread-safe</em> if the internal
 state as managed by OpenCL remains consistent when called simultaneously
 by multiple <em>host</em> threads.
 OpenCL API calls that are <em>thread-safe</em> allow an application to call
 these functions in multiple <em>host</em> threads without having to implement
 mutual exclusion across these <em>host</em> threads i.e. they are also
 re-entrant-safe.</p>
 </dd>
 <dt class="hdlist1">Undefined </dt>
 <dd>
 <p>The behavior of an OpenCL API call, built-in function used inside a
 <em>kernel</em> or execution of a <em>kernel</em> that is explicitly not defined by
 OpenCL.
 A conforming implementation is not required to specify what occurs when
 an undefined construct is encountered in OpenCL.</p>
 </dd>
 <dt class="hdlist1">Unit of execution </dt>
 <dd>
 <p>A generic term for a process, OS managed thread running on the host (a
 host-thread), kernel-instance, host program, work-item or any other
 executable agent that advances the work associated with a program.</p>
 </dd>
 <dt class="hdlist1">Work-group </dt>
 <dd>
 <p>A collection of related <em>work-items</em> that execute on a single <em>compute
 unit</em>.
 The <em>work-items</em> in the group execute the same <em>kernel-instance</em> and
 share <em>local</em> <em>memory</em> and <em>work-group functions</em>.</p>
 </dd>
 <dt class="hdlist1">Work-group Barrier </dt>
 <dd>
 <p>See <em>Barrier</em>.</p>
 </dd>
 <dt class="hdlist1">Work-group Function </dt>
 <dd>
 <p>A function that carries out collective operations across all the
 work-items in a work-group.
 Available collective operations are a barrier, reduction, broadcast,
 prefix sum, and evaluation of a predicate.
 A work-group function must occur within a <em>converged control flow</em>; i.e.
 all work-items in the work-group must encounter precisely the same
 work-group function.</p>
 </dd>
 <dt class="hdlist1">Work-group Synchronization </dt>
 <dd>
 <p>Constraints on the order of execution for work-items in a single
 work-group.</p>
 </dd>
 <dt class="hdlist1">Work-pool </dt>