新API里的一些特色包括有：

• 阴影语言。

一种独立于硬件之外的OpenGL 2.0阴影语言，与OpenGL 1.3有紧密的整合。现有的状态机又增加了可编程单元，将可增设OpenGL 1.3固定式的替代功能。新的着色器可自动纪录现有的OpenGL状态（例如进行一个简单的光源转换而无须覆写参数管理）。它以C为架构，加上容易理解的向量和矩阵类型，并也将整合一些Renderman功能。这套语言会虚拟资源管线，因此对大多数的程序设计师来说便不用去考虑资源管理。将来也会有相同形式、供顶点着色与片段着色之用的语言，并加上一些特别内建的功能和数据限定。

• 顶点处理。

其功能在于照明、材质和几何图形的弹性。顶点程序将取代部分的OpenGL管线，像是：顶点转换；正规转换；正规化和尺寸重设；照明；彩色材质应用程序；色彩强化；材质坐标产生；以及材质坐标转换。然而，顶点着色并无办法取代下列功能：透视投影与视觉坐标对应；柱状及用户剪裁；隐面消除；原始组合；双面照明选择；多重模式处理；多边形平移；或多边形模式。

• 片段处理器。

其功能为材质存取、插值计算与像素运算弹性。Open GL 2.0增加了片段处理器能力，将取代下列功能：内插值顶点数据运算；像素缩放；材质存取、缩放和偏向；材质应用；色表查找；雾化；旋绕；以及OpenGL管线中的色彩矩阵部分。然而片段着色并没有取代下列功能：OpenGL的阴影模型；直方图；覆盖度；极值；像素所有权测试；像素封装和解封装；剪裁；点刻；alpha测试；深度测试；模印测试；alpha混色；逻辑运算；抖动；或平面屏蔽。

• 封装和解封装运算。

封装和解封装运算的目的在于将「应用像素」转换成一致性的像素群数据流。在数据传送到解封装处理器前先运用未封装储存模式。解封装处理器和应用对OpenGL传输有关，而封装处理器则负责OpenGL对应用传输这部分，两者都跟复制运算没有关系。绘图子系统内的复制只使用片段处理器。
OpenGL现有的「像素传输」运算是由片段处理器所支持，而非封装∕解封装处理器。片段处理器具有缩放、偏向、查找、旋绕等所需的能力。此外由于ARB并不要求多余的硬件能力，封装∕解封装处理器因而便无需具备其它可编程单元所搭载的浮点运算能力。主要的运算能力为偏移、屏蔽以及转换为∕自浮点数 - 那些和像素数据的应用对OpenGL转换有关的功能。在封装解封装处理器中运行的程序必需和目前的片段着色兼容，并和片段处理器搭配运行以实现OpenGL像素管线。

• 数据移动与内存管理。

为了增进性能，数据移动量必需减至最低。视觉处理的主要数据为：顶点数据（色彩、正规、位置、用户定义等）以及图像数据（材质、图像、像素缓冲区）。建立与管理OpenGL对象的机制大体上就是定位、连结与通过相同接口控制对象，并运用顶点数组、图像、材质、着色、显示清单以及像素缓冲区。
目前来说，OpenGL的内存管理还是黑箱作业；这也就是说所有的事项都会自动处理。因此应用程序无需了解究竟运算结果为何、运算要花多少时间、无需去控制要配置多少储存空间以及这些对象要放在何处。因此，目前版本的OpenGL对于对象何时要被复制、搬移、删除或封装（片段整理）是无法加以控制的。此外也不清楚内存资源的虚拟化。这样的结果是目前OpenGL仅有相当有限的能力去「要求一块空间」，而且只能为了预存材质才能进行这项要求。下图所示为目前OpenGL内存管理的组织架构。

OpenGL 2.0将提供更好的内存管理，并提供应用程序对数据移动的控制能力，提供更好的顶点处理能力、将数据抓进OpenGL的更有效方法，OpenGL对象的直接存取。此外，内存管理功能能消除为增进数据流量而产生的数据备份，以大幅提升性能。藉由内存管理的控制能力，应用程序便可进行调适与动态改变。然而，应用程序开发者将得运用每个对象的使用线索，并和OpenGL联系以使应用程序了解数据的使用状态。这就会达到真的「用一次、用很多次、写一次、异步连结数据」 － [S1]。他也会提供一个供所有对象使用的单一机制（例如材质、显示清单、顶点数组、图像、像素缓冲区和着色）。材质、显示清单、顶点数组内存等之间并无什么区别，这并不会使OpenGL的实现无法取得这些对象的特定储存区。另外可供选择的，应用程序还是可以让OpenGL去管理内存；这就是另一个作法 － [S2]。
OpenGL 2.0会采用应用程序掌控的固定作法，一旦数据被加载后，OpenGL便无法进行搬移、复制、封装或删除对象的动作。对象会被配置在高性能的绘图内存上，让应用程序负责储存或删除对象、或启始封装的运行。新的结构更有效率，如下图所示。

• 异步OpenGL。

Open GL加上异步运算后，OpenGL 2.0将提供更好的平行化和同步化能力。传统上OpenGL在意的是如何和何处 － 而非何时。长久以来一直需要一个能了解并控制事件于何时发生的更好机制。并行化能让某个事件处理完后，工作能继续进行。比方说，在等待交换的同时清空色深暂存区。
OpenGL需要一个一般化、统一的异步化机制，以避免每个扩展指令都要求产生自己的机制。这将会：解决一些短期的问题如平行图像下载；在未来能更加精细的运用时机控制；令应用程序必需遵守时机性；事件发生时的控制能力；以及允许较长的OpenGL运算进行平行执行。这些长运算可相对于主渲染工作「分段执行」，这会是一个替代一个做完才换下一个的好方法 － [S3]。
最后的结果会是OpenGL (2.0)将具有一般化的时间控制能力，有助于增进平行化和运算时机的控制。

• Glsync。

Glsync是一种新的OpenGL数据类型，可提供统一的同步化机制。它可以视为是一个控制器。现在OpenGL具有配置和释放内存空间的功能，但没有由应用程序所控制的ID内存空间。在新的版本中，执行线程可以藉由OpenGL的等待功能，在Glsync上稍后处理。绘图驱动程序可以解除在Glsync上执行线程的等待状态。Glsync可以运用在相当广泛的地方像：围墙渲染；异步数据链路；事件提示（例如垂直空白讯号）；交换完成通知；以及其它现在还没想到的新东西... 这也提供了一个整合至基础操作系统同步化原函式的选择 － [S4] 。
渲染一个围墙会将执行强线程同步化到渲染命令流中；这是一个涵盖「Finish：」功能的的集合。「Finish」必需停滞新渲染工作无法起始的主执行线程。OpenGL将可使用Glsync作此通知。一个执行线程可以产生围墙、执行更多命令，然后在Glsync上等待。「等待」会在围墙之前的渲染工作完成后解除。这可以达成Finish所无法办到的功能。
增加了许多额外的功能及能力，象是：

• FlushStream。

现在的规格在数据暂存上允许过多的自由度。清除功能被滥用且迫使驱动程序得对此做最佳化。真正的清除功能是用在当应用程序已经下完渲染指令后才做的。暂存的渲染工作应该和应用程序在处理其它事项时并行运行，在到Glsync上等待前，必需要确定暂存起来的命令会被加以处理。[S5] － FlushStream解决了这样的问题。

• 异步数据链路。

这可在数据复制前提供回传功能 － [S6]，并在数据进行连结时允许主机并行处理。执行线程在OpenGL读数据时可以做其它事。这可以避免内存内容在OpenGL存取完成前被修改，不过这在可以安全修改内存内容时需要加以通知。

• 后台命令流。

现有的异步数据链路还是无法进行并行渲染。藉由后台命令流功能，另一个命令流可以下达异步连结的指令，给比优先级较低的渲染工作执行。这便可以在前台命令流下达OpenGL的指令，一般的命令流现在都是上下连接的。前台命令流具有较高的优先级，较后台命令流优先执行。

• 场消隐通知。

似乎是个很明显的事，场消隐通知让OpenGL可以对视频输出和程序代码进行同步化。
就在前途看似黯淡的同时，生产绘图产品的厂商证明他们本身会更专注于绘图的目标上，而非他们自己的平台和产品的目标上。就连Microsoft也对扩展OpenGL的可用性感兴趣，更令人振奋的是主要的硬件厂商愿意开放IP，这个之前造成很多阻碍的问题来共同参与。而ATI与Nvidia也双双致力于彼此技术的整合运行。

ARB强调的重点之一是「开放」必需回到OpenGL。该团体宣誓所有送至OpenGL的创意想法，一经采用，便公开给所有人使用且不用IP授权。当然，这样的作法自然有利有弊，不过目前为止我们看到的是good-wonderful-shimmering-FX-laden-graphics（令人雀跃的FX满载绘图），这样一个ARB对绘图的观点，就相当程度的抓到重点，致力于其中就等同于致力于让绘图产品迈向成功。