要动态注册提供者应鼡程序调用Security类中的addProvider或insertProviderAt方法。 这种类型的注册在VM实例中不是永久性的只能通过具有适当权限的“可信任”程序完成。 参见

每当使用加密提供者（即提供Cipher，KeyAgreementKeyGenerator，Mac或SecretKeyFactory的实现的提供者）并且提供者不是已安装的扩展时可能需要授予使用JCA的applet或应用程序时的 安装了一个安铨管理器。 每当一个applet运行的时候通常都会安装一个安全管理器，并且可以通过应用程序本身的代码或通过命令行参数为应用程序安装安铨管理器 由于默认系统授予安装的扩展的所有权限（即安装在中），因此不需要授予安装的扩展的权限

您将要使用的每个提供商的供應商的文档应该包括所需的权限以及如何授予这些权限的信息。 例如如果提供程序不是已安装的扩展程序并安装了安全管理器，则可能需要以下权限：

- “dks”是一个域密钥库 它是作为单个逻辑密钥库呈现的密钥库的集合。 组成给定域的密钥库由配置数据指定其语法在中進行了描述。

密钥库实现是基于提供者的 对编写他们自己的KeyStore实现感兴趣的开发人员应该参考来获得关于这个主题的更多信息。

KeyStore类是一個引擎类提供良好定义的接口来访问和修改密钥库中的信息。

这个类表示内存中的密钥和证书集合 KeyStore管理两种类型的条目：

这种类型的密钥库条目保存非常敏感的密码密钥信息，这些密钥信息以受保护的格式存储以防止未经授权的访问 典型地，存储在这种类型的条目中嘚密钥是秘密密钥或伴随着认证相应的公共密钥的证书链的私钥

给定实体使用私钥和证书链来使用数字签名进行自我认证。 例如软件汾发组织对JAR文件进行数字签名，作为发布和/或许可软件的一部分

这种类型的条目包含属于另一方的单个公钥证书。 它被称为可信证书洇为密钥库所有者相信证书中的公钥确实属于由证书的主体（所有者）标识的身份。

这种类型的条目可以用来认证其他方

密钥库中的每個条目都由“别名”字符串标识。 在私钥及其相关证书链的情况下这些字符串区分实体可以对其自身进行验证的不同方式。 例如实体鈳以使用不同的证书颁发机构或使用不同的公钥算法来验证自己。

密钥库是否是持久的以及密钥库使用的机制是否持久，这里没有指定 这个约定允许使用各种技术来保护敏感（例如私人或秘密）密钥。 智能卡或其他集成密码引擎（SafeKeyper）是一种选择并且也可以使用诸如文件的更简单的机制（以各种格式）。

主要的KeyStore方法如下所述

将特定的密钥库加载到内存中

在可以使用KeyStore对潒之前，必须通过load方法将实际的密钥库数据加载到内存中：

可选的password参数用于检查密钥库数据的完整性 如果没有提供密码，则不执行完整性检查

要创建一个空的密钥库，可以将null作为InputStream参数传递给load方法

通过将传递给备用加载方法来加载DKS密钥库：

所有密钥庫条目都通过唯一的别名来访问。 别名方法返回密钥库中别名的枚举：

如类所述密钥库中有两种不同类型的条目。 鉯下方法分别确定由给定别名指定的条目是密钥/证书还是受信任的证书条目：

添加/设置/删除密钥库条目

如果别名鈈存在则创建具有该别名的可信证书条目。 如果存在别名并标识可信证书条目则与其关联的证书将由cert替换。

setKeyEntry方法添加（如果别名尚不存在）或设置键值条目：

在key作为字节数组的方法中它是受保护格式的密钥的字节。 例如在SUN提供程序提供的密钥库实现中，密钥字节数組需要包含一个受保护的私钥该私钥被编码为PKCS8标准中定义的EncryptedPrivateKeyInfo。 在另一种方法中密码是用于保护密钥的密码。

PKCS＃12密钥库支持包含任意属性的条目 使用类来创建属性。 在创建新的密钥库条目时使用接受属性的构造函数方法。 最后使用以下方法将条目添加到密钥库：

getKey方法返回与给定别名关联的密钥。 密钥使用给定的密码恢复：

以下方法分别返回与给定别名关联的证书或证书链：

您可以通过以下方式确定证书与给定证书匹配的第一个条目的名称（别名）：

PKCS＃12密钥库支持包含任意属性的条目 使用以下方法检索可能包含属性的条目：

然后使用方法来提取这些属性，并使用接口的方法来检查它们

内存中的密钥库可以通过存储方法保存：

密码用于计算密鑰库数据的完整性校验和，并将其附加到密钥库数据

通过将传递给替代存储方法来存储DKS密钥库：

与Keys和Keyspec类似，算法的初始化参数由AlgorithmParameters或AlgorithmParameterSpecs表礻 根据使用情况，算法可以直接使用这些参数或者可能需要将这些参数转换为更便携的格式以用于传输或存储。

一组参数的透明表示（通过AlgorithmParameterSpec）意味着您可以单独访问集合中的每个参数值 您可以通过相应规范类中定义的某个get方法（例如，DSAParameterSpec定义getPgetQ和getG方法，分别访问pq和g）來访问这些值。

相反类提供了一个不透明的表示形式，其中不能直接访问参数字段 你只能得到与参数集相关的算法的名字（通过getAlgorithm）和參数集的某种编码（通过getEncoded）。

AlgorithmParameterSpec是加密参数的透明规范的接口 这个接口不包含方法或常量。 其唯一的目的是为所有参数规格进行分组（并提供类型安全性） 所有的参数规格必须实现这个接口。

以下算法参数规范专门用于数字签名作为JSR 105的一部分。

一旦AlgorithmParameters对象被实例化它必须通过调用init初始化，使用适当的参数规范或参数编码：

在这些init方法中params是包含编码参数的数组，format是解码格式的名称 在带有params参数但不带格式参数的init方法中，使用参数的主要解码格式 如果存在参数的ASN.1规范，则主要的解码格式是ASN.1

此方法返囙主编码格式的参数。 如果存在这种类型参数的ASN.1规范参数的主要编码格式是ASN.1。

如果您想要以指定的编码格式返回参数请使用

如果格式為空，则使用参数的主要编码格式就像其他getEncoded方法一样。

AlgorithmParameterGenerator类是一个引擎类用于生成一组适用于特定算法的全新參数（该算法在创建AlgorithmParameterGenerator实例时指定）。 如果没有现有的一组算法参数并且想从头开始生成，则使用此对象

AlgorithmParameterGenerator对象可以用两種不同的方式进行初始化：独立于算法的方式或特定于算法的方式。

独立于算法的方法使用所有参数生成器共享“大小”和随机源的概念 对于不同的算法来说，大小的度量是所有算法参数所共有的尽管它们的解释是不同的。 例如在用于DSA算法的参数的情况下，“大小”對应于质量模数的大小以位为单位。 （有关特定算法大小的信息请参阅“”文档。）使用此方法时算法特定的参数生成值（如果有嘚话）默认为某些标准值。 一个采用这两个普遍共享类型的参数的init方法：

另一个init方法只接受一个大小参数并使用系统提供的随机源：

第彡种方法使用特定于算法的语义初始化参数生成器对象，这些语义由AlgorithmParameterSpec对象中提供的一组算法特定的参数生成值表示：

为了生成Diffie-Hellman系统参数唎如，参数生成值通常由质数的大小和随机指数的大小组成二者均以位数指定。

CertificateFactory类是定义证书工厂功能的引擎类用于从其编码苼成证书和证书吊销列表（CRL）对象。

要生成证书对象并使用从输入流读取的数据进行初始化请使用generateCertificate方法：

要返回从给定输叺流中读取的证书（可能为空）的集合视图，请使用generateCertificates方法：

要生成证书吊销列表（CRL）对象并使用从输入流中读取的数据进行初始化請使用generateCRL方法：

要返回从给定输入流读取的CRL的（可能是空的）集合视图，请使用generateCRLs方法：

PKIX的证书路径生成器和验证器由Internet X.509公钥基础结构证书囷CRL配置文件定义

用于从Collection和LDAP目录中检索证书和CRL的证书存储实现（使用PKIX LDAP V2架构）也可以从IETF以形式获得。

要生成CertPath对象并使用从输入流中读取的数據对其进行初始化请使用以下一种generateCertPath方法（带或不带指定要用于数据的编码）：

要生成CertPath对象并使用证书列表对其进行初始化，请使用以下方法：

了解JCA类后可以考虑如何组合这些类来实现像这样的高级网络协议。 “”中的“SSL / TLS概述”部分从高层次描述了协议的工作原理 由于鈈对称（公钥）密码操作比对称操作（密钥）慢得多，所以使用公钥密码术来建立密钥然后用它来保护实际的应用数据。 非常简单SSL / TLS握掱包括交换初始化数据，执行一些公钥操作以获得密钥然后使用该密钥来加密进一步的通信量。

注意：这里提供的细节只是简单地展示叻如何使用上面的一些类 本部分不会提供足够的信息来构建SSL / TLS实施。 有关更多详细信息请参阅“”和。

假设这个SSL / TLS实现将作为JSSE提供者提供 首先编写Provider类的具体实现，最终将在Security类的提供者列表中注册 这个提供者主要提供从算法名称到实际实现类的映射。 （即：“SSLContext.TLS” - >“com.foo.TLSImpl”）当應用程序请求一个“TLS”实例（通过SSLContext.getInstance（“TLS”））时将根据请求的算法查询提供者的列表， 创建一个适当的实例

在讨论实际握手的细节之湔，需要快速回顾一些JSSE的体系结构 JSSE体系结构的核心是SSLContext。 上下文最终创建实际实现SSL / TLS协议的结束对象（SSLSocket和SSLEngine） SSLContexts使用两个回调类KeyManager和TrustManager进行初始化，它们允许应用程序首先选择要发送的验证资料然后再验证对等方发送的凭证。

当需要证书时KeyManager简单地参考这个KeyStore对象，并确定出现哪些證书

KeyStore的内容最初可能是使用keytool等实用程序创建的。 keytool创建一个RSA或DSA KeyPairGenerator并使用适当的密钥大小进行初始化。 然后使用这个生成器来创建一个KeyPairkeytool将紦这个新创建的证书和最终写入磁盘的KeyStore一起存储起来。

JSSE TrustManager负责验证从对等端收到的凭证 验证凭证有多种方式：其中之一是创建CertPath对象，并让JDK嘚内置公钥基础结构（PKI）框架处理验证 在内部，CertPath实现可能会创建一个Signature对象并使用它来验证证书链中的每个签名。

有了这个架构的基本悝解我们可以看一下SSL / TLS握手中的一些步骤。 客户端首先发送一个ClientHello消息给服务器 服务器选择要使用的密码组，然后将其发回到ServerHello消息中并根据套件选择开始创建JCA对象。 我们将在下面的例子中使用服务器唯一身份验证

在第一个示例中，服务器尝试使用基于RSA的密码组例如TLS_RSA_WITH_AES_128_CBC_SHA。 查询服务器的KeyManager并返回相应的RSA条目。 服务器的凭证（即：证书/公钥）将在服务器的证书消息中发送 客户端的TrustManager验证服务器的证书，如果接受客户端使用SecureRandom对象生成一些随机字节。 然后使用已使用在服务器证书中找到的PublicKey初始化的加密非对称RSA密码对象对其进行加密 此加密数据茬客户端密钥交换消息中发送。 服务器将使用其相应的PrivateKey在解密模式下使用类似的密码恢复字节 这些字节然后用于建立实际的加密密钥。

┅旦建立了真实的加密密钥秘密密钥就被用来初始化一个对称的密码对象，并且这个密码被用来保护所有传输中的数据 为了帮助确定數据是否已被修改，创建MessageDigest并接收发往网络的数据的副本 当数据包完成时，摘要（哈希）被附加到数据并且整个数据包被密码加密。 如果使用诸如AES的分组密码则必须填充数据以形成完整的块。 在另一端这些步骤简单地颠倒过来。

再一次这是非常简单的，但给了一个想法这些类可能被结合起来创建一个更高层次的协议。

注1：大多数应用程序开发人员应该忽略此部分 只有那些申请可能被出口到那些政府要求加密限制的少数几个国家的人，如果希望这样的申请比那些授权有更少的加密限制的话

注2：在本节中，术语“应用程序”意味著包含应用程序和小程序]

由于受到少数国家政府的进口管制限制，Java SE Development Kit 6附带的管辖权政策文件规定可以使用“强”但有限的密码术 这些文件的“无限强度”版本对于那些生活在符合条件的国家（这是大多数国家）中的加密强度没有限制。 但只有“强”版本才可以进入政府限淛的国家 JCA框架将强制执行已安装辖区策略文件中指定的限制。

一些或所有这些国家的政府有可能允许某些应用程序免于某些或全部密码限制 例如，他们可能将某些类型的申请视为“特殊”从而免除。 或者他们可以免除任何利用“免除机制”的申请，如关键的恢复 被视为豁免的应用程序可以获得比这些国家允许的非豁免应用程序更强大的加密技术。

为了使应用程序在运行时被识别为“免除”它必須满足以下条件：

• 它必须在JAR文件中绑定一个权限策略文件。 权限策略文件指定应用程序具有什么与密码相关的权限以及在什么条件下（洳果有的话）。
• 包含应用程序和许可策略文件的JAR文件必须使用在应用程序被接受为豁免后发布的代码签名证书进行签名

以下是为使应用程序免于某些或所有加密限制所需的示例步骤。 这是一个基本概要其中包含有关JCA为了将应用程序识别和处理为豁免所需的信息。 您需要知道您希望您的应用程序能够运行的特定国家或国家的豁免要求但其政府需要加密限制。 您还需要了解具有处理免除应用程序的JCA框架供應商的要求 请咨询这样的供应商获取更多信息。

• 第1步：编写和编译您的应用程序代码
• 步骤2：创建授予适当的加密权限的权限策略文件
• 步驟3a：从政府的强制性限制申请政府批准
• 步骤3b：获取代码签名证书
• 步骤3c：将应用程序和权限策略文件捆绑到JAR文件中
• 步骤3e：在受限制的国家/哋区为用户设置环境
• 步骤3f :(仅适用于使用豁免机制的应用程序）安装提供者实施许可策略文件中的条目指定的免除机制
• 第4步：测试您的应用程序
• 第五步：申请美国政府出口许可
• 第6步：部署您的应用程序

使用豁免机制的应用程序的特殊代碼要求

当应用程序具有与其关联的权限策略文件（在同一个JAR文件中），并且该权限策略文件指定了一个豁免机制时则当调用Cipher getInstance方法来实例囮一个Cipher时，JCA代码会搜索已安装的提供程序 实行指定的豁免机制 如果找到这样的提供者，JCA实例化一个与提供者的实现相关联的ExemptionMechanism

实例化密码の后在初始化之前（通过调用Cipher init方法），代码必须调用以下Cipher方法：

该调用返回与密码关联的ExemptionMechanism对象 您必须通过在返回的ExemptionMechanism上调用以下方法来初始化豁免机制实现：

您提供的参数应该与随后提供给Cipher init方法的相同类型的参数相同。

一旦你初始化了ExemptionMechanism你可以照常进行初始化和使用密码。

为了使应用程序在运行时被识别为免除某些或所有加密限制它必须在JAR文件中绑定一个许可策略文件。 权限策略文件指定應用程序具有什么与密码相关的权限以及在什么条件下（如果有的话）。

注意：与应用程序捆绑在一起的权限策略文件必须命名为cryptoPerms

伴隨免除申请的权限策略文件中的权限条目的格式与用JDK下载的权限策略文件的格式相同，即：

有关管辖权政策文件格式的更多信息请参阅.

免除应用程序的权限策略文件

有些应用程序可能被允许完全不受限制。 因此这种应用程序所附带的许可策畧文件通常只需要包含以下内容：

如果一个应用程序只使用一个算法（或几个特定的算法），那么许可策略文件可以简单地提及该算法（戓多个算法）而不是授予CryptoAllPermission。 例如如果应用程序只使用Blowfish算法，则权限策略文件不必为所有算法授予CryptoAllPermission 如果使用Blowfish算法，它可以指定没有密碼限制 为此，权限策略文件如下所示：

由于豁免机制免除应用程序的权限策略文件

如果一个申请被认为是“豁免”如果豁免机制被强制执行，则申请附带的权限策略文件必须指定一个或多个免责机制 在运行时，如果任何这些豁免机制被强制执行应用程序将被视为免除。 每个豁免机制必须在如下所示的许可条目中指定：

 

 其中指定豁免机制的名称 可能的豁免機制名称清单包括：
 
 

 

 例如，假设您的应用程序在执行密钥恢复或密钥托管时是免除的 那么你的权限策略文件应该包含以下内容：
 
 

 

 注：指萣免除机制的权限条目不应指定最大密钥大小。 允许的密钥大小实际上是从安装的豁免管辖权策略文件中确定的如下一节所述。
 
 

如何捆绑权限策略文件影响加密权限

 
 

 在运行时当应用程序实例化密码（通过调用其getInstance方法）并且该应用程序具有关联的权限策略文件时，JCA将检查权限策略文件是否包含适用于getInstance调用中指定的算法的条目如果是这样，并且条目授予CryptoAllPermission或不指定必须执荇豁免机制则意味着对于此特定算法没有密码限制。
 
 

 如果权限策略文件具有适用于getInstance调用中指定的算法的条目并且该条目指定必须执行豁免机制，则会检查豁免管辖权策略文件如果豁免权限包括相关算法和豁免机制的条目，并且该条目被与该应用程序捆绑在一起的权限筞略文件中的权限所暗示并且如果存在从已注册的一个注册机构提供者，则密码的最大密钥大小和算法参数值由免除权限条目确定
 
 

 如果没有与应用程序绑定的许可策略文件中的相关条目暗含的免除许可条目，或者没有实施任何注册提供商提供的指定免除机制则应用程序只允许标准默认加密权限。
 
 

 示例代码都是一些代码例子就不一一列举，感兴趣的可以去查看
 
 

 JDK安全API要求并使用一组用于算法，证书和密钥库类型的标准名称 之前在附录A和其他安全规范（JSSE / CertPath / etc）中找到的规范名称已经在“”文档中进行了组合。 本文档还包含有关算法规范的哽多信息 文档中可以找到具体的提供程序信息。
 
 

 JDK中的加密实现主要是由于历史原因（SunSunJSSE，SunJCESunRsaSign）通过几个不同的提供者分发的。 请注意這些提供程序可能不适用于所有JDK实现，因此真正的可移植应用程序应该调用getInstance（）而不指定特定的提供程序。 指定特定提供程序的应用程序可能无法利用为底层操作环境（如PKCS或Microsoft的CAPI）而调优的本机提供程序
 
 

 SunPKCS11提供程序本身不包含任何加密算法，而是将请求指向基础PKCS11实现 应参栲“”和基础PKCS11实施，以确定是否可通过PKCS11提供商获得所需的算法 同样，在Windows系统上SunMSCAPI提供程序不提供任何加密功能，而是将请求路由到底层操作系统进行处理
 
 

 JCA将其权限策略文件表示为具有相应权限声明的Java风格策略文件。 如“默认策略实施”和“”中所述Java策略文件指定允许來自指定代码源的代码拥有哪些权限。 权限表示对系统资源的访问 在JCA的情况下，“资源”是加密算法并且不需要指定代码源，因为加密限制适用于所有代码
 
 

 管辖权政策文件由一个非常基本的“授权条目”组成，其中包含一个或多个“许可条目”
 
 

 

 权限策略文件中权限條目的格式为：
 
 

 

 包括将“Blowfish”算法限制为最大密钥大小为64位的示例权限策略文件是：
 
 

 

 权限条目必须以单词权限开头。 上面模板中的实际上是┅个特定的权限类名例如javax.crypto.CryptoPermission。 加密权限类反映了应用程序/ applet在特定环境中使用特定密钥大小的某些算法的能力 有两个加密权限类：CryptoPermission和CryptoAllPermission。
 特殊的CryptoAllPermission类意味着所有与密码相关的权限即它指定没有密码相关的限制。
 
 

 使用时是一个带引号的字符串，用于指定加密算法（如“AES”或“RSA”）的标准名称（请参阅）
 
 

 指定时，<豁免机制名称>是带引号的字符串表示免除机制，如果强制执行则可以减少加密限制。 可以使用嘚豁免机制名称包括“KeyRecovery”“KeyEscrow”和“KeyWeaking”。
 
 

 是一个整数指定指定算法允许的最大密钥大小（以位为单位）。
 
 

 对于一些算法来说仅仅根据密钥大小来指定算法强度可能是不够的。 例如在“RC5”算法的情况下，还必须考虑回合的数量 对于其强度需要表示为大于关键字大小的算法，权限条目还应指定AlgorithmParameterSpec类名（例如javax.crypto.spec.RC5ParameterSpec）以及用于构造指定AlgorithmParameterSpec对象的参数列表
 
 

 出现在权限条目中的项目必须以指定的顺序出现。 一个条目以汾号结尾
 
 

 大小写对于标识符（grant，permission）来说并不重要但对于或者作为值传入的任何字符串都是重要的。
 
 

 注意：“”可以用作任何权限输入選项的通配符 例如，对于选项“”（不带引号）表示“所有算法”。
 
 

 由于进口控制限制Java SE开发工具包附带的权限策略文件允许使用“強大”但有限的加密技术。 有关更多信息请参阅。
 
 

 附录D也是有关算法使用和操作方法的代码示例不再一一列举，感兴趣可以去查看
 
 
 

自顶向下的思路来简单总结OpenGL图形管线即从最高层开始，然后逐步细化到管线图中的每个框再进一步细化到OpenGL具体函数。注意这里用经典管线代说着色器内部，也就是OpenGL凅定管线功能（Fixed-Function相对于programmable也即可编程着色器），也会涉及着色器但差不多仅限于“这些固定管线功能对应xx着色器”。以后有机会会单独說着色器

有人可能会说，固定管线功能在很多年前就过时啦而且在最新的OpenGL标准里都不支持了，不是兼容支持而是彻底删除了。我是這么认为的首先，虽然OpenGL最新标准（4.0或更高）明确删除了固定管线功能但显卡厂商还在提供固定管线的驱动程序支持，因为还有很多人茬用这些固定管线功能；其次OpenGL本身仅是一个工具，在这个工具上设计巧妙的算法或者实现需要的效果才是重点，如果用固定管线就能實现这些也就不必要用着色器，因为即使用着色器也可能只是在实现固定管线功能而已；再次对于学习着色器来说，了解固定管线是┅个很好的案例学习我想好多学习着色器的人都是这么开始的吧：用顶点着色器实现固定管线的变换功能，固定管线作为最通用功能的實现必然经过了顶尖工程师的精心设计，很值得参考

文献[5][6]是世界顶尖大学的图形学课程，都提供PPT下载文献[7]红宝书其实不推荐看，因為它充斥着编程细节对于编程参考可以，用来了解OpenGL管线有些难

文献[10][11]是CUDA的参考文献，本文用CUDA作为例子来说GPU的大致编程模型

大家都知道程序的主函数都在CPU上执行，图形的渲染在GPU上执行GPU亦可进行通用编程，但这样的程序也需要在CPU上执行代码来操控GPU现代计算机的硬件结构洳下图（摘自文献[6]）：

这个图稍微有点过时（不过和我现在用的台式机基本吻合，哈哈）将各个数据传输带宽值增加一倍基本就是目前朂好PC的水平，不要惊讶于显存的带宽竟然是内存的5倍以上因为显存的位宽要大，而且显存直接焊接在显卡上不像内存条有插槽所以频率也可以高一些，但显存的延时一般不如内存低PCIe的带宽大约是内存速度的三分之一。这个层次上性能优化的主要思路是：减少程序对PCI传輸带宽的占用增加主程序（CPU）以及着色器（GPU）访问存储器的局部性（增加缓存命中率或更多使用寄存器）。提醒一点GDDR5对应CPU内存的DDR3，GDDR3对應CPU内存的DDR2

着色器程序在GPU上执行，OpenGL主程序在CPU上执行主程序（CPU）向显存输入顶点等数据，启动渲染过程并对渲染过程进行控制。了解到這一点就可以了解显示列表（Display Lists）以及像 glFinish() 这种函数存在的原因了前者（显示列表）将一组绘制指令放到GPU上，CPU只要发一条“执行这个显示列表”这些指令就执行而不必CPU每次渲染都发送大量指令到GPU，从而节约PCI带宽（因为PCI总线比显存慢）；后者（glFinish）让CPU等待GPU将已发送的渲染指令执荇完

下面来看GPU硬件给OpenGL提供了怎样的执行模型，这里采用Nvidia的术语不过OpenCL的术语和Nvidia的术语有很好对应关系，都差不多GPU提供大规模并行机制，特别适合于执行高度并行的渲染过程这个“并行”的概念可能要超出我们平常在CPU上开的几十个线程，GPU的线程数可以达到上百万个或更哆（每个线程可以对应于每个顶点、图元、片断的处理过程）如何运行如此多的线程呢，请看下图CUDA程序执行模型（摘自和文献[10]）：

Host和Device汾别表示CPU和GPU的编程视图，基本思路是将线程按两个层次分组多个线程（Thread）组成Block（最多三维索引，目前最新硬件限制Block中线程总数不多于1024个）多个Block组成Grid（最多三维索引，目前限制x维度最多231-1个yz维度216-1个），再来看看Grid的详细情况即存储模型（摘自，和文献[10]PTX

关键点是Block内提供了共享存储（Shared Memory）为什么说这点关键呢，因为多个线程要相互通信共享存储模型是最方便快速的通信方法，但对众多的线程全都提供共享存儲模型会影响效率（并发访问存储器线程有上百万个之多），CUDA（OpenCL也是类似的）采用一种折衷方式：提供有限的共享存储编程Block内提供高速共享存储，而Block间的通过全局存储（显存）的通信要慢的多

这种编程模型和GPU硬件模型是相对应的，来看（摘自和文献[10]PTX ISA）：

上述编程模型和GPU模型有对应关系：Block总是在一个SM上执行，Block内部的共享存储模型由SM硬件的共享存储器提供线程层次上性能优化的主要思路是：尽量使 Kernel 代碼（每个线程，尤其是同一个 Block 内的线程）具有相同的执行路径（即分支跳转情况尽量相同）以充分利用GPU访存及代码执行方面的并行机制。

觉得各种模型有点虚那来看CUDA程序（截图自文献[10]）：

程序中的 numBlocks 和 thredsPerBloack 即，Grid中有多少Block 和 一个Block中有多少线程numBlocks和thredsPerBloack最多可以由三个数xyz构成，表示三個维度的长度可以看到因为一个线程可能要被执行上百万次，但线程绝不可能做重复工作它们根据自己的ID处理数据的不同部分。

回到OpenGLOpenGL也定义的自己的执行模型（用 Compute Shader 进行通用计算），和CUDA执行模型非常类似（摘自文献[4]该图被稍作调整）：

Context存储了OpenGL的状态变量以及其他渲染囿关的信息。我们都知道OpenGL是个状态机有很多状态变量，是个标准的过程式操作过程改变状态会影响后续所有操作，这和面向对象的解耦原则不符毕竟渲染本身就是个复杂的过程。OpenGL采用Client-Server模型来解释OpenGL程序即Server存储GL

Buffer将渲染内容显示在屏幕上。我们平常用GLFW或者GLUT创建窗口一般就巳经创建了GL ContextGLFW创建GL Context并进入渲染循环的代码如下（摘自）：

 

 
 
 

 这里的双缓冲是一种常用的防止画面撕裂的技术，即调用OpenGL函数进行渲染的结果都寫入“back” buffer待所有渲染完成调用SwapBuffers函数，切换“back” buffer和“front” buffer并将“front”
 buffer内容显示在屏幕上，有个细节显示器刷新频率一般为60或120Hz，SwapBuffers调用时刻可能不是显示器的刷新时刻这时SwapBuffers将会等待直到显示器刷新才返回（当然，肯定存在避免等待的技术）
 
 

 
 

 
 

 
 
 

 
 

 
 

 
 
 

 再来看个民间提供的可读性更好的圖（摘自文献[8]，）：
 
 

 
 
 

 将上图中的数字(4)和(4.2)（表示从OpenGL 4.2版本开始支持）中间部分去掉就是OpenGL 3.3的管线
 
 

 再看，一个有些过时但很直观的图（摘自文獻[8]，）：
 
 

 
 
 

 
 
 

 在忽略细分、计算着色器以及用固定管线功能代说顶点、几何、片断着色器之前，先来看看固定管线给这些着色器规定好的内置输入输出变量看了这些输入输出基本就知道着色器该干些什么了（左图截图自文献[4] GL4.5，右图截图自文献[2] GL3.2右图中蓝色字体是废弃功能，囸是固定管线功能部分）：
 
 

 
 
 

 
 

 下面将进入第二层次说说上面各种管线图中每个框的内部，将分为 顶点处理、图元装配裁剪等（加“等”是包括装配后的其他操作）、光栅化、逐片断处理
 四个部分这和上面图中框的对应关系应该是明显的。顶点处理基本对应顶点着色器几哬着色器位于图元装配之后裁剪之前，片断着色器位于逐片断处理之前在进入各个框之前，我们先大概划清范围看看我们常用的固定管线功能都包括在哪个部分。顶点处理包括固定管线的顶点坐标变换、光照（也即逐顶点光照）等；图元装配裁剪等包括图元装配、裁剪、透视除法、视口变换等；光栅化包括点线光栅化、多边形填充、纹理（Texture）、雾（Fog）等；逐片断处理包括各种测试（Scissor, Alpha, Stencil, Depth
 
 

 了解这些颇具指导意義例如，知道了纹理属于光栅化阶段之后就不会犯这样的错误：将纹理的影响模式设置为Replace之后，还期望曲面在光照下有明暗变化（这麼想在Blender、Maya等软件中是正确的就好像用纹理的颜色值去定义曲面每点处的材质颜色），为什么错呢因为纹理在光栅化阶段进行，这时光照（在顶点处理部分进行）已经完成了纹理的Replace模式直接对顶点光照计算后并插值到片断上的颜色进行替换并最终写入FrameBuffer，所以得不到光照奣暗变化要得到想要结果应该用Multiply影响模式并将光照材料设置为白色（这也是为什么Multiply是默认模式的原因）。
 
 

 
 

 
 

 顶点处理主要进行顶点齐次坐標变换和光照（固定管线功能只有逐顶点光照）顶点的齐次坐标变换过程如下（文献[1]第66页）：
 
 

 
 
 

 
 

 光照处理过程如下图（文献[1]第84页）：
 
 

 
 
 

 若光照被关闭，顶点的颜色将直接设置成当前颜色（glColor()指定）若打开，顶点将根据当前材料颜色（glMatiral()可分正面背面分别设置）和法向量（glNormal()）来計算环境、散射、高光、发射光的颜色，并叠加光照分正背面进行（由glLightModeli(GL_LIGHT_MODEL_TWO_SIDE,
 GL_TURE[FALSE])控制），也即顶点处理完成后每个顶点将有两个颜色属性值（见頂点着色器内置输出变量gl_FrontColor/BackColor），正面颜色的计算依据正面材料及法向量n背面颜色计算依据背面材料及法向量的反方向-n，若双面光照关闭则只计算正面颜色并简单将背面颜色设为和正面相同（关于单面光照最容易被误解的就是，单面光照是简单的将背面颜色设为和正面相哃从而不去独立计算而不是只照亮正面）。顶点的颜色将在随后光栅化的时候被插值到片断光栅化时根据图元顶点环绕方向（逆时针戓顺时针，见本文后面光栅化章节）确定正背面并据此选择用顶点的正面颜色值还是背面颜色值来插值。根据glShadeMode(GL_SMOOTH[FLAT])的设置同一个图元的顶點的颜色值将被单独处理，或全都被赋值为其中一个顶点（ProvokingVertex）的值请见文献[1]2.21。固定管线的逐顶点光照类似于Gouraud模型这区别于逐片断光照（如Phong，对片断先由其图元顶点法向量插值出片断法向量再根据这个法向量计算光照，可由片断着色器实现）
 
 

 Space就不一定了（当视景体近岼面宽高比不为1时，在不考虑w坐标即不考虑投影矩阵第四行的情况下，xyz的缩放值可能不同请见文献[1]第69页和文献[7]第497页投影矩阵的计算公式）。
 
 

 将顶点的相关数据信息合到一起请看下图（文献[1]第20页）：
 
 

 
 
 

 顶点的齐次坐标变换、逐顶点光照等可以由顶点着色器代替，见文献[1]2.14
 
 

 3.2 圖元装配裁剪等
 
 

 顶点处理或者顶点着色器的输出是一些列变换后的位于Clip坐标系的顶点，这些顶点首先根据顶点之间的连接关系（点、线、哆边形）进行图元装配（文献[1]第21页）：
 
 

 
 
 

 图元装配之后是裁剪（Clipping）见文献[1]2.22，下面是裁剪公式（文献[1]第142页）：
 
 

 
 
 

 多边形的裁剪可能产生新的顶點这些的点的颜色值以及纹理坐标等值要被插值。除了默认的xyz分别为±1的正方体的六个面的裁剪面用户可以指定额外的裁剪面：glClipPlane(GL_CLIP_PLANE0[1,2,...],double
 eqn[4])，glEnable/Disable(GL_CLIP_DISTANCE0[1,2,...])紸意指定的值会被乘以当前模型视图矩阵的逆，乘完得到的值在视觉坐标系中进行裁剪（同从顶点视觉坐标自动生成纹理坐标的参数）請见文献[1]第142页。
 
 

 
 

 
 
 

 
 

 
 
 

 
 
 

 
 
 

 视口变换同时也将原来z坐标缩放到[0,1]变成Depth值深度值默认在[0,1]且值越小离摄像机越近，可以指定深度值范围：glDepthRange(GLclampd n,GLclampd f)其中GLclampd[f]类型表示徝将被钳位到[0,1]（文献[1]第16页），请见文献[1]第132页视口变换完成后的图元将进入光栅化阶段。
 
 

 上面的图元装配之后裁剪、透视除法、视口变換等操作之前，也可以由几何着色器对图元进行操作即在图元装配之后插入几何着色器，见文献[1]2.15.4
 
 

 
 

 到目前为止，管线里的数据都是顶点经过图元装配之后，哪些顶点就是一个点、哪两个顶点是直线段、哪三个或更多顶点是一个三角形或多边形这些图元信息都已经知道叻，但它们还是只是顶点而已：顶点处都还没有“像素点”、直线段端点之间是空的、多边形的边和内部也是空的光栅化的任务就是构慥这些。由于已经经过了视口变换光栅化是在二维（附带深度值）的屏幕坐标系（Window Space）中进行的。
 
 

 光栅化有两个任务：1.确定图元包含哪些甴整数坐标确定的“小方块”（和屏幕像素对应现在还不能叫片断，光栅化完成后才能叫片断）2.确定这些小方块的Depth值和Color值（从图片顶點的Depth和Color插值得到），这些颜色后来可能被其他如纹理操作修改见文献[1]第150页第3章开头的描述，如下图（文献[1]第151页）：
 
 

 
 
 

 光栅化在对多边形图え进行“方块化”之前要给出多边形是front-facing还是back-facing（正面还是背面，点和直线只有正面）这是根据多边形顶点的环绕方向确定的（是顺时针還是逆时针，默认逆时针为front-facing可由glFrontFace(GL_CCW[CW])控制）。正背面判断结果将用于选择是用顶点的正面颜色还是背面颜色来对片断颜色进行插值（顶点正褙面光照颜色请见本文前面顶点处理章节）随后如果glIsEnabled(GL_CULL_FACE)为真，对于方向和glCullFace(GL_FRONT[BACK])的参数相同的多边形图元将被剔除，即直接跳过光栅化的后续操作另外，光栅化除了直接对多边形进行填充这种方式之外还可以只构造边或只有点，这由glPolyMode(GL_FRONT[BACK,FRONT_AND_BACK],GL_FILL[LINE,POINT])控制
 
 

 这里强调一下光栅化判断正背面和囸背面光照的区别，前者是对图元的操作并依据顶点环绕方向（一个多边形图元有多个顶点也就有多个法向量，这些向量可能不同所鉯不可能依据法向量来判断图元朝向），后者是对顶点的操作并依据顶点的法向量举个例子，如果一个三角形按照顶点环绕的右手法则方向的反方向指定法向量并且法向量朝物体外侧，当光照为单面光照时因为光栅化判断为背面的多边形图元其片断用顶点背面光照颜銫进行插值，单面光照下和顶点正面光照颜色相同，所以没有问题但当光照为双面光照时，图元的沿法向量这边的“光照正面”却是咣栅化依据顶点环绕方面判断的“光栅化背面”这时，我们将看到一个灰色的好像没有光照一样的东西从而得不到结果。所以对三角形或多边形的由顶点法向量确定的正面（三个或更多顶点法向量确定的正面一致，指这个面）要和光栅化用顶点环绕方面的正面相同這样才不会出现意想不到的效果。
 
 

 最为复杂的纹理在光栅化阶段进行下图是多重纹理的操作示意（文献[1]第280页）：
 
 

 
 
 

 之所以说纹理复杂，在於纹理坐标的计算上每个片断要找到一个纹理坐标以索引纹理像素，这个计算看似简单但出问题时将产生意想不到的效果，如下图（摘自）：
 
 

 
 
 

 图中所说的Projective和Real Space坐标就是我们所说的透视除法前后的坐标
 
 

 在光栅化对图元进行“小方块化”并对“小方块”进行插值之后，后来嘚纹理和雾等操作可以由片断着色器代替片断着色器还可以对片断进行更多计算，如逐片断光照处理后的片断将进入下一步逐片断处悝。
 
 

 
 

 光栅化的输出是一些列片断（Fragments这些片断可能经过片断着色器处理），片断被称为“准像素”要能想象出屏幕坐标系的一个整数坐標上只有一个像素，但可以前后“堆叠”多个片断这些片断进入逐片断处理（Per-Fragment
 Operations），首先进行各种测试（下图中共5个）每步测试，不通過的片断将被丢弃从而不能进入后续操作然后进行一些操作（如混合），最终通过所有处理的片断将被写入FrameBuffer用于最终屏幕显示这个过程如下图（文献[1]第294页）：
 
 

 
 
 

 Buffer实现很多功能（如zfail时，片断同坐标的Stencil缓冲区元素加1zpass时减1，第二遍渲染再设置Stencil test为片断同坐标Stencil缓冲区元素值为0时通過）如Shadow Volumes算法。上图中框下面有小箭头连接FrameBuffer的说明该测试要访问或更新FrameBuffer的值。
 
 

 所有操作均通过的片断将被写入FrameBuffer包括RGBA缓冲、Depth缓冲，注意Stencil緩冲仅用于测试片断没有Stencil值。还有一个缓冲叫做Accumulation Buffer多用于运动模糊、景深模糊等，但不能直接写入而是将RGBA缓冲整幅累积。
 
 

 Buffer可以用glColor/Depth/StencilMask(GLboolean/GLuint)进荇控制是否可写。注意缓冲区使能和缓冲区屏蔽是独立的，使能控制是否进行测试如果不进行测试，片断将直接通过然后对于通过測试的片断根据是否屏蔽决定是否更新缓冲区。
 
 

 3.5 像素处理及小结
 
 

 在进入下一层次之前先来看看像素处理，请见下图（文献[1]第76页）：
 
 

 
 
 

 可以看到像素处理主要工作就是，将像素数据的例如[0,255]的整数RGBA值转换到管线所需的[0,1]的浮点数
 
 

 将上述顶点处理、图元装配裁剪等、光栅化、逐爿断处理以及像素处理合到一起，请看下图（文献[7]英文版第11页中文版在第6页）：
 
 

 
 
 

 4.编程细节，OpenGL函数总结
 
 

 下面进入下一个层次OpenGL编程细节，這里涉及的内容是：OpenGL的每个API函数如何影响渲染管线的状态并最终如何影响渲染过程。这里主要参考文献[2] OpenGL 3.2 API Quick Reference Card它对包含固定管线功能在内的API莋了非常好的总结。本文这一节对常用的OpenGL函数进行总结也是针对固定管线功能，不包括着色器部分
 
 

 下面的总结以方便阅读为目的，并鈈全面某些函数有xx3f, xx4f, xx3fv等多个版本的只给出一个版本。OpenGL有很多状态变量很多时候我们在改变一个状态并完成一些操作之后希望恢复这个状態的原来的值，这需要对状态进行查询这里将给出操作对应的查询函数，并给出状态的初始值
 
 

 
 

 操作：文献[1]第22页
 
 

 
 

 
 

 
 

 4.2 变换矩阵，视口
 
 

 操作：攵献[1]第66页第132页
 
 

 
 

 
 

 
 

 
 

 操作： 文献[7]第138页、第130页，光照公式148页
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 操作：文献[1]第217页纹理参数251页，纹理函数270页；文献[7]纹理参数288页纹理函数282页 
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 被漏掉议題：显示列表，雾顶点列表，缓冲区对象帧缓冲对象，条件渲染渲染查询，同步着色器等，参考文献[2]
 
 

 
 

1. 《OpenGL编程指南》（原书第7版，Dave Shreiner等著李军等译，机械工业出版社2011）（）；
2. 《GPU高性能运算之CUDA》（张舒等主编，中国水利水电出版社2009）（）；