2012-基于Open CV的农田视觉感知系统-电气工程系欢迎您
当前位置：
>>>>>>正文
2012-基于Open CV的农田视觉感知系统
& &SRT计划项目研究报告 & & & & &
基于OpenCV的农田视觉感知系统
& & & & & & &杨鑫 & & & & & &
& & & & & & &工学院 & & & &
& & & 农业电气化与自动化 & &
& &钱燕 & 职称: & & 讲师 &
基于OpenCV的农田视觉感知系统 & & & & & & & & & & & & & &&
杨鑫 & &马步原 &韩龙
指导老师 & 钱燕
摘要： 为解决农田数据采集、实时数据传输及对农田感知车的远程控制等问题，拟研制一种基于Open CV的农田视觉感知系统，该系统由摄像头数据采集模块，Open CV数据处理模块，3G无线传输模块，服务器数据接收模块，安卓平台的农田感知车数据接收模块等组成。用摄像头采集农田环境，传输到Open CV数据处理模块，对图片进行三维重构，计算需要的相关数据，由手机对摄像头采集的数据进行接收转发，通过手机3G网络传到授权电脑，最后供授权的电脑接收使用。
关键词：OpenCV &采集 感知 &分析
Apperceivethe agricultural view，depends on OpenCV
YangXin & Ma Bu Yuan & Han Long
Tutor &Qian Yan
Thesuccessful development of the system for IOT farmland perception vehicle automaticoperation provide environmental information in the farmland, realizes theautomatic control.
农业是人类的生存之本，是各国经济发展的基础，是国家安全的重要保证。农业生产不仅是个经济问题，更是一个政治问题。对于中国这个拥有 13 亿人口的大国而言，农业生产的重要性可想而知。为了防止产量下降并在理想情况下提升农产品的产量，对于农田环境信息的监测就显得尤为重要。由于农田复杂的大自然环境当中，受到季节、天气、环境和通风条件等因素的影响，农田内的温度和湿度可能会出现异常，导致农作物的霉烂、干枯，这将造成很大的经济损失。我国是人口大国，粮食消耗数量巨大，全国种植地众多。农民每年为农产品的产量费尽心思，主要是因为监测难度较高，管理方式不够先进。科学合理的农田管理，将会为国家节约一笔相当可观的劳动开支。
1. 课题背景
& &近年来，随着科技的发展，三维视觉已经得到广泛的应用发展，三维图像能够全方面精确的展现一个物体，它以其直观、方便、精确、信息内容丰富而被应用于各种场合，成为一种主流。如果将三维视觉应用于农业发展，会使农业信息的采集，图像数据的提取与处理更加精准，从而提高农田管理的工作效率。3D技术的发展能推进农业化与信息化的融合，是促进产业升级和自主创新的推动力，是农业界与文化创意产业广泛应用的基础性、战略性工具技术。充分地将3D与农业相结合，会使农业的发展变得更加容易高效。&
1.1 研究意义
& &本课题研究的目的和意义在于建立一个立体视觉测速系统，实现对农场的三维图像的采集，处理，传输等功能。这在车载摄像机，安全车距，机器人壁障等场景中都拥有广泛的应用。&
1.2 现状分析
3D是基于电脑网络，数字化平台的现代工具性基础共用技术。随着近些年电脑技术的快速发展，3D技术的研究与应用已经走过了几十年的前期摸索阶段，技术的成熟度、完善度、易用性、人性化、经济性等，都已经取得了巨大的突破。目前，3D技术已广泛应用于企业、电子商务、教育、娱乐游戏、虚拟现实展示、虚拟社区等多个方面，而在关乎民生的农业领域尚涉入较浅。
& &我国自古以来就是一农业大国，农业的发展对我国社会的进步起着不可替代的作用，将现代化技术应用于农业生产已成为时代的趋势, 3D技术的应用能够很大程度上提高农业生产和农田管理的效率。&
& &Open CV是一个开源的计算机视觉库，它采用C/C++语言编写，可以运行在Linux/Windows/Mac等操作系统上。它采用优化的C代码编写，能够充分利用多核处理器的优势。它可以构建一个简单易用的计算机视觉框架，帮助开发人员更便捷地设计更复杂的计算机视觉相关应用程序。基于Open CV立体视觉系统，其拥有标定结果精确、运算效率高、跨平台移植性好等优点，它现在应用在许多领域，如基于Open CV的机器视觉图像处理技术实现，基于Open CV和无线通信的智能视频监控报警系统设计，VC++环境下基于Open CV的摄像机标定系统的开发等。
& &将基于Open CV立体视觉系统应用在我国的农业领域里，我国的农业生产效率将会得到很大的提高。&
1.3 研究目标
设计本系统的主要目的是解决农田感知车在农田边缘的耕作问题， 通过双摄像头采集图像信息和Open CV对视觉信息的处理提供农田感知车前端据农田尽头的具体距离，并应用于Android操作系统上，使使用者直观简便地控制农田感知车在农田边缘的耕作。
1.4研究内容
& (1)车载端的Open CV视频流处理，视觉分析，测距离。基于OpenCV的摄像机模型标定和对于三维视觉的数字化处理。由于机械制造的种种局限，透镜成像时会形成来自透镜形状和摄像机组装过程所造成的透镜畸变，所以首要工作就是要利用Open CV来计算畸变向量，即摄像机标定，从而解决这一问题。然后是对于三维立体视觉的处理。在计算机视觉中，要标定或提取3D信息一定要利用多幅图像进行重建，即立体视觉。在农田感知车前端的两侧分别设置两个摄像头，同时在两个位置拍摄两幅图像中的特征，然后对图像中的特征进行匹配，分析其中的差异，从而获得深度信息，即车头到农田边界的精确距离。
& &(2)基于核心技术Open CV的应用与操作要在服务平台上实现。本部分涉及到Android开发环境的搭建，一些基本软件的安装；用户界面的开发。将由Open CV收集处理的数据通过网络传输到Android终端，在Android系统上通过Open GL进行二维绘图,构造一个简明亲和的用户界面。最终让用户在Android用户界面上简单直观的实现操作控制。较精确的控制农田感知车在农田边缘的耕作。
& & & & & & & & & & & & & & &&
2.系统设计路线
图1.设计路线
2.1图像采集处理模块
& 通过cvCaptureFromCAM函数实现图像采集功能，调整图像的大小，色度，频率，通过cvWriteFrame函数完成录像功能，并设置输出格式。
图像采集图例：
图2.实地取景&
2.2 图像特征提取 &&
& &确定被测物的同一物点在不同图像中的对应关系进而通过双视点的视差确定三维信息，实地取景如图二所示。利用canny算子进行边缘检测，提取harris角点为特征点。&
2.3 运动方向分析
通过函数cvFindCorner寻找亚像素角点，当前帧与下一帧角点对比，得出运动方向。
图3.运动提取结果
2.4 手持客户端模块
OpenGL使用简便，效率高。我们应用Android与OpenGL相结合来实现应用平台的搭建，以下是步骤方法：
1.建模：OpenGL图形库除了提供基本的点、线、多边形的绘制外，还提供了复杂的三维物体（球、锥、多面体、茶壶等）以及复杂和曲面绘制函数。
2.变换：OpenGL图形库的变换包括基本变换和投影变换。基本变换有平移、旋转、缩放、四种变换，投影变换有平行投影（又称正射投影）和透视投影两种变换。其变换方法有利于减少算法的运行时间，提高三维图形的显示速度。
3.颜色模式设置：OpenGL颜色模式有两种，即RGBA模式和颜色索引（Color Index）。
4.光照和材质设置：OpenGL光有自发光（Emitted Light）、环境光（Ambient Light）、漫反射光（Diffuse Light）和高光（Specular Light）。材质是用光反射率来表示。场景（Scene）中物体最终反映到人眼的颜色是光的红绿蓝分量与材质红绿蓝分量的反射率相乘后形成的颜色。
5.（TextureMapping）。利用OpenGL纹理映射功能可以十分逼真地表达物体表面细节。
6.显示和图象增强图象功能除了基本的拷贝和像素读写外，还提供融合（Blending）、抗锯齿（反走样）（Antialiasing）和雾（fog）的特殊图象效果处理。以上三条可使被仿真物更具真实感，增强图形显示的效果。
7.双缓存动画（Double Buffering）双缓存即前台缓存和后台，简言之，后台缓存计算场景、生成画面，前台缓存显示后台缓存已画好的画面。
& &成功地搭建出3D农田平台，实现在Android手机显示3D农田，并且农田的视角能够变化。&
2.5 Android系统3D农田效果图
图4.Android手机端3D农田
经过几个月的刻苦研究与制作，在本次毕业设计中我主要完成了以下工作：（1）对OpenCV编程有了深入的了解，能够熟练运用OpenCV函数进行软件设计，成功实现了预期目标，并且通过OpenCV自制了一些小软件，如avi播放器，摄像头录像，照片修改器等
（2）通过Android与OpenGL相结合，成功做到了安卓平台的3D稻田搭建，并且视角可以通过按键前后移动或左右转向，完成了通过手机软件对小车进行操控。
通过本次SRT项目的研究，我们确实学到了很多东西，掌握了许多以前不懂的知识，提高了自学能力，加强了我们的团队合作能力。巩固了我们的专业知识基础，更扩展了我们的知识面。基于OpenCV的农田视觉感知系统基本实现了预期的设计要求，当然还可以不断的拓展和完善，需要我们更深入的探讨和研究。
经过不懈努力，并在各位老师、同学的帮助之下，我们圆满地完成了SRT设计的工作。在这里我们衷心的向所有给予我关心和帮助的老师、同学致以最真诚的感谢！
本项目是在我们的指导老师钱燕老师的悉心指导和热情帮助下完成的，项目的每个环节都凝聚了老师大量的心血。不论是选题上还是实验设计上，一直到完善和成功都包含了指导老师耐心帮助和悉心的指导。无论是在学习理论知识还是在实践中，都给了我们很多的建议和帮助。就是一位这样负责任的好老师，我们才能顺利地完成我的论文。在学校学习这段时间里，我们接触到并且学习到了很多前沿的技术和知识。开阔了视野，提高自己了解决实际问题的能力。在此，向尊敬的钱燕老师致以最诚挚的感谢！
本文凝聚了文中提到和没有提到的所有关心我的人之心血，再次向他们致以最崇高的敬意、最衷心的感谢和最诚挚的祝福。
参考文献：
[1]罗丹,寥志贤.基于Open CV的双目立体视觉测距[J].大众科技,2011,(4).
[2]余绍鹏,冯凌云.基于Open CV的二维定位系统设计[J].贵州大学学报（自然科学版）,2010,（05）.
[3]王福斌,李迎燕,刘杰,陈至坤.基于Open CV的机器视觉图像处理技术实现[J].机械与电子.2010,6.
[4]张景元.基于Open CV和无线通信的智能视频监控报警系统设计[D].武汉科技大学:2009,4.
[5] 李洪雷,管群,胡凯衡,杨宇.VC++环境下基于Open CV的摄影机标定系统的开发[J].计算机应用与软件,2011,（06）.
陈敏,许雪林. 科学技术与工程[J] .2010(15).&
[7]陆宝春,李建文,陈吉朋,王婧,李纯健,汤海昌.南京理工大学学报（自然科学版）. 2010 (6)
Copyright (C) & 系部网站. Cn All Rights Reserved
地址：江苏省南京市浦口区点将台路40号 邮政编码：210031& 苏ICP备号-31337人阅读
Ubuntu Linux（66）
最近，Khronos公布了OpenCL（Open Computing Language）的第一个测试版本，一经发布便在通用计算领域掀起来轩然大波！OpenCL是由公司发起，业界众多著名厂商共同制作的面向异构系统通用目的并行编程的开放式、免费标准，也是一个统一的编程环境。便于软件开发人员为高性能计算服务器、桌面计算系统、手持设备编写高效轻便的代码，而且广泛适用于多核心处理器(CPU)、图形处理器(GPU)、Cell类型架构以及数字信号处理器(DSP)等其他并行处理器，在游戏、娱乐、科研、医疗等各种领域都有广阔的发展前景。
那么OpenCL与NVIDIA的CUDA架构是什么关系，是否是外界认为的竞争关系？目前众多的通用计算标准中，比如NVIDIA的CUDA、Khronos的OpenCL、AMD的Stream，CAL、Brook+、微软下一代的Computer shader等，他们之间有什么异同，看完这篇文章，相信你就会有一个大概的了解……
OpenCL来了！
Khronos是一个开发组织，著名的OpenGL就是出自Khronos之手，Khronos有很多厂商组成，OpenCL工作组同时也是OpenCL的一个协调机构，来负责制定OpenCL的规格、架构等等各方面。业界最主要的和图形或者和计算相关的厂商都是Khronos的成员。
OpenCL实际上是针对异构系统进行并行编程的一个全新的API，OpenCL可以利用GPU进行一些并行计算的工作。我们知道，图形里面有很多API，比如OpenGL是针对图形的，而OpenCL则是针对并行计算的API。 OpenCL开发人员可以利用GPU和CPU的计算能力，把GPU和CPU异构的系统运用在很多并行计算的领域。
OpenCL对于业界来说是非常重要也是非常好的一个标准，这样业界有一个共同的标准可以利用GPU的强大计算能力，然后应用在图形以外各种各样的并行计算方面。NVIDIA公司的副总裁Neil Trevett是OpenCL工作组的主席，引导很多OpenCL的开发，NVIDIA公司很多员工都在参与这项工作。
OpenCL最早由Apple公司提出的，OpenCL发起NVIDIA就和Apple公司进行非常紧密的合作。OpenCL开发的过程中，技术平台均为NVIDIA的GPU，实际上OpenCL是基于NVIDIA GPU的平台进行开发的。另外OpenCL在大概两个多月以前进行了第一次演示，也是运行在NVIDIA的GPU上。
对于Apple公司来说是把GPU计算当成一种未来的趋势，他们非常重视OpenCL，在新一代的产品里面选择了最适合于OpenCL运行的平台。所以新一代苹果的电脑全都采用了NVIDIA的平台，不管是MacBook Pro还是MaBook。实际上这也是从另外一个方面证明NVIDIA的GPU对于OpenCL的支持。
OpenCL与CUDA并非敌对关系
很多人对什么是CUDA可能还有一些疑虑，并没有搞清楚CUDA到底是什么。实际上CUDA最主要的包含两个方面：一个是ISA指令集架构；第二硬件计算引擎；实际上是硬件和指令集。 也就是说我们可以把CUDA看做是与X86或者cell类似的架构，但是是基于是GPU，而不是传统的CPU。
这个其实很好理解，把它和传统的和CPU的架构比较下相信就更容易理解，传统X86是包含一套指令集和执行X86各种各样的CPU，对于CUDA也是一样，CUDA有一套指令集ISA，还有执行指令集各种各样的硬件引擎。CUDA到目前为止包含了一个C语言的编译器，当然CUDA架构还可以支持其他的API，包括OpenCL或者DirectX，同时CUDA还会有其他的语言，包括Fortran、Java、Python等各种各样的语言，可以说CUDA架构是原生的，专门为计算接口而建造的这样的一个架构，这种硬件架构包括指令集都是非常适合于这种并行计算，为异构计算而设计的一整套的架构。
OpenCL与CUDA的关系
上图很好的解释CUDA和OpenCL的关系，他们并不是冲突关系，而是包容关系。OpenCL是一个API，在第一个级别，CUDA架构是更高一个级别，在这个架构上不管是OpenCL还是DX11这样的API，还是像C语言、Fortran、DX11计算，都可以支持。作为程序开发员来讲，一般他们只懂这些语言或者API，可以采用多种语言开发自己的程序，不管他选择什么语言，只要是希望调用GPU的计算能，在这个架构上都可以用CUDA来编程。
CUDA编程的道理和CPU的编程很类似，比如有了X86的指令集，又有X86各种各样的CPU，那么我们只需要对这个指令集编程即可。X86架构上有各种各样的开发工具，当然也有C语言，Fortran语言，Python语言，Java或者以前的Pascal语言，不论你使用什么语言进行开发，最后还是在X86的架构上执行。CUDA也是一样，有了CUDA的指令集，有了支持CUDA的硬件，我们就可以采用不同的途径来进行开发，比如可以采用OpenCL或者DirectX这样的API，也可以用C语言或者Fortran或者Java开发，最终都可以在CUDA架构上运行。
OpenCL与CUDA C语言的异同
前文已经说过，CUDA架构与OpenCL是包容关系，我们把他们放在同一级别进行讨论本来就是错误的，与OpenCL在同一级别不是CUDA架构，而是CUDA的C语言包，也就是我们常说的CUDA版本，比如，CUDA 1.0、CUDA 2.0等等，下面来介绍一下OpenCL和CUDA C语言的一些异同。
对于编程人员来说可以选择不同的开发环境来进行编程，例如我们可以选择OpenCL编程也可以选择CUDA上面的C语言来编程，或者API的语言来编程。API和C语言进行开发是有一些不同的，API是一个编程接口，它的核心是函数库和应用程序开发的一个硬件接口，对于API来编程的话，好处在于可以访问比较低层次的硬件，单弊端也是显而易见的，那就是很多程序特别是像内存的管理，需要程序员自己来进行管理。而我们在利用CUDA C语言来编程的时候，底层的硬件管理是由CUDA开发包来进行管理，比如内存是用runtime进行管理（runtime实际上就是运行时的一些支持程序来进行底层硬件的管理），而不需要开发者考虑底层的硬件效率。不管OpenCL或者CUDA
C语言来编程，最终都是需要通过一个驱动程序来变成一个PTX的代码，PTX相当于CUDA的指令集来进行执行，然后交给图形处理其或者交给CPU来进行执行。
也就是说，如果开发人员想获得更多的对硬件上的控制权的话，可以使用API来进行编程，而如果类似科学家如果对API不是太了解，那么就可以用CUDA C语言来编程，这是两种不同编程的方式，他们有他们相同点和不同点。OpenCL和CUDA C语言进行开发的时候，在并行计算上的概念很相似，在程序上是也有很大的相似度，所以程序之间的相互移植相对来说也比较容易。
当然我们也许会有疑问，那就是OpenCL看似更趋向于底层开发的API，那相对于CUDA C来说，OpenCL开发的程序执行效率会不会比CUDA C效率更高一些？实际上这个问题是不用担心的，执行效率高不高，并不取决于采用的什么语言，什么样的API，更大程度上取决于的代码的优化程度！
不同编程模式解读
下面我们来深入解读一下CUDA与C语言编程模式的异同。对C语言进行编程的人员都知道，C语言使用驱动程序就是API，实际上是一种抽象，这个抽象主要是指和硬件相关的抽象。实际上CUDA C语言是一种C语言的扩展，这扩展的一部分主要是进行并行运算编程的方面，这些是通过C的扩展来获得的。基本上认为CUDA的程序也是一种标准的C语言的程序，然后使用一些关键字然后来对并行这方面计算，最后做一些区分。C语言最终编译会成为PTX的代码，然后在GPU上执行。OpenCL是一个API，就是应用程序的编程接口，OpenCL和OpenGL很像，这种API可以调用API最底层的数据，通过程序开发调用各种各样的函数，实现各种各样的功能。对于API来说一般它对硬件设备有比较完整的访问权，以访问硬件的设备，可以对内存进行管理，这是由开发人员通过编程来做的这些事情。最后OpenCL通过编译、通过驱动程序可以生成PTX代码在GPU上进行执行。
编程人员要利用GPU的计算能力开发你的应用的时候，有两种模式：如果你需要对硬件有更多的控制，可以通过OpenCL来编你的API和你的程序，那么它可以在CPU上运行；如果不需要底层的硬件管理，同时对硬件有控制权，而且又不太懂API这些程序，只要用C语言就可以编程了，或者CUDA C语言来编程，编完程序以后也可以在CPU的硬件上运行。
OpenCL和OpenGL在很多方面都很类似，他们也是一个共同的组织Khronos来进行管理的。对OpenGL图形开发比较熟悉的人使用OpenCL计算这方面的开发，他们就会非常熟悉它里面所涉及的很多方面，这是OpenCL的一个非常明显的特点。如果你对图形编程很熟悉的话，就像是Computer shader，如果是多媒体等方面的应用，又想使用图形又想使用GPU的来计算，用Computer shader的DX11编程，可能比较容易。但是对于大部分的科学家来说，可能对API，OpenCL可能完全不熟悉，他需要的就像在CPU上编程一样，对CPU的计算编程，可以使用CUDA
C语言，在CUDA C语言里面我们把CPU看成专门做计算的协处理器来进行编程，这是两个之间不同的模式。
如果认为一种开发环境就可以取代其他的开发环境，这个是不现实的。举个例子，在X86的架构上，除了C语言以外还有Java、Fortran还有Pascal语言，这些不可能互相取代的，每种语言、每种API都有它使用的人群。不同的语言、不同的API都会满足不同人群的。GPU计算和API语言不是太多，目前还比较少，NVIDIA还会不断地推出Java、Pascal或者C++也会支持。如果以前没有Fortran，那些“老古董”程序员要让他们学习C语言的话基本不可行，他们可能用Fortran用了几十年，让他们使用C语言开发的话他就比较痛苦，所以OpenCL与CUDA
C语言并不存在谁将取代谁的问题。
CUDA与ATI Stream异同
我们知道，ATI方面也有自己的通用计算编程接口，叫做Stream。那么他与CUDA架构又有什么不同呢？
Stream基本上还是基于一种传统CPU的一种方式，Stream主要包括CAL与Brook+。CAL是一套指令集，可以用汇编语言的方式来开发软件，然而我们汇编方式开发软件的话，对搞计算的人来说不大现实，让他们用汇编语言来说的话可能确实是一个折磨。Brook+是斯坦福大学开发的，它是类似于C语言的东西，是把底层GPGPU的计算方式类似于C的这种语言，这里要说明的是Brook+不是C语言而是类C语言，语法和C语言比较类似，但内部做的还是使用顶点这样的数据。
Stream视频编码
另外Stream的方式还有一个很大的问题，那就是主要是基于本地的板载内存存入数据，换算完成再写到板载内存。这样对GPU非常强大的计算能力来说，带宽是一个非常大的障碍。例如每秒种进行1P的数字计算的话，需要多少的带宽？32位浮点4个字节，如果是1P的话，我们把乘加这部分也计算在内就相当于再乘以2，至少需要每秒2P的吞吐量然后才能够满足，板载内存每秒需要几十P。可见Stream的方式从效率上是一个比较低的计算，而对于开发者来说也会碰到很多的问题。
对于CUDA来说我们支持的C语言，是真正GPU上运行的C语言。C语言有一个很重要的特点，需要有存储体系，而NVIDIA GPU在设计之初就考虑到了这点，内部有拥有share memory，编译器会把大部分的数据尽可能的在share memory上进行计算。share memory带宽非常高，因为它在芯片内部，速度接近于寄存器。数据在share memory上运行，然后再把这个数据再输出，这样的话真正地可以利用到绝大部分的GPU性能。
汇编语言的弊端
基于Stream来开发的应用软件，我们知道的只有一个是folding@home，ATI比NVIDIA进入早两年，但是NVIDIA进入以后使用CUDA的语言来写folding@home客户端的软件，性能比ATI的GPU要高好几倍。folding@home的一个版本可以运行在在上一代的架HD3（&&&）850或者HD3870的GPU上，但是HD4850和HD4870发布后，从浮点性能上来说计算能力比HD3850、HD3870要高2.5倍，但是folding@home的性能反而下降了？原来HDns/day左右，每天可以模拟200万秒的性能等级，但是HD4870发布后每天只能模拟170ns/day，这又是为什么？其原因是软件不是使用Brook+开发的，而直接使用汇编的方式，这就需要对每一个新的GPU进行编程，每个架构都需要对它重新进行编程，然后才可以得到一个最好的效率，这就是说使用汇编方式的话会带来一个非常大的问题，任何一个应用软件里面都需要重新优化、重新编程。
汇编语言实际上就是机械码来进行编程，属于体力比较好、记忆也比较好的人才能胜任的工作。高级语言相对来说确实要简单太多了，例如有些人甚至对编程都不是很熟悉，他只要基本上知道源代码里面哪些代码是在做什么东西，然后他就可以使用CUDA，核心部分计算部分一定要自己编写，因为CUDA有很多现成的库，都是直接写好的函数，这个函数把原来的函数替代掉，就可以取得很好的性能。NVIDIA提供很多函数库，这些函数库有一些是NVIDIA公司开发的，像FFT、线性代数或者是快速傅里叶变换等，但是有一些库是第三方帮NVIDIA开发的。CUDA实际上形成一个非常好的环境，不断的有人针对CUDA来开发，不管是应用软件或者是中间件，这些中间件的话就包含各种各样的库。
因此对于CUDA来说，与Stream相比几乎现在没什么可比性。对OpenCL、DirectX这样应用在CUDA的架构上运行程序也比在Stream上运行程序好的多。因为NVIDIA在使用的CUDA架构实际上字开发的时候，就考虑到通用计算方面的应用。而ATI方面，可能通用计算仅仅是图形的一个副产品。
OpenCL与CUDA C语言路线图
目前OpenCL路线图目前还是属于Alpha版本。明年第一季度可能是Beta的版本，09年OpenCL1.0可能会正式推出，OpenCL最早会出现在Mac OS上，以后逐渐的扩展到其他的操作系统，像Windows或者Linux。
OpenCL路线图
下面来介绍一下CUDA C语言的情况，NVIDIA一直还是不断地对这个语言进行更深层次的开发，也不断的有新版本的出现，到目前为止已经是CUDA 2.0。CUDA C语言研发已经超过5年时间，NVIDIA从03年左右就开始开发C语言。到目前为止，开发人员的数量已经是超过25000个，而且现在应用程序已经超过100个，特别是很多的科学计算的领域，几乎涉及到各种各样的HPC高性能计算的领域都有CUDA的身影出现，甚至现在HPC进入排行榜前100的高性能计算机里面也有使用NVIDIA的Tesla系统，GPU集群就是配置成高性能计算机的集群数量已经达到了30个，我国大陆也有采用。
CUDA C语言是一个跨操作系统的开发工具，现在支持Windows、Linux、Mac OS，几乎最主流的操作系统都支持，SUN公司的Solaris系统也会支持。一些数学软件像Matlab、Mathematica、LabView都有CUDA的插件，可以使用C语言的插件让他更容易的利用CUDA。
上面是C语言的路线图，目前的版本是CUDA 2.0，到今年年底CUDA 2.1会与我们见面，到明年会有2.2、2.3版本，到明年年底会到CUDA 3.0版本。随着CUDA版本的升级，它的功能也在不断地升级，比如最早的CUDA只能支持单精度的浮点计算，现在可以支持双精度，可以支持各种各样的库，各种各样的功能也是越来越多。
并行计算时代已经到来……
OpenCL的面世，不管对开发人员还是业界人员来说还是消费者来说都是一个非常好的API，它可以使得开发者很容易的开发出跨平台的GPU计算的程序，充分利用GPU强大的计算能力然后应用在各种各样计算的方面。 除了CUDA的架构上除了C语言以外，现在新增加了OpenCL或者DX11这样的API，对于开发人员来说也提供了一种更多的GPU计算的开发环境的一种选择。如果对API很熟悉的程序员，肯定会很高兴的看到OpenCL或者新的API的加入，对于这些人来说他们很容易利用这种计算的API然后开发各种各样GPU计算的程序。
NVIDIA也会继续对C语言包括其他语言的支持，实对NVIDIA CUDA C语言来说目前还是唯一的针对GPU的runtime C的语言环境（runtime C的语言环境是指GPU直接执行这个C语言）。CUDA C语言还会进一步的发展，不断会有新的版本推出。CUDA C语言会和OpenCL和DX11这种计算API会共存。
除了C语言以外NVIDIA还会推出更多的其他CUDA的语言，包括Fortran，还会有Java等。不管C语言还是Fortran，与OpenCL、Computer shader这种API是一种长期共存的关系。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1535951次
积分：14714
积分：14714
排名：第734名
原创：67篇
转载：535篇
评论：139条
(1)(1)(1)(1)(1)(6)(1)(4)(2)(2)(2)(7)(22)(19)(7)(7)(18)(17)(25)(20)(35)(24)(24)(8)(4)(8)(21)(14)(6)(5)(8)(12)(6)(13)(15)(28)(9)(21)(31)(16)(6)(14)(4)(5)(3)(5)(1)(1)(6)(6)(4)(5)(5)(11)(31)(21)(5)}