OpenCL memory object 之 Global memory (2)
当我们用clCreateBuffer, clCreateImage创建OpenCL memory object时候，我们需要输入一个flag参数，这个参数决定memory object的位置。
cl_mem clCreateBuffer (cl_context context,
cl_mem_flags flags,
size_t size,
void *host_ptr,
cl_int *errcode_ret) ;
cl_mem clCreateImage2D (cl_context context,
cl_mem_flags flags,
const cl_image_format *image_format,
size_t image_width,
size_t image_height,
size_t image_row_pitch,
void *host_ptr,
cl_int *errcode_ret)
创建memory object后，并没有立即给它分配空间，而是在第一次device2device之间copy数据时候，才会真正的分配空间，所以我们经常会感觉到，第一次使用某个memory object时候会比较慢。
在AMD APP 2.5中，根据flag值，memory object分配位置如下表4.3所示：
注意AMD 扩展flag： CL_MEM_USE_PERSISTENT_MEM_AMD中，把memory object创建在host visible device memory中，这样实现了zero copy操作。
我们能够用函数clEnqueueMapBuffer把device memory object映射到host memory空间，以便cpu进行处理，处理完后，我们要调用clEnqueueUnmapMemObject进行反映射操作，以便device能继续访问memory object，注意：在map期间，device不能访问。
下面我们了解一个重要的概念：zero copy memory ojbect以及copy memory object
memory object位于host memory，或者位于device meory，但是host能够直接访问，这样的memory object称作zero copy memory object，因为数据从来没有在host和device之间进行过实际传输，但host和device都能直接访问它。
如果memory object在device上，需要在host和device之间进行to and from传输操作，这种memory object称作copy memory object。
注意CL_MEM_USE_PERSISTENT_MEM_AMD 和CL_MEM_ALLOC_HOST_PTR的不同之处，前者创建device驻留的zero copy memory，后者创建host驻留的zero copy memory。
使用zero copy memory时候，clEnqueueMapBuffer/clEnqueueMapImage/clEnqueueUnmapMemObject 操作并不产生实际的传输操作，所以速度很快，但是对于同一个zero memory object，每次runtime都会返回不同的指针值。
当device以sparse（稀疏）方式访问host memory时，驻留host的zero copy memory object也能提高程序performance，但要注意：此时，传输数据的代价一定大于slower的直接访问代价。
host能够以host<->device数据传输带宽速度对驻留device的zero copy memory进行写操作（combined write），所以当host不需要读memory object的时候，我们可以使用zero copy device memory避免数据传输操作。注意：zero copy device驻留images也是支持的，但zero copy host 驻留images不被支持。linux也不支持zero copy memory object。
对于copy模式的memory object， 一般都位于device momeroy，需要在host和device之间来回传输数据。注意：实际上只传输memory object被request部分数据，这样提高传输性能。
对于使用缺省方式创建的memory object，clEnqueueMapBuffer/clEnqueueMapImage每次返回的指针可能不同，因为runtime每次映射的host memory区域不同，但对于用CL_MEM_USE_HOST_PTR和CL_MEM_ALLOC_HOST_PTR 方式创建的memory object，每次返回的指针是一样的，因为每次都是返回相同的映射位置，而且对于这两种方式创建的memory object，每次传输前，runtime都要track当前位置是否是最新的memory object，以便决定是否传输。[注：缺省方式创建的memory object不能被tracker，因为每次位置都不同,所以总要执行传输操作]。
对于用CL_MEM_USE_HOST_PTR创建的memory object，clCreateBuffer/clCreateImage 每次都要对分配的内存执行pinned操作，删除memory object后，还要执行unpinned操作。为了最小化pinned/unpinned的代价，分配的内存应该4K对齐，这样不用每次map/unmap都做pin/unpin操作,但是这样做确实浪费了一些空间。如果host memory object需要频繁进行map操作，建议使用CL_MEM_ALLOC_HOST_PTR和CL_MEM_COPY_HOST_PTR，相应的，如果device memory需要频繁map，使用CL_MEM_USE_PERSISTENT_MEM_AMD以及clEnqueueWriteBuffer。
注：当用CL_MEM_ALLOC_HOST_PTR和CL_MEM_COPY_HOST_PTR指针创建memory object时候，memory实际上被创建在pinned host memory中，并初始化数据。CL_MEM_COPY_HOST_PTR相比于CL_MEM_ALLOC_HOST_PTR多了一个把初始化后的数据copy到device memory中的操作，并不推荐这样使用，还是第一次使用时再传输效率更高。
images 对象传输需要额外的costs，因为images必须在线性地址模式（host使用）和tile地址模式（device使用）之间转换。
Read/Write/Map memory object的时候，我们要尽量使用non-blocking命令方式，这样，命令都在缓冲中排队，通过flush(clFlush)操作，以大批次的方式传输到GPU，分摊了runtime准备和提交数据到GPU的开销。我们能够用event机制来决定操作之间的依赖关系。目前，runtime还没有完全挖掘异步DMA传输的潜力，但是我们保持正确的编码是需要的，一旦dirver提供了支持，我们就能提高程序性能。
