周工作总结报告

第四周

姓名 日期 朱宇峰 2010.3.29-2010.4.4 学号 指导老师 5060379063 杨旭波 本周工作记录 1. 阅读有关GPU编程的论文和技术文档 2. 学习GPGPU的开发技术 3. 学习CUDA编程技术 完成的工作 4. 完成Linux下GPU算法和分布式渲染框架SPU的整合 5. 听取杨老师的意见，准备单卡多屏渲染的相关技术资料 6. 了解A卡N卡的发展历程和GPU的发展路线，为进一步优化项目做准备 1.这周完成了最终的GPU算法同分布式渲染框架中的SPU的整合，效果从3fps提高到8fps，但这和原先CPU上的18-20fps还想去甚远。分析后归纳为以下几点原因（可能有纰漏，会在进一步加深对GPGPU的理解后予以修正）： 遇到的问题（包括是否解决） （1）也是最为主要的一点原因，之所以效率下降最为直接的是由于内存和显存间的数据拷贝所造成的：首先，由于单帧图像的分辨率一般在1280*1024，单个像素由RGB三通道组成，再加上单通道的位宽为16位的浮点存储（原本希望可以通过HDR弥补投影设备的色彩空间较小的缺陷，最初位宽为32位浮点时帧率仅有3fps，换为16位后可提高到8fps，后期优化可能还是会变回256色的8位byte型），这样单帧图像的传输数据量就有7.5MB，这无疑将直接影响绘制效率；其次，为了兼容分布式渲染框架中流处理的方式，一个非render SPU中不负责最后的渲染工作，而是须将结果传给后项的SPU，因此还需将如数据从显存拷贝回内存，生成的结果图像的分辨率为800*600，同样单通道位宽为16位，也就是一次拷贝的数据量又有2.7MB左右，反反复复的拷贝操作无疑大大降低了渲染的实时性能。 （2）另外一个原因与我的实现方式有关，我的实现是通过Cg Pixel Shader进行GPGPU的运算，然而在逐步学习的过程中发现这并不是最好的选择，原因有二：其一，从编程复杂度上而言，用图形学得方法进行通用编程显然不够和谐，并且还存在这调试困难等诸多弊病；其二，从效率上而言也并不理想，因为针对图形学的Shader即为可编程的渲染管线，由于涉及初衷比较单一，因此在硬件所提供的接口方便也并不适合于通用编程，当然这也与Shader的编译器有着莫大的关系。 目前，比较流行的GPU通用并行计算平台有CUDA，OpenCL，Direct Compute，Brook+，Sh等，他们所提供的编译平台更吻合通用编程的思想，并且也得到了硬件更多的支持，因此无论在效率上还是性能上都比直接用Shader编写效果更好。为此，我下一步将会转向CUDA方面的学习，并同如今的框架进行整合。 （3）硬件配置，由于是在笔记本上得到的测试数据，因此硬件的配置也是不可忽略的因素之一，具体不再赘述。 2.这周同样遇到了一个问题，就是分布式渲染框架在传输过程中有数据损坏的情况出现，这一问题会在下周初期尽快解决，以避免对系统调试的影响。 经验收获与个人点评 希望助教在检查记录的时候能够仔细一些，之前我一直按时提交报告，但在最后检查时由于助教个人的疏忽导致我被错误的警告了一次，希望这只是一个小小的误会，也希望类似的情况今后不要再度发生。