GPGPU的体系结构

自2006年NVIDIA公司和AMD公司两个主要GPU生产商推出统一渲染GPU架构至今,统一渲染GPU架构的体系结构不断得到改进和革新,以致短短几年时间内GPU的性能飞速提升。

    NVIDIA公司推出的三代GPGPU体系结构分别为G80、GT200和Fermi。GT200在G80的基础上提高了硬件计算资源和计算功能,并在存储层次和硬件比例配置方面做出了优化和改进。Femi则对G80体系结构进行了许多革新,引入了新的体系结构特征。

G80系列是NVIDIA公司最早推出的统一架构GPU,G80体系结构从总体上来说可以分成两个组成部分,分别是流处理器阵列(stream processor array,SPA)和存储系统。这两个部分是由一个片上交叉互联网络连接,因此,该体系结构具有良好的扩展性。

    统一结构中的基本计算单元被称为流多处理器(streaming multiprocessors,SsM)SM是GPU最底层的独立硬件结构,可以把它看成一个SIMD处理単元。共有16个SM,每个SM又包括8个流处理器(streaming processor,SP)和两个特殊功能单元(special function unit,SFU)。此外,每个SM中还包含一个16KB大小的共享存储器(shared memory),用来实现同一线程块中的线程共享数据和通信。共享存储器采用的是显式访存模式,在没有冲突的情况下,访存速度接近于寄存器的访问速度。SM上还包括8192个32位寄存器,在执行时分配给每个线程。在G80体系结构中,每两个SM组成了一个线程处理簇(thread processing cluster,,TPC),组成TPC的两个SM共用一级常量Cache、纹理Cache和一条纹理访存流水线,8个TPC共用二级常量Cache和二级纹理Cachet 

GT200架构是NVIDIA公司在2008年推出的第二代统一架构GPU。GT200架构是G80架构的延续和扩展。基于G1200架构的GTX280采用TSMC65nm工艺技术,芯片面积约为能达到90 GFLOPS。576mm2,在片上集成了多达14亿个品体管。单精度浮点性能达到1 TFLOPS,双精度浮点性能达到90GFLOPS。

Ubuntu解压缩zip,tar,tar.gz,tar.bz2

ZIP
zip可能是目前使用得最多的文档压缩格式。它最大的优点就是在不同的操作系统平台,比如Linux, Windows以及Mac OS,上使用。缺点就是支持的压缩率不是很高,而tar.gz和tar.gz2在压缩率方面做得非常好。闲话少说,我们步入正题吧:

我们可以使用下列的命令压缩一个目录:
# zip -r archive_name.zip directory_to_compress

下面是如果解压一个zip文档:
# unzip archive_name.zip

TAR
Tar是在Linux中使用得非常广泛的文档打包格式。它的好处就是它只消耗非常少的CPU以及时间去打包文件,他仅仅只是一个打包工具,并不负责压缩。下面是如何打包一个目录:
# tar -cvf archive_name.tar directory_to_compress

如何解包:
# tar -xvf archive_name.tar.gz

上面这个解包命令将会将文档解开在当前目录下面。当然,你也可以用这个命令来捏住解包的路径:

# tar -xvf archive_name.tar -C /tmp/extract_here/

TAR.GZ
这种格式是我使用得最多的压缩格式。它在压缩时不会占用太多CPU的,而且可以得到一个非常理想的压缩率。使用下面这种格式去压缩一个目录:

# tar -zcvf archive_name.tar.gz directory_to_compress

解压缩:
# tar -zxvf archive_name.tar.gz

上面这个解包命令将会将文档解开在当前目录下面。当然,你也可以用这个命令来捏住解包的路径:

# tar -zxvf archive_name.tar.gz -C /tmp/extract_here/

TAR.BZ2

这种压缩格式是我们提到的所有方式中压缩率最好的。当然,这也就意味着,它比前面的方式要占用更多的CPU与时间。这个就是你如何使用tar.bz2进行压缩。

# tar -jcvf archive_name.tar.bz2 directory_to_compress

上面这个解包命令将会将文档解开在当前目录下面。当然,你也可以用这个命令来捏住解包的路径:

# tar -jxvf archive_name.tar.bz2 -C /tmp/extract_here/

General Wireless systhink

2019.9.25 AP

  • 分析盒子的万兆口的打通工作量,目前是挂在mcs芯片上;
  • 盒子上使用UHD的具体方案,如何移植,是采用逻辑开发还算ARM的C++;
  • 基于OAI代码框架,内部人员分工,分析代码学习开源项目的设计。
  • 梳理我们PHY的代码有哪些函数需要进行优化?下一步做OAI的PHY代码对比分析。

2019.9.10 遍历场景问题
  • 今天想到信道遍历问题,物理层在算法与实现上的对数应该是不充分的,数据样本太少.
  • 如何充分遍历信道场景?如果使用通用平台接入RF单元,可以海量存储和实时分析判断IQ data的处理对比.
  • 初定一个目标: 使用通用x86平台完成一个接收机的连续IQ数据采样分析,如实时频谱图.
2019.9.7 讨论启动关键点论证
  1. 协调一台5300服务器安装linux ubuntu系统,作为研究资料共享及开发调试USRP的环境。
  2. 分析开源srslte项目中UHD底层协议,输出解析文档
  3. 分析x86平台上适合的OS实时系统,及软件协议框架的设想。
  4. 分析射频前端选择,在USRP和MK500两者间考虑可行的方案
  5. 分析NB PHY的汇编代码移植工作量.