基于KerplerGPU的Grid内移动对象的更新查询

1，Tesla k40c介绍

GPU型号为NVIDIA Tesla k40c,采用最新的Kepler架构GK110图形处理器；

基本参数：

流处理器（Stream Multiprocessor, SM)个数：15 ；

CUDA核心数：每个SM拥有192个CUDA核心，总计15*192=2880个CUDA核心
；

计算能力（Compute Capability): 3.5 ；

设备内存（Device Memory): 12GB ；

双精度浮点性能：1.43Tflops ；

单精度浮点性能：4.29Tflops ；

显存带宽：288GB/s,支持PCI-E3.0,采用GDDR5,速度是GDDR3的4倍
；

与之比较普通主机内存DDR3带宽不到20GB/s; 因此GPU无论是并处计算能力还是数据传输能力都碾压CPU和内存；

架构图示：



上8下7总计15个流处理器（SMX)，每个SMX包含16*12=192个CUDA核心，每个SMX内靠近L2 Cache部分为64KB
Shared Memory / L1 Cache，远离L2 Cache部分为寄存器文件，两者为整个block内所有线程共享；中间的L2
Cache为所有SMX共享。

Kepler架构与上一代Fermi架构参数对比：

2，Grid内移动对象的数据结构表示

采用三层嵌套：Grid -> Cell -> Bucket ->Object ，可以实现从Grid遍历么一个对象；

二级索引SecIndex: 一个索引数组，元素为对象所在Grid内的Cell号idx_cell, 所在Cell内的Bucket偏移idx_bkt,
所在Bucket内的偏移idx_obj, 可以实现对象位置信息的快速提取，进而通过Grid找到对象；

Grid内对象组织结构：



存放对象位置信息的二级索引：

3，通过原子操作和RCU实现更新与更新、更新与查询的无锁操作

CUDA内含有的原子操作如__iAtomicAdd(), __iAtomicCAS(), 应用于分发进程对更新请求的分解/聚类，实现多个更新进程对相同Cell的更新缓冲区的非阻塞访问，极大减少了同步开销。

RCU, Read-Copy Update, 写拷贝更新，通过对更新进程、查询进程各维护一份格网对象索引，实现更新进程与查询进程的并行执行，这回一定程度延迟对象的写操作，但鉴于GPU卓越的更新性能，可以容忍的。

4，下面介绍基于CPU+GPU异构平台下格网内移动对象并行处理框架



更新过程和查询过程皆采用周期性分段批处理机制，在每个更新周期里，格网索引从主机端(Host端，即CPU和内存)拷贝到设备端(Device端，即GPU和显存)，即图中Grid1->Grid3，更新请求片段由主机端经分解与聚类处理存放到更新缓冲区中，然后交由更新线程并行处理并更新设备端的格网索引，最后将更新后的格网索引拷贝回主机端(图中Grid3->Grid1)，同时利用更新后的主机端格网索引覆盖查询操作的格网索引(图中Grid1->Grid2)，即RCU机制。在每个查询周期里，主机端首先对查询请求范围进行判断，选择相对应的VLSQ, LSQ与SSQ查询策略，如果选择的VLSQ策略，则进入图2中大查询的执行分支，输出查询请求边缘部分覆盖的Cell，然后将完全覆盖的Cell写入到Cell聚类队列进行汇总，最后一次性输出给所有涉及的请求；如果选择的LSQ或SSQ策略，则进入图中小查询的执行分支，分别输出查询请求完全覆盖Cell和部分覆盖Cell的全部对象，此处请求之间相互独立，不进行Cell查询汇总。

5 处理结果
采用CPU-GPU异构架构处理格网内移动对象与CPU相比，在不通的格网尺度下和对象移动速度下，更新速度平均提升了9倍；在不同格网尺度和查询范围下，查询速度提升了7倍。