OpenGL 4.6 comp spec chapter 1-3

1. Introduction 简介

This document, referred to as the “OpenGL Specification” or just “Specification” hereafter, describes the OpenGL graphics system: what it is, how it acts, and what is required to implement it. We assume that the reader has at least a rudimentary understanding of computer graphics. This means familiarity with the essentials of computer graphics algorithms and terminology as well as with modern GPUs (Graphic Processing Units). The canonical version of the Specification is available in the official OpenGL Registry, located at URL http://www.opengl.org/registry

此文档（以下称为“ OpenGL规范”或以下简称“规范”）描述了OpenGL图形系统：它是什么，它如何工作以及实现它的要求。我们假设读者至少对计算机图形学有基本的了解。这意味着您必须熟悉计算机图形算法和术语的要点以及现代GPU（图形处理单元）。规范可在官方的OpenGL注册表中找到，位于URL http://www.opengl.org/registry

1.1 Formatting of the OpenGL Specification OpenGL规范的格式

Starting with version 4.3, the OpenGL Specification has undergone major restructuring to focus on programmable shading, and to describe important concepts and objects in the context of the entire API before describing details of their use in the graphics pipeline.

从4.3版开始，OpenGL规范经历了重大的调整，以专注于可编程着色，并在描述它们在图形管道中使用的详细信息之前，在整个API的上下文中描述了重要的概念和对象

1.1.1 Formatting of the Compatibility Profile 兼容性配置文件的格式

Material which is present only in the compatibility profile Specification and not in the core Specification (see appendix E) is typeset in orange, like this paragraph.

仅在兼容性概要文件规范中出现而在核心规范中不存在的材料（请参阅附录E）用橙色排版，就像橙色字体一样

1.1.2 Formatting of Optional Features 可选功能的格式

Some features in the Specification are considered optional; an OpenGL implementation may or may not choose to provide them (see section 8.4.2). 规范中的某些功能被认为是可选的

Portions of the Specification which are optional are so described where the optional features are first defined (see section 8.4.2). State table entries which are optional are typeset against a gray background .可选的状态表条目是在灰色背景下排版的

1.2 What is the OpenGL Graphics System? 什么是OpenGL图形系统

OpenGL (for “Open Graphics Library”) is an API (Application Programming Interface) to graphics hardware. The API consists of a set of several hundred procedures and functions that allow a programmer to specify the shader programs, objects, and operations involved in producing high-quality graphical images, specifically color images of three-dimensional objects.
Most of OpenGL requires that the graphics hardware contain a framebuffer. Many OpenGL calls control drawing geometric objects such as points, lines, and polygons, but the way that some of this drawing occurs (such as when antialiasing or multisampling is in use) relies on the existence of a framebuffer and its properties. Some commands explicitly manage the framebuffer.

OpenGL（用于“ Open Graphics Library”）是图形硬件的API（Application Programming Interface）。该API由数百个过程和函数组成，允许程序员指定着色器程序，对象和操作，这些着色器程序，对象和操作涉及生成高质量的图形图像，尤其是三维对象的彩色图像。大多数OpenGL要求图形硬件包含帧缓冲区。许多OpenGL调用控制图形的几何对象，例如点，线和多边形，但是某些图形的发生方式（例如，在使用抗锯齿或多重采样时）取决于帧缓冲区的存在及其正确的属性。一些命令显式管理帧缓冲区

https://learnopengl-cn.github.io/

1.2.1 Programmer’s View of OpenGL 程序猿世界的OpenGL

To the programmer, OpenGL is a set of commands that allow the specification of shader programs or shaders, data used by shaders, and state controlling aspects of OpenGL outside the scope of shaders.

对于程序员而言，OpenGL是一组命令，这些命令允许指定着色器程序或着色器，着色器使用的数据以及着色器范围之外的OpenGL状态控制方面

Typically the data represent geometry in two or three dimensions and texture images, while the shaders control the geometric processing, rasterization of geometry and the lighting and shading of fragments generated by rasterization, resulting in rendering geometry into the framebuffers.

通常，数据代表二维或三维和纹理图像中的几何图形，而shader着色器控制几何图形处理，几何图形栅格化以及光栅化生成的片段的照明和阴影，从而将几何图形渲染到帧缓冲区中

A typical program that uses OpenGL begins with calls to open a window into the framebuffer into which the program will draw. Then, calls are made to allocate an OpenGL context and associate it with the window. Once a context is allocated,OpenGL commands to define shaders, geometry, and textures are made, followed by commands which draw geometry by transferring specified ortions of the geometry to the shaders. Drawing commands specify simple geometric objects such as points, line segments, and polygons, which can be further manipulated by shaders. There are also commands which directly control the framebuffer by reading and writing pixels.

使用OpenGL的典型程序首先调用打开一个窗口，该窗口进入该程序将绘制到的帧缓冲区。然后，进行调用以分配OpenGL上下文并将其与窗口关联。分配上下文后，将使用OpenGL命令定义着色器，几何图形和纹理，然后执行通过将geometry的指定位置转移到着色器来绘制几何图形的命令。绘制命令指定简单的几何对象，例如点，线段和多边形，可以通过着色器对其进行进一步操作。还有一些命令可以通过读写像素直接控制帧缓冲区

1.2.2 Implementor’s View of OpenGL 实施者的OpenGL视图

To the implementor, OpenGL is a set of commands that control the operation of the GPU. Modern GPUs accelerate almost all OpenGL operations, storing data and framebuffer images in GPU memory and executing shaders in dedicated GPU processors. However, OpenGL may be implemented on less capable GPUs, or even without a GPU, by moving some or all operations into the host CPU.

对于实施者(radeonsi)来说，OpenGL是一组控制GPU操作的命令。现代GPU加速了几乎所有OpenGL操作，将数据和帧缓冲图像存储在GPU内存中，并在专用GPU处理器中执行着色器。但是，通过将部分或全部操作移至主机CPU中，OpenGL可以在性能较低的GPU上实现，甚至可以在没有GPU的情况下实现。

The implementor’s task is to provide a software library on the CPU which implements the OpenGL API, while dividing the work for each OpenGL command between the CPU and the graphics hardware as appropriate for the capabilities of the GPU”

实施者的任务是在CPU上提供实现OpenGL API的软件库，同时根据GPU的功能在CPU和图形硬件之间划分每个OpenGL命令的工作

OpenGL contains a considerable amount of information including many types of objects representing programmable shaders and the data they consume and generate, as well as other context state controlling non-programmable aspects of OpenGL. Most of these objects and state are available to the programmer, who can set, manipulate, and query their values through OpenGL commands. Some of it,however, is derived state visible only by the effect it has on how OpenGL operates. One of the main goals of this Specification is to describe OpenGL objects and context state explicitly, to elucidate how they change in response to OpenGL commands, and to indicate what their effects are.

OpenGL包含大量信息，包括代表可编程着色器及其消耗和生成的数据的许多类型的对象，以及控制OpenGL非可编程方面的其他上下文状态;这些对象和状态中的大多数对程序员都是可用的，程序员可以通过OpenGL命令设置，操作和查询其值。但是，其中的某些派生状态只能通过其对OpenGL操作符的作用方式可见。本规范的主要目标之一是明确描述OpenGL对象和上下文状态，阐明它们如何响应OpenGL命令而改变，并指出它们的作用。

1.2.3 Our View 我们的视角

We view OpenGL as a pipeline having some programmable stages and some state driven fixed-function stages that are invoked by a set of specific drawing operations. This model should engender a specification that satisfies the needs of both programmers and implementors. It does not, however, necessarily provide a model for implementation. An implementation must produce results conforming to those produced by the specified methods, but there may be ways to carry out a particular computation that are more efficient than the one specified.

我们将OpenGL视为具有一些可编程阶段和某些状态驱动的固定功能阶段的管线，这些阶段由一组特定的绘图操作调用。该模型应产生一个满足程序员和实现者需求的规范。但是，它不一定提供实施模型。一个实现必须产生与指定方法产生的结果相符的结果，但是可能有一种方法可以执行比指定方法更有效的特定计算。

OpenGL 只提供规范，告诉规范是什么样子，但是不提供真正的模型

1.2.4 Fixed-function Hardware and the Compatibility Profile 为了与老版本兼容

Older generations of graphics hardware were not programmable using shaders, although they were configurable by setting state controlling specific details of their operation. The compatibility profile of OpenGL continues to support the legacy OpenGL commands developed for such fixed-function hardware, although they are typically implemented by writing shaders which reproduce the operation of such hardware. Fixed-function OpenGL commands and operations are described as alternative interfaces following descriptions of the corresponding shader stages.

固定功能的硬件和兼容性配置文件尽管可以通过设置状态控制其特定操作细节来配置，但较旧的图形硬件无法使用着色器进行编程。 OpenGL的兼容性配置文件继续支持为此类固定功能硬件开发的传统OpenGL命令，尽管它们通常是通过编写可再现此类硬件操作的着色器来实现的。固定功能的OpenGL命令和操作在相应的着色器阶段的描述之后被描述为备用接口

1.2.5 The Deprecation Model 一些弃用的范例

Features marked as deprecated in one version of the Specification are expected to be removed in a future version, allowing applications time to transition away from use of deprecated features. The deprecation model is described in more detail,
together with a summary of the commands and state deprecated from this version of the API, in appendix E.

在规范的一个版本中标记为不推荐使用的功能，预计将在将来的版本中删除，从而使应用程序有时间转移使用不推荐使用的功能的时间

附录E中详细描述了弃用模型，以及此版本API中弃用的命令和状态的摘要

1.3 Related APIs 相关API

与OpenGL相关的其他API和相关规范如下所述。这些API的大多数规范都可以在Khronos Group网站上找到，尽管某些特定于供应商的API记录在该供应商的开发者网站上

1.3.1 OpenGL Shading Language GLSL语言

The OpenGL Specification should be read together with a companion document titled 《The OpenGL Shading Language》. The latter document (referred to as the OpenGL Shading Language Specification hereafter) defines the syntax and semantics of the programming language used to write shaders (see chapter 7). Descriptions of shaders later in this document may include references to concepts and terms (such as shading language variable types) defined in the OpenGL Shading Language Specification. OpenGL 4.6 implementations are guaranteed to support version 4.60 of the OpenGL Shading Language. All references to sections of that specification refer to that version. The latest supported version of the shading language may be queried as described in section 22.2. The compatibility profile of OpenGL 4.6 is also guaranteed to support all previous versions of the OpenGL Shading Language back to version 1.10. The #version strings for all supported versions of the OpenGL Shading Language may be queried as described in section 22.2. The OpenGL Shading Language Specification is available in the OpenGL Registry

应将OpenGL规范与标题为《 The OpenGL Shading Language》的配套文档一起阅读.

后面的文档（以下称为OpenGL shadow语言规范）定义了用于编写着色器的编程语言的语法和语义（请参见第7章）

本文档后面的着色器的描述可能包含对OpenGL着色语言规范中定义的概念和术语（例如，着色语言变量类型）的引用保证OpenGL 4.6实现支持OpenGL阴影语言4.60版.

该规范各节的所有引用均指该版本。如第22.2节中所述，可以查询最新的受支持的着色语言版本

还保证了OpenGL 4.6的兼容性配置文件支持所有旧版本的OpenGL阴影语言回到1.10版

可以按照第22.2节中的说明查询所有受支持的OpenGL阴影语言版本的#version字符串。OpenGL注册表中提供了OpenGL阴影语言规范

1.3.2 OpenGL ES

OpenGL ES is a royalty-free, cross-platform API for full-function 2D and 3Dgraphics on embedded systems such as mobile phones, game consoles, and vehicles. It consists of well-defined subsets of OpenGL. Each version of OpenGL ESimplements a subset of a corresponding OpenGL version as shown in table 1.1OpenGL ES versions also include some additional functionality taken fromlater OpenGL versions or specific to OpenGL ES. It is straightforward to port codewritten for OpenGL ES to corresponding versions of OpenGL.

OpenGL ES是免版税的跨平台API，用于嵌入式系统（例如手机，游戏机和车辆）上的全功能2D和3D图形。它由定义明确的OpenGL子集组成。如表1.1所示，每个OpenGL ES版本都实现了相应OpenGL版本的子集，如表1.1所示，OpenGL ES还包括一些其他功能，这些功能取自更高版本的OpenGL版本或特定于OpenGL ES的版本。将为OpenGL ES编写的代码移植到相应版本的OpenGL上很简单

Opengl ES	OpenGL
1.0	1.5
2.0	2.0
3.0	3.3
3.1	4.3

OpenGL和OpenGL ES是在控制两个标准的Khronos内并行开发的。 OpenGL 4.3和4.5分别包含最初在OpenGL ES 3.0和OpenGL ES 3.1中定义的其他功能，以提高OpenGL和OpenGL ES实现之间的兼容性。 OpenGL ES规范可在Khronos API注册表中找到，网址为http://www.khronos.org/registry

1.3.3 OpenGL ES Shading Language

The Specification should also be read together with companion documents titled The OpenGL ES Shading Language. Versions 1.00, 3.00, and 3.10 should be read. These documents define versions of the OpenGL Shading Language designed for implementations of OpenGL ES 2.0, 3.0, and 3.1 respectively, but also supported by OpenGL implementations. References to the OpenGL Shading Language Specification hereafter include both OpenGL and OpenGL ES versions of the Shading Language; references to specific sections are to those sections in version 4.60 of the OpenGL Shading Language Specification. OpenGL 4.6 implementations are guaranteed to support versions 1.00, 3.00,and 3.10 of the OpenGL ES Shading Language.The #version strings for all supported versions of the OpenGL Shading Language may be queried as described in section 22.2.The OpenGL ES Shading Language Specifications are available in the Khronos API Registry.

该规范还应与标题为“ OpenGL ES shadow Language”的随附文档一起阅读。应该阅读1.00、3.00和3.10版本。这些文档定义了分别为OpenGL ES 2.0、3.0和3.1的实现而设计的OpenGL阴影语言的版本，但也受OpenGL的实现支持。下文中对OpenGL着色语言规范的引用包括OpenGL和OpenGL ES版本的着色语言。对特定部分的引用是《 OpenGL阴影语言规范》版本4.60中的那些部分。保证OpenGL 4.6实现支持OpenGL ES阴影语言的1.00、3.00和3.10版本。如22.2节所述，可以查询所有受支持的OpenGL阴影语言版本的#version字符串。可在Khronos API注册表中找到

1.3.4 SPIR-V

SPIR-V is a binary intermediate language for representing graphical-shader stages and compute kernels for multiple Khronos APIs, such as OpenCL, OpenGL, and Vulkan

The SPIR-V Specification, and the related SPIR-V Extended Instructions for the OpenGL Shading Language Specification, are available in the Khronos API Registry.

SPIR-V是一种二进制中间语言，用于表示图形着色器阶段并为多个Khronos API（例如OpenCL，OpenGL和Vulkan）的计算内核提供SPIR-V规范，以及相关的OpenGL着色语言的SPIR-V扩展指令规范，可在Khronos API注册表中找到

1.3.5 WebGL

WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES. Developers familiar with OpenGL ES will recognize WebGL as a shader-based API using the OpenGL Shading Language, with constructs that are semantically similar to those of the underlying OpenGL ES API. It stays very close to the OpenGL ES specification, with some concessions made for what developers expect out of memory-managed languages such as JavaScript. The WebGL Specification and related documentation are available in the Khronos API Registry

WebGL是用于基于OpenGL ES的低级3D图形API的跨平台，免版税的Web标准。熟悉OpenGL ES的开发人员将使用OpenGL shadow语言将WebGL视为基于着色器的API，其结构在语义上与基础OpenGL ES API相似。它非常接近OpenGL ES规范，并为开发人员对诸如JavaScript之类的内存管理语言的期望做出了一些让步。 WebGL规范和相关文档可在Khronos API注册表中找到

1.3.6 Window System Bindings 窗口系统绑定

OpenGL requires a companion API to create and manage graphics contexts, windows to render into, and other resources beyond the scope of this Specification.
There are several such APIs supporting different operating and window systems.

1.3.6.1 GLX - X Window System Bindings GLX窗口系统绑定

OpenGL Graphics with the X Window System, referred to as the GLX Specification hereafter, describes the GLX API for use of OpenGL in the X Window System. It is primarily directed at Linux and Unix systems, but GLX implementations also exist for Microsoft Windows, MacOS X, and some other platforms where X is available.

The GLX Specification is available in the OpenGL Registry.

1.3.6.2 WGL - Microsoft Windows Bindings WGL窗口系统绑定

The WGL API supports use of OpenGL with Microsoft Windows. WGL is documented in Microsoft’s MSDN system, although no full specification exists.

1.3.6.3 MacOS X Window System Bindings Macos窗口系统绑定

Several APIs exist supporting use of OpenGL with Quartz, the MacOS X window
system, including CGL, AGL, and NSOpenGLView. These APIs are documented
on Apple’s developer website.

1.3.6.4 EGL - Mobile and Embedded Device Bindings

The Khronos Native Platform Graphics Interface or “EGL Specification” describes
the EGL API for use of OpenGL ES on mobile and embedded devices. EGL implementations supporting OpenGL may be available on some desktop platforms as well. The EGL Specification is available in the Khronos API Registry.

1.3.7 OpenCL

OpenCL is an open, royalty-free standard for cross-platform, general-purpose parallel programming of processors found in personal computers, servers, and mobile devices, including GPUs. OpenCL defines interop methods to share OpenCL memory and image objects with corresponding OpenGL buffer and texture objects, and to coordinate control of and transfer of data between OpenCL and OpenGL. This allows applications to split processing of data between OpenCL and OpenGL; for example, by using OpenCL to implement a physics model and then rendering and interacting with the resulting dynamic geometry using OpenGL. The OpenCL Specification is available in the Khronos API Registry

1.4 Filing Bug Reports 一些bug(API或者shading)

Bug reports on the OpenGL API Specification should be filed in the Khronos
OpenGL-API Github repository, located at URL
https://github.com/KhronosGroup/OpenGL-API
Bug reports on the OpenGL Shading Language Specification should be filed in
the Khronos OpenGL-GLSL Github repository, located at URL
https://github.com/KhronosGroup/OpenGL-GLSL
It is best to file bugs against the most recently released versions, since older
versions are usually not updated for bugfixes.

2.OpenGL Fundamentals OpenGL 基础知识

This chapter introduces fundamental concepts including the OpenGL execution model, API syntax, contexts and threads, numeric representation, context state and state queries, and the different types of objects and shaders. It provides a framework for interpreting more specific descriptions of commands and behavior in the remainder of the Specification

本章介绍了基本概念，包括OpenGL执行模型(Execution Model)，API语法API syntax，上下文和线程contexts and threads，数字表示numeric representation，上下文状态和状态查询 context state and state queries 以及不同类型的对象和着色器different types of objects and shaders…它提供了一个框架用于解释规范其余部分中对命令和行为的更具体的描述.

2.1 Execution Model 执行模型

OpenGL (henceforth, “the GL”) is concerned only with processing data in GPU memory, including rendering into a framebuffer and reading values stored in that framebuffer. There is no support for other input or output devices. Programmers must rely on other mechanisms to obtain user input

OpenGL（以下简称GL）”仅与处理GPU内存中的数据有关，包括渲染到帧缓冲区和读取存储在该帧缓冲区中的值。不支持其他输入或输出设备。程序员必须依靠其他机制来获取用户输入

The GL draws primitives processed by a variety of shader programs and fixedfunction processing units controlled by context state. Each primitive is a point, line segment, patch, pixel rectangle, or polygon.Context state may be changed independently;

GL由上下文状态控制(context state. )的各种着色器程序和固定功能处理单元处理进行绘制图元primitives， 每个图元都是点，线段，面块，像素矩形或多边形(在mesa的gl.h中既可看到对应primitive的分类)， 上下文的状态可以独立更改

the setting of one piece of state does not affect the settings of others (although state and shaders all interact to determine what eventually ends up in the framebuffer). State is set, primitives drawn, and other GL operations described by sending commands in the form of function or procedure calls

一种状态的设置不会影响其他状态的设置（尽管状态和着色器都会相互作用，以确定最终在帧缓冲区中结束的状态）。通过以函数或过程调用的形式发送命令来设置状态，绘制基元以及描述其他GL操作

Primitives are defined by a group of one or more vertices. A vertex defines a point, an endpoint of a line segment, or a corner of a polygon where two edges meet.Data such as positional coordinates, colors, normals, texture coordinates, etc. are associated with a vertex and each vertex is processed independently, in order, and in the same way.The only exception to this rule is if the group of vertices must be clipped so that the indicated primitive fits within a specified region; in this case vertex data may be modified and new vertices created. The type of clipping depends on which primitive the group of vertices represents.

图元由一个或多个顶点vertex定义，vertex顶点定义了两个边相交的点，线段的端点或多边形的角.诸如位置坐标，颜色，法线，纹理坐标等的数据与一个顶点相关联，并且每个顶点都以相同的方式独立地，以相同的方式进行处理.该规则的唯一例外是是否必须修剪掉顶点组，以使指示的图元适合指定区域内,在这种情况下，可以修改顶点数据并创建新的顶点. 裁剪的类型取决于顶点组代表哪个图元.

Commands are always processed in the order in which they are received, although there may be an indeterminate delay before the effects of a command are realized. This means, for example, that one primitive must be drawn completely(完全地) before any subsequent one can affect the framebuffer. It also means that queries and pixel read operations return state consistent with complete execution of all previously invoked GL commands, except where explicitly specified otherwise. In general, the effects of a GL command on either GL state or the framebuffer must be complete before any subsequent command can have any such effects.

命令Commands始终按照接收顺序进行处理，尽管在实现命令效果之前可能会有不确定的延迟;

这意味着必须先绘制一个图元，然后任何后续图元才能影响帧缓冲区

这还意味着查询和像素读取操作返回的状态与所有先前调用的GL命令的完整执行一致，除非另有明确规定

总的来说，GL命令对GL状态或帧缓冲区的影响必须完整，然后任何后续命令才能产生任何此类影响

Data binding occurs on call.This means that data passed to a GL command are interpreted when that command is received.Even if the command requires a pointer to data, those data are interpreted when the call is made, and any subsequent changes to the data have no effect on the GL (unless the same pointer is used in a subsequent command).

数据绑定是在调用时发生的。这意味着传递到GL命令的数据将在接收到该命令时进行解释。即使该命令需要指向数据的指针，这些数据也会在调用时进行解释，并对后续的更改进行解释。数据对GL没有影响（除非在后续命令中使用相同的指针)
The GL provides direct control over the fundamental operations of 3D and 2D graphics. This includes specification of parameters of application-defined shader programs performing transformation, lighting, texturing, and shading operations, as well as built-in functionality such as antialiasing(抗锯齿) and texture filtering. It does not provide a means for describing or modeling complex geometric objects, although shaders can be written to generate such objects. In other words, OpenGL provides mechanisms to describe how complex geometric objects are to be rendered, rather than mechanisms to describe the complex objects themselves.

GL提供了对3D和2D图形基本操作的直接控制。这包括执行转换，照明，纹理和着色操作的应用程序定义的着色器程序的参数规范，以及诸如抗锯齿和纹理过滤的内置功能。尽管可以编写着色器以生成此类对象，但它没有提供用于描述或建模复杂几何对象的方法。

换句话说，OpenGL提供了描述如何渲染复杂几何对象的机制，而不是描述复杂对象本身的机制。

The model for interpretation of GL commands is client-server. That is, a program (the client) issues commands, and these commands are interpreted and processed by the GL (the server). The server may or may not operate on the same computer or in the same address space as the client. In this sense, the GL is network transparent. A server may maintain a number of GL contexts, each of which is an encapsulation of current GL state and objects. A client may choose to be made current to any one of these contexts.

解释GL命令的模型是客户端-服务器。即，程序（客户端）发出命令，并且这些命令由GL（服务器）解释和处理。服务器可能会或可能不会在与客户端相同的计算机上或在相同的地址空间中运行。从这个意义上讲，GL是网络透明的。服务器可以维护多个GL上下文，每个GL上下文都是当前GL状态和对象的封装。客户可以选择了解其中任何一种最新情况。

“Issuing GL commands when the program does not have a current context re%02sults in undefined behavior, up to and including program termination” “在程序没有当前上下文时发出GL命令会导致未定义行为，直至并包括程序终止”

There are two classes of framebuffers: a window system-provided framebuffer associated with a context when the context is made current, and application-created framebuffers. The window system-provided framebuffer is referred to as the default framebuffer. Application-created framebuffers, referred to as framebuffer objects, may be created as desired, A context may be associated with two framebuffers, one for each of reading and drawing operations. The default framebuffer and framebuffer objects are distinguished primarily by the interfaces for configuring and managing their state.

有两类帧缓冲区：当上下文成为当前上下文时，窗口系统提供与上下文相关联的帧缓冲区，以及应用程序创建的帧缓冲区.

窗口系统提供的帧缓冲区称为默认帧缓冲区。应用程序创建的帧缓冲区（称为帧缓冲区对象）可以根据需要创建，上下文可以与两个帧缓冲区相关联，一个用于读取和绘制操作。“默认的帧缓冲区和帧缓冲区对象主要通过配置和管理其状态的接口来区分.

The effects of GL commands on the default framebuffer are ultimately controlled by the window system,which allocates framebuffer resources, determines which portions of the default framebuffer the GL may access at any given time, and communicates to the GL how those portions are structured. Therefore, there are no GL commands to initialize a GL context or configure the default framebuffer.Similarly, display of framebuffer contents on a physical display device (including the ransformation of individual framebuffer values by such techniques as gamma correction) is not addressed by the GL.

GL命令对默认帧缓冲区的影响最终由窗口系统控制，窗口系统分配帧缓冲区资源，确定GL在任何给定时间可以访问默认帧缓冲区的哪些部分，并向GL传达这些部分的结构。因此，没有GL命令来初始化GL上下文或配置默认帧缓冲区。同样，在物理显示设备上显示帧缓冲区内容（包括通过gamma校正等技术转换单个帧缓冲区值）也不由GL处理.

Allocation and configuration of the default framebuffer occurs outside of the GL in conjunction with the window system, using companion APIs described in section 1.3.6.Allocation and initialization of GL contexts is also done using these companion
APIs. GL contexts can be associated with different default framebuffers, and some context state is determined at the time this association is performed

It is possible to use a GL context without a default framebuffer, in which case
a framebuffer object must be used to perform all rendering. This is useful for
applications needing to perform offscreen rendering.

默认帧缓冲区的分配和配置在GL之外与窗口系统一起进行，使用1.3.6节中描述的配套API

GL上下文的分配和初始化也是使用这些配套api完成的。GL上下文可以与不同的默认帧缓冲区相关联，某些上下文状态在执行此关联时确定

可以在没有默认帧缓冲区的情况下使用GL上下文，在这种情况下，必须使用帧缓冲区对象来执行所有渲染。这对于需要执行屏幕外渲染的应用程序非常有用（离屏渲染?）。

OpenGL is designed to be run on a range of platforms with varying capabilities, memory, and performance. To accommodate this variety, we specify ideal behavior instead of actual behavior for certain GL operations. In cases where deviation from the ideal is allowed, we also specify the rules that an implementation must obey if it is to approximate the ideal behavior usefully. This allowed variation in GL behavior implies that two distinct GL implementations may not agree pixel for pixel when presented with the same input, even when run on identical framebuffer configurations

OpenGL被设计为在一系列具有不同功能、内存和性能的平台上运行。为了适应这种变化，我们为某些GL操作指定了理想行为而不是实际行为。在允许偏离理想的情况下，我们还指定了实现要有效地近似理想行为必须遵守的规则。这种允许的GL行为变化意味着两个不同的GL实现在使用相同的输入时可能不一致，即使在相同的帧缓冲区配置上运行也是如此。

Finally, command names, constants, and types are prefixed in the C language binding to OpenGL (by gl, GL_, and GL, respectively), to reduce name clashes with other packages. The prefixes are omitted in this document for clarity.

最后，命令名称，常量和类型在绑定到OpenGL的C语言中带有前缀（分别通过gl，GL_和GL），以减少与其他软件包的名称冲突。为了清楚起见，在本文档中省略了前缀。

2.2 Command Syntax 命令语法

The Specification describes OpenGL commands as functions or procedures using ANSI C syntax. Languages such as C++ and Javascript which allow passing of argument type information permit language bindings with simpler declarations and fewer entry points.

规范将OpenGL命令描述为使用ansic语法的函数或过程。诸如C++和JavaScript的允许参数类型信息传递的语言允许语言绑定使用更简单的声明和更少的入口点

Various groups of GL commands perform the same operation but differ in how arguments are supplied to them. To conveniently accommodate this variation, we adopt a notation for describing commands and their arguments.

不同的GL命令组执行相同的操作，但参数的提供方式不同。为了方便地适应这种变化，我们采用了一种符号来描述命令及其参数。

GL commands are formed from a name which may be followed, depending on the particular command, by a sequence of characters describing a parameter to the command. If present, a digit indicates the required length (number of values) of the
indicated type. Next, a string of characters making up one of the type descriptors from table 2.1 indicates the specific size and data type of parameter values. A final v character, if present, indicates that the command takes a pointer to an array (a vector) of values rather than a series of individual arguments. Two specific examples are:

GL命令由一个名称构成，根据具体命令的不同，名称后面可能跟有一系列字符，这些字符描述了命令的参数。如果存在，则数字表示所示类型的所需长度（值的数目）。接下来，组成表2.1中类型描述符之一的字符串表示参数值的特定大小和数据类型。最后一个v字符（如果存在）表示该命令采用指向值数组（向量）的指针，而不是一系列单独的参数。两个具体的例子是

void glUniform4f( int location, float v0, float v1, float v2, float v3 );
void glGetFloatv( enum pname, float *data );

通常，命令声明的形式为:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gy8qnIuQ-1620876920133)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512114357668.png)]

rtype is the return type of the function. The braces ({}) enclose a series of type descriptors (see table 2.1), of which one is selected.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a1UFEBYJ-1620876920136)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512114818688.png)] indicates no type descriptor.The arguments enclosed in brackets ([args ,] and [, args]) may or may not be present. The N arguments arg1 through argN have type T, which corresponds to one of the type descriptors indicated in table 2.1 (if there are no letters, then the arguments’ type is given explicitly). If the final character is not v, then N is given by the digit 1, 2, 3, or 4 (if there is no digit, then the number of arguments is fixed). If the final character is v, then only arg1 is present and it is an array of N values of the indicated type.

rtype是函数的返回类型, 第一个{}是数据类型，在下表选择了其中的一个。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TTrXkbvc-1620876920137)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512114818688.png)]是表示没描述类型。括在方括号（[args，]和[，args]）中的参数可能存在也可能不存在。 N个参数arg1到argN具有类型T，它对应于表2.1中指示的类型描述符之一（如果没有字母，则显式给出参数的类型）。如果最后一个字符不是v，则N由数字1、2、3或4给出（如果没有数字，则参数个数是固定的）。如果最后一个字符是v，则仅存在arg1，它是指示类型的N个值的数组。

For example,

void Uniform{1234}{if}( int location, T value );

indicates the eight declarations “表示八项声明”

void Uniform1i( int location, int value );
void Uniform1f( int location, float value );
void Uniform2i( int location, int v0, int v1 );
void Uniform2f( int location, float v0, float v1 );
void Uniform3i( int location, int v0, int v1, int v2 );
void Uniform3f( int location, float v0, float v1, float v3 );

Type Descriptor	Corresponding GL Type
b	byte
s	short
i	int
i64	int64
f	float
d	double
ub	ubyte
us	ushort
ui	uint
ui64	uint64

Table 2.1:命令后缀类型描述符与GL参数类型的对应。有关GL类型的定义，请参见表2.2

void Uniform4i( int location, int v0, int v1, int v2, int v3 );
void Uniform4f( int location, float v0, float v1, float v2, float v3 );

Arguments whose type is fixed (i.e. not indicated by a suffix on the command) are of one of the GL data types summarized in table 2.2, or pointers to one of these types. Since many GL operations represent bitfields within these types, transfer blocks of data in these types to graphics hardware which uses the same data types, or otherwise requires these sizes, it is not possible to implement the GL API on an architecture which cannot satisfy the exact bit width requirements in table 2.2. The types clampf and clampd are no longer used, replaced by float and double respectively together with specification language requiring parameter clamping( These changes are backwards-compatible at the compilation and linking levels, and are being
propagated to man pages and header files as well).

其类型是固定的（即，未在命令后缀上指示）的参数属于表2.2中所概述的GL数据类型之一，或这些类型之一的指针。由于许多GL操作表示这些类型中的位域，因此将这些类型的数据块传输到使用相同数据类型或需要这些大小的图形硬件，因此无法在无法满足确切要求的体系结构上实现GL API表2.2中的位宽要求。 “ clampf”和“ clamped”类型不再使用，分别由“ float”和“ double”替换，以及要求参数“ clamping”的规范语言(这些更改在编译和链接级别上是向后兼容的，并且也将传播到手册页和头文件中)

2.2.1 Data Conversion For State-Setting Commands 状态设置命令的数据转换

Many GL commands specify a value or values to which GL state of a specific type (boolean, enum, integer, or floating-point) is to be set. When multiple versions of such a command exist, using the type descriptor syntax described above, any such version may be used to set the state value. When state values are specified using

许多GL命令指定一个或多个值，特定类型（布尔，枚举，整数或浮点）的GL状态将被设置为该值。当存在此类命令的多个版本时，使用上述类型描述符语法，可以使用任何此类版本来设置状态值。

GL type	Bit width	Descriptin
boolean	8	Boolean
byte	8	Signed two’s complement binary integer 带符号的二进制补码整数
ubyte	8	Unsigned binary integer 无符号二进制整数
char	8	Characters making up strings 组成字符串的字符
short	16	Signed two’s complement binary integer 带符号的二进制补码整数
ushort	16	Unsigned binary integer
int	32	Signed two’s complement binary integer
uint	32	Unsigned binary integer
fixed	32	Signed two’s complement 16.16 scaled integer
int64	64	Signed two’s complement binary integer
uint64	64	Unsigned binary integer
sizei	32	Non-negative binary integer size
enum	32	Enumerated binary integer value
intptr	ptrbits	Signed twos complement binary integer
sizeiptr	ptrbits	Non-negative binary integer size
sync	ptrbits	Sync object handle (see section 4.1)
bitfield	32	Bit field
half	16	Half-precision floating-point value encoded in an unsigned scalar
float	32	Floating-point value
clampf	32	Floating-point value clamped to [0, 1]
double	64	Floating-point value
clampd	64	Floating-point value clamped to [0, 1]

​ Table 2.2: GL data types. 表2.2：GL数据类型。

GL types are not C types. Thus, for example, GL type int is referred to as GLint outside this document, and is not necessarily equivalent to the C type int. An implementation must use exactly the number of bits indicated in the table to represent a GL type. ptrbits is the number of bits required to represent a pointer type; in other words, types intptr, sizeiptr, and sync must be large enough to store any CPU address. sync is defined as an anonymous struct pointer in the C language bindings while intptr and sizeiptr are defined as integer types large enough to hold a pointer.

GL类型不是C类型。因此，例如，GL类型int在本文档之外称为GLint，不一定与C类型int等效。实现必须完全使用表中指示的位数来表示GL类型。 ptrbits是表示指针类型所需的位数。换句话说，类型intptr，sizeiptr和sync必须足够大才能存储任何CPU地址。在C语言绑定中，sync被定义为匿名结构指针，而intptr和sizeiptr被定义为足够容纳指针的整数类型

a different parameter type than the actual type of that state, data conversions are
performed as follows:

• When the type of internal state is boolean, zero integer or floating-point values are converted to FALSE and non-zero values are converted to TRUE.
• When the type of internal state is integer or enum, boolean values of FALSE
  and TRUE are converted to 0 and 1, respectively. Floating-point values are
  rounded to the nearest integer. If the resulting value is so large in magnitude
  that it cannot be represented by the internal state variable, the internal state
  value is undefined
• When the type of internal state is floating-point, boolean values of FALSE
  and TRUE are converted to 0.0 and 1.0, respectively. Integer values are converted to floating-point, with or without normalization as described for specific commands.

与该状态的实际类型不同的参数类型，数据转换如下执行:

• 当内部状态的类型为布尔值时，零整数或浮点值将转换为FALSE，非零值将转换为TRUE
• 当内部状态的类型为整数或枚举时，布尔值FALSE和TRUE分别转换为0和1。浮点值四舍五入到最接近的整数。如果结果值的大小太大以致于内部状态变量无法表示，则内部状态值未定义
• 当内部状态的类型是浮点型时，FALSE和TRUE的布尔值分别转换为0.0和1.0。整数值转换为浮点值，包括或不包括特定命令所述的标准化

For commands taking arrays of the specified type, these conversions are performed for each element of the passed array.

Each command following these conversion rules refers back to this section.Some commands have additional conversion rules specific to certain state values and data types, which are described following the reference.

Validation of values performed by state-setting commands is performed after conversion, unless specified otherwise for a specific command.

对于采用指定类型数组的命令，将对传递数组的每个元素执行这些转换.

遵循这些转换规则的每个命令都可以参考本节。某些命令具有特定于某些状态值和数据类型的附加转换规则，在参考之后进行了描述.

由状态设置命令执行的值的验证在转换后执行，除非对特定命令另有规定

2.2.2 Data Conversions For State Query Commands 状态查询命令的数据转换

Query commands (commands whose name begins with Get) return a value or values to which GL state has been set. Some of these commands exist in multiple versions returning different data types. When a query command is issued that returns data types different from the actual type of that state, data conversions are performed as follows. If more than one step is applicable, all relevant steps are applied in the following order:

查询命令（名称以Get开头的命令）返回一个或多个已设置GL状态的值.其中一些命令存在于多个版本中，这些版本返回不同的数据类型.

当发出的查询命令返回与该状态的实际类型不同的数据类型时，数据转换按如下方式执行,如果不止一个步骤，则所有相关步骤按以下顺序应用:

• If a command returning boolean data is called, such as GetBooleanv, a
  floating-point or integer value converts to FALSE if and only if it is zero.
  Otherwise it converts to TRUE.
• If a command returning unsigned integer data is called, such as GetSamplerParameterIuiv, negative values are clamped to zero.
• If a command returning signed or unsigned integer data is called, such as
  GetIntegerv or GetInteger64v, a boolean value of TRUE or FALSE is interpreted as one or zero, respectively. A floating-point value is rounded to the nearest integer, unless the value is an RGBA color component, a normal coordinate, a DepthRange value, or a depth buffer clear value. In these cases, the query command converts the floating-point value to an integer according to the INT entry of table 18.2; a value not in [−1, 1] converts to an undefined
  value
• If a command returning floating-point data is called, such as GetFloatv or
  GetDoublev, a boolean value of TRUE or FALSE is interpreted as 1.0 or
  0.0, respectively. An integer value is coerced to floating-point. Single- and
  double-precision floating-point values are converted as necessary.

Following these steps, if a value is so large in magnitude that it cannot be represented by the returned data type, then the nearest value representable using that type is returned.

When querying bitmasks (such as SAMPLE_MASK_VALUE or STENCIL_WRITEMASK) with GetIntegerv, the mask value is treated as a signed integer, so that mask values with the high bit set will not be clamped when returned as signed integers.

Unless otherwise indicated, multi-valued state variables return their multiple
values in the same order as they are given as arguments to the commands that set
them. For instance, the two DepthRange parameters are returned in the order n
followed by f. Similarly, points for evaluator maps are returned in the order that
they appeared when passed to Map1. Map2 returns Rij in the [(uorder )i + j]th
block of values (see page 687 for i, j, uorder, and Rij )

• 如果调用了返回布尔数据的命令，例如GetBooleanv，则浮点数或整数值仅当为零时才转换为FALSE。否则它将转换为TRUE
• 如果调用返回无符号整数数据的命令，如getSamplerParameterUIV，负值将被钳制为零
• 如果调用返回有符号或无符号整数数据的命令，如GetIntegerv或GetInteger64v，则布尔值TRUE或FALSE分别解释为1或0。浮点值舍入为最接近的整数，除非该值是RGBA颜色分量、法向坐标、深度范围值或深度缓冲区清除值。在这些情况下，query命令根据表18.2的INT条目将浮点值转换为整数；值不在[−1，1]转换为未定义的值
• 如果调用了返回浮点数据的命令，例如GetFloatv或GetDoublev，则布尔值TRUE或FALSE分别解释为1.0或0.0。整数值被强制为浮点数。单精度和双精度浮点值将根据需要进行转换

按照这些步骤，如果值的大小太大以致不能用返回的数据类型表示，那么将返回使用该类型可表示的最接近的值.

当使用GetIntegerv查询位掩码（例如SAMPLE_MASK_VALUE或STENCIL_WRITEMASK）时，掩码值将被视为有符号整数，因此设置为高位的掩码值作为有符号整数返回时将不会被钳位设置为0.

除非另有说明，否则多值状态变量将以与作为设置它们的命令的参数给出的顺序相同的顺序返回它们的多个值。例如，两个DepthRange参数以n后跟f的顺序返回。同样，评估者地图的点按传递给Map1时出现的顺序返回。 Map2在第[[uorder] i + j]个值块中返回Rij（有关i，j，uorder和Rij，请参见第687页)

2.3 Command Execution 命令执行

Most of the Specification discusses the behavior of a single context bound to a single CPU thread. It is also possible for multiple contexts to share GL objects and for each such context to be bound to a different thread. This section introduces concepts related to GL command execution including error reporting, command queue flushing, and synchronization between command streams. Using these tools can increase performance and utilization of the GPU by separating loosely related tasks into different contexts.

规范的大部分内容都讨论了绑定到单个CPU线程的单个上下文( a single context)的行为。多个上下文也可以共享GL对象，并且每个这样的上下文都可以绑定到不同的线程。本节介绍与GL命令执行相关的概念，包括错误报告，命令队列刷新command queue flushing和命令流之间的同步。通过将松散相关的任务分离到不同的上下文中，使用这些可以提高GPU的性能和利用率

Methods to create, manage, and destroy CPU threads are defined by the host CPU operating system and are not described in the Specification. Binding of GL contexts to CPU threads is controlled through a window system binding layer such as those described in section 1.3.6.

2.3.1 Errors

​ The GL detects only a subset of those conditions that could be considered errors.This is because in many cases error checking would adversely impact the performance of an error-free program.

The command: enum GetError( void );

​ is used to obtain error information. Each detectable error is assigned a numeric code. When an error is detected, a flag is set and the code is recorded. Further errors, if they occur, do not affect this recorded code. When GetError is called, the code is returned and the flag is cleared, so that a further error will again record its code. If a call to GetError returns NO_ERROR, then there has been no detectable error since the last call to GetError (or since the GL was initialized).

GL仅检测到那些可能被认为是错误的条件的子集。这是因为在许多情况下，错误检查会对无错误程序的性能产生不利影响.

GetError用于获取错误信息,每个可检测到的错误都分配了一个数字代码。当检测到错误时，将设置标志并记录代码。如果发生其他错误，则不会影响此记录的代码。调用GetError时，将返回代码并清除该标志，以便进一步的错误将再次记录其代码。如果对GetError的调用返回了NO_ERROR，则自上次对GetError的调用以来（或自GL初始化以来，就没有可检测的错误)

​ To allow for distributed implementations, there may be several flag-code pairs. In this case, after a call to GetError returns a value other than NO_ERROR each subsequent call returns the non-zero code of a distinct flag-code pair (in unspecified order), until all non-NO_ERROR codes have been returned. When there are no more non-NO_ERROR error codes, all flags are reset. This scheme requires some positive number of pairs of a flag bit and an integer. The initial state of all flags is cleared and the initial value of all codes is NO_ERROR.

​ 为了允许分布式实现，可能会有几个标志代码对。在这种情况下，在对GetError的调用返回了NO_ERROR以外的值之后，每个后续调用都将返回不同标志代码对的非零代码（以未指定的顺序），直到所有非NO_ERROR代码都已返回。当不再有非NO_ERROR错误代码时，将重置所有标志。该方案需要一些正数的标志位和整数对。清除所有标志的初始状态，并且所有代码的初始值为NO_ERROR.

​ Table 2.3 summarizes GL errors. Currently, when an error flag is set, results of GL operation are undefined only if an OUT_OF_MEMORY error has occurred. In other cases, there are no side effects unless otherwise noted; the command which
generates the error is ignored so that it has no effect on GL state or framebuffer contents. Except as otherwise noted, if the generating command returns a value, it returns zero. If the generating command modifies values through a pointer argument, no change is made to these values.

​ These error semantics apply only to GL errors, not to system errors such as memory access errors. This behavior is the current behavior; the action of the GL in the presence of errors is subject to change, and extensions to OpenGL may define behavior currently considered as an error.

Several error generation conditions are implicit in the description of every GL command(For historical reasons, some older errors do not follow the patterns described below, and cannot easily be changed. The explicit error language with each command always controls behavior when in conflict with this section.)

表2.3总结了GL错误。当前，当设置了错误标志时，仅当发生OUT_OF_MEMORY错误时，GL操作的结果才是未定义的。在其他情况下，除非另有说明，否则没有副作用；生成错误的命令将被忽略，因此它对GL状态或帧缓冲区内容没有影响。除非另有说明，否则如果生成命令返回一个值，则它返回零。如果生成命令通过指针参数％02ment修改了值，则不会对这些值进行任何更改。

这些错误语义仅适用于GL错误，不适用于系统错误，例如内存访问错误。此行为是当前行为； GL在存在错误的情况下的行为可能会发生变化，并且对OpenGL的扩展可能会定义当前被视为错误的行为

每个GL命令的描述中都隐含了多个错误生成条件（由于历史原因，一些较旧的错误未遵循以下描述的模式，并且无法轻松更改。每个命令的显式错误语言在与以下命令冲突时始终控制行为这个部分)

• If the GL context has been reset as a result of previous GL command, or if the context is reset as a side effect of execution of a command, a CONTEXT_LOST error is generated.如果由于先前的GL命令而已重置GL上下文，或者如果由于执行命令而将上下文重置，则会生成CONTEXT_LOST错误
• If a command that requires an enumerated value is passed a symbolic constant that is never allowable for that command, an INVALID_ENUM error is generated. This is the case even if the argument is a pointer to a symbolic constant, if the value or values pointed to are not allowable for the given command. In some cases, a symbolic constant is allowable for a command,
  but is forbidden in combination with current GL state and/or a value passed for another parameter of that command. These cases are documented explicitly, and an INVALID_OPERATION error is generated instead.如果将要求枚举值的命令传递给该命令永远不允许的符号常量，则会生成INVALID_ENUM错误。即使参数是指向符号常量的指针，即使给定命令不允许使用一个或多个指向的值，也是如此。在某些情况下，命令常量允许使用符号常量，但符号常量与当前GL状态和/或为该命令的另一个参数传递的值结合使用是被禁止的。这些情况已明确记录在案，而是生成了INVALID_OPERATION错误
• If a negative number is provided where an argument of type sizei or sizeiptr is specified, an INVALID_VALUE error is generated如果在指定了sizei或sizeiptr类型的参数的情况下提供了负数，则会生成INVALID_VALUE错误
• If memory is exhausted as a side effect of the execution of a command, an OUT_OF_MEMORY error may be generated.如果由于执行命令而耗尽了内存，则可能会生成OUT_OF_MEMORY错误

The Specification attempts to explicitly describe these implicit error conditions(with the exception of CONTEXT_LOST3 and OUT_OF_MEMORY4 wherever they apply. However, they apply even if not explicitly described, unless a specific command escribes different behavior. For example, certain commands use a sizei parameter to indicate the length of a string, and also use negative values of the parameter to indicate a null-terminated string. These commands do not generate an INVALID_VALUE error, because they explicitly describe different behavior.

​ Otherwise, errors are generated only for conditions that are explicitly described in the Specification.

​ When a command could potentially generate several different errors (for example, when it is passed separate enum and numeric parameters which are both out of range), the GL implementation may choose to generate any of the applicable errors.

规范试图明确描述这些隐式错误条件（除了CONTEXT_LOST3(未描述CONTEXT_LOST，因为它几乎可以由几乎所有GL命令生成，并且由于与受影响的命令不直接相关的原因而发生)和OUT_OF_MEMORY4(未描述OUT_OF_MEMORY，因为它可能由任何GL com％02mand生成，即使那些未显式分配GPU内存的应用也是如此)在任何适用的地方。但是，即使没有明确描述，它们也适用，除非特定命令描述了不同的行为。例如，某些命令使用sizei参数表示字符串的长度，并且还使用参数的负值表示以空值结尾的字符串。这些命令不会产生INVALID_VALUE错误，因为它们明确描述了不同的行为。否则，仅针对规范中明确描述的条件才产生错误.

当命令可能会产生几个不同的错误时（例如，当传递单独的枚举和数值参数都超出范围时，则GL实现可以选择生成任何适用的错误”）

Errors based solely on one or more argument values to a command must bedetected before any processing based on current state(This ensures consistent behavior for commands including language which ignores certain parameters under some conditions, such as glBlitFramebuffer treatment of mask and filter).

在基于当前状态的任何处理之前，必须先检测仅基于命令的一个或多个参数值的错误(这确保了命令的一致行为，包括在某些情况下会忽略某些参数的语言，例如glBlitFramebuffer对掩码和过滤器的处理)

Error	Description	Offending command ignored?
CONTEX_LOST	Context has been lost and reset by the driver	Except as noted for specific commands
INVALID_ENUM	enum argument out of range	Yes
INVALIED_VALUE	Numeric argument out of range	Yes
INVALID_OPERATION	Operation illegal in current state	Yes
INVALID_FRAMEBUFFER_OPERATION	Framebuffer object is not complete	Yes
OUT_OF_MEMORY	Not enough memory left to execute command	unknown
STACK_OVERFLOW	Command would cause a stack overflow	Yes
STACK_UNDERFLOW	Command would cause a stack underflow	Yes
TABLE_TOO_LARGE	The specified table is too large	Yes

​ Table 2.3: Summary of GL errors

​ When an error is generated, the GL may also generate a debug output message describing its cause (see chapter 20). The message has source DEBUG_SOURCE_API, type DEBUG_TYPE_ERROR, and an implementation-dependent ID. Most commands include a complete summary of errors at the end of their description, including even the implicit errors described above.

Such error summaries are set in a distinct style, like this sentence.

当产生错误时，GL可能还会生成一条调试输出消息，描述其原因（请参见第20章）。该消息具有源DEBUG_SOURCE_API，类型DEBUG_TYPE_ERROR和与实现有关的ID。大多数命令的描述末尾都包含错误的完整摘要，甚至包括上述隐式错误。

​ In some cases, however, errors may be generated for a single command for reasons not directly related to that command. One such example is that deferred processing for shader programs may result in link errors detected only when attempting to draw rimitives using vertex specification commands. In such cases, errors generated by a command may be described elsewhere in the specification than the command itself.

​ 但是，在某些情况下，由于与该命令不直接相关的原因，单个命令可能会产生错误。这样的一个例子是，仅在尝试使用顶点指定命令绘制边界时，对着色器程序的延迟处理才可能导致检测到链接错误。在这种情况下，由命令产生的错误可能会在规范中除命令本身之外的其他地方进行描述。

2.3.1.1 No Error Mode 无错误模式

​ If the GL context was created with the no error mode enabled, then any place where the driver would have generated an error instead has undefined behavior. This could include application termination. All calls to GetError will return NO_ERROR or OUT_OF_MEMORY. OUT_OF_MEMORY errors are a special case because they already allow for undefined behavior and are more difficult for application developers to predict than other errors. OUT_OF_MEMORY errors may be delayed, which can be useful for optimizing multithreaded drivers, but eventually the OUT_OF_MEMORY error will be reported if an implementation would have reported this error. Since behavior of OUT_OF_MEMORY errors are undefined there is some implementation flexibility here. However, this behavior may provide useful information on some implementations that do report OUT_OF_MEMORY without crashing

如果在启用无错误模式的情况下创建了GL上下文，那么驱动程序将在其中生成错误的任何地方都将具有未定义的行为。这可能包括应用程序终止。对GetError的所有调用将返回NO_ERROR或OUT_OF_MEMORY。 OUT_OF_MEMORY错误是一种特殊情况，因为它们已经允许未定义的行为，并且与其他错误相比，应用程序开发人员更难以预测。 OUT_OF_MEMORY错误可能会延迟，这对于优化多线程驱动程序很有用，但是如果实现将报告此错误，则最终将报告OUT_OF_MEMORY错误。由于未定义OUT_OF_MEMORY错误的行为，因此此处具有一定的实现灵活性。但是，此行为可能会提供确实报告OUT_OF_MEMORY而不会崩溃的某些实现的有用信息。

2.3.2 Graphics Reset Recovery 图形重置恢复

Certain events can result in a reset of the GL context. After such an event, it is referred to as a lost context and is unusable for almost all purposes. Recovery requires creating a new context and recreating all relevant state from the lost context. The current status of the graphics reset state is returned by

enum GetGraphicsResetStatus( void );

The value returned indicates if the GL context has been in a reset state at any point since the last call to GetGraphicsResetStatus:

• NO_ERROR indicates that the GL context has not been in a reset state since
  the last call. NO_ERROR表示自上次调用以来，GL上下文尚未处于重置状态
• GUILTY_CONTEXT_RESET indicates that a reset has been detected that is
  attributable to the current GL context. GUILTY_CONTEXT_RESET指示已检测到归因于当前GL上下文的重置
• INNOCENT_CONTEXT_RESET indicates a reset has been detected that is not
  attributable to the current GL context INNOCENT_CONTEXT_RESET表示已检测到与当前GL上下文无关的重置
• UNKNOWN_CONTEXT_RESET indicates a detected graphics reset whose cause
  is unknown. UNKNOWN_CONTEXT_RESET指示检测到的图形重置，其原因未知

If a reset status other than NO_ERROR is returned and subsequent calls return NO_ERROR, the context reset was encountered and completed. If a reset status is repeatedly returned, the context may be in the process of resetting.

如果返回了非NO_ERROR的重置状态，并且随后的调用返回了NO_ERROR，则上下文重置已遇到并完成。如果重复返回重置状态，则上下文可能正在重置过程中.

Reset notification behavior is determined at context creation time, and may be queried by calling GetIntegerv with pname RESET_NOTIFICATION_STRATEGY.

重置通知行为是在上下文创建时确定的，可以通过使用pname RESET_NOTIFICATION_STRATEGY调用GetIntegerv来查询

If the reset notification behavior is NO_RESET_NOTIFICATION, then the implementation will never deliver notification of reset events, and GetGraphicsResetStatus will always return NO_ERROR(In this case, it is recommended that implementations should not allow loss of context state no matter what events occur. However, this is only a recommendation, and cannot be relied upon by applications)

则实现将永远不会提供重置事件通知，而GetGraphicsResetStatus将始终返回NO_ERROR(在这种情况下，建议无论发生什么事件，实现都不应允许丢失上下文状态。但是，这只是一个建议，不能被应用程序所依赖。)

If the behavior is LOSE_CONTEXT_ON_RESET, a graphics reset will result in the loss of all context state, requiring the recreation of all associated objects. In this case GetGraphicsResetStatus may return any of the values described above.

If a graphics reset notification occurs in a context, a notification must also occur in all other contexts which share objects with that context(The values returned by GetGraphicsResetStatus in the different contexts may differ.).

如果行为是LOSE_CONTEXT_ON_RESET，则图形重置将导致所有上下文状态丢失，需要重新创建所有关联的对象。在这种情况下，GetGraphicsResetStatus可以返回上述任何值。

如果在上下文中发生图形重置通知，则通知也必须在与该上下文共享对象的所有其他上下文中发生(GetGraphicsResetStatus在不同的上下文中返回的值可能会有所不同)。

After a graphics reset has occurred on a context, subsequent GL commands on that context (or any context which shares with that context) will generate a CONTEXT_LOST error. Such commands will not have side effects (in particular,they will not modify memory passed by pointer for query results), and may not block indefinitely or cause termination of the application. Exceptions to this behavior include:

• GetError and GetGraphicsResetStatus behave normally following a
  graphics reset, so that the application can determine a reset has occurred,
  and when it is safe to destroy and re-create the context
• Any commands which might cause a polling application to block indefinitely
  will generate a CONTEXT_LOST error, but will also return a value indicating
  completion to the application. Such commands include:
  • GetSynciv with pname SYNC_STATUS ignores the other parameters
    and returns SIGNALED in values.
  • GetQueryObjectuiv with pname QUERY_RESULT_AVAILABLE ignores the other parameters and returns TRUE in params

在上下文上发生图形重置后，该上下文（或与该上下文共享的任何上下文）上的后续GL命令将生成CONTEXT_LOST错误。这样的命令不会有副作用（特别是它们不会修改指针传递给查询结果的内存），并且不会无限期阻塞或导致应用程序终止。这种行为的例外情况包括:

• 在图形重置后，GetError和GetGraphicsResetStatus正常运行，因此应用程序可以确定发生了重置，以及何时可以安全地销毁并重新创建上下文
• 任何可能导致轮询应用程序无限期阻塞的命令都会生成CONTEXT_LOST错误，但也会向应用程序返回一个指示完成的值。这些命令包括:
  • 带有pname SYNC_STATUS的GetSynciv会忽略其他参数，并在值中返回SIGNALED
  • pname为QUERY_RESULT_AVAILABLE的GetQueryObjectuiv会忽略其他参数，并在参数中返回TRUE

2.3.3 Flush and Finish 刷管线和结束管线

Implementations may buffer multiple commands in a command queue before sending them to the GL server for execution. This may happen in places such as the network stack (for network transparent implementations), CPU code executing as part of the GL client or the GL server, or internally to the GPU hardware. Coarse control over command queues is available using the command:

void Flush( void );

实现可能会将多个命令发送到GL服务器以执行之前，在命令队列中缓冲多个命令。这可能发生在诸如网络堆栈（对于网络透明实现），作为GL客户端或GL服务器的一部分执行，或在GPU硬件内部执行的CPU代码之类的地方。使用命令可以对命令队列进行粗略控制

which causes all previously issued GL commands to complete in finite time( Historically, use of Flush has had negative performance implications for some implementations, and subsequently it does not universally operate as described here. One exception to this is when the default framebuffer is bound, and it is single-buffered; in this case, flush behaves as expected. Other references to the flush operation in the specification, such as that in section 4.1.2, will behave as expected. Waiting on a fence sync object with SYNC_FLUSH_COMMANDS_BIT is thus recommended as a way to perform a guaranteed flush).(although such commands may still be executing when Flush returns).

void Finish( void );

forces all previously issued GL commands to complete. Finish does not return until all effects from such commands on GL client and server state and the framebuffer are fully realized.

Finer control over command execution can be expressed using fence commands and sync objects, as discussed in section 4.1.

这会导致所有先前发出的GL命令在有限的时间内完成（从历史上看，使用Flush对某些实现产生负面的性能影响，因此，它无法按此处所述进行通用操作。一个例外是当绑定了默认帧缓冲区时，并且是单缓冲的；在这种情况下，刷新的行为符合预期。规范中对刷新操作的其他引用（如第4.1.2节中的行为）将符合预期。等待使用SYNC_FLUSH_COMMANDS_BIT的fence同步对象是因此建议将其作为执行有保证的刷新的一种方法）。（尽管在刷新返回时此类命令可能仍在执行).

Finish强制所有先前发布的GL命令完成。直到完全实现了此类命令对GL客户端和服务器状态以及帧缓冲区的所有影响后，Finish才会返回。可以使用fence命令和同步对象来表达对命令执行的精细控制，如第4.1节所述

2.3.4 Numeric Representation and Computation 数值表示和计算

The GL must perform a number of floating-point operations during the course of its operation.

Implementations normally perform computations in floating-point, and must meet the range and precision requirements defined under ”Floating-Point Computation” below.

These requirements only apply to computations performed in GL operations outside of shader execution, such as texture image specification and sampling, and per-fragment operations. Range and precision requirements during shader execution differ and are specified by the OpenGL Shading Language Specification.

In some cases, the representation and/or precision of operations is implicitly limited by the specified format of vertex, texture, or renderbuffer data consumed by the GL. Specific floating-point formats are described later in this section.

GL在其运行过程中必须执行许多浮点运算.实现通常以浮点数执行计算，并且必须满足以下“浮点计算”下定义的范围和精度要求。这些要求仅适用于在着色器执行之外的GL操作中执行的计算，例如纹理图像指定和采样以及每片段操作。着色器执行期间的范围和精度要求有所不同，并由OpenGL着色语言规范指定。在某些情况下，运算的表示形式和/或精度受GL消耗的顶点，纹理或渲染缓冲区数据的指定格式的隐式限制。特定的浮点格式将在本节后面介绍

2.3.4.1 Floating-Point Computation 浮点计算

We do not specify how floating-point numbers are to be represented, or the details of how operations on them are performed.

我们没有指定浮点数的表示方式，也不详细说明如何对它们进行操作

我们只要求数字的浮点部分包含足够的位，并且它们的指数字段足够大，以便浮点运算的单个结果精确到10^5分之一。

所有浮点值的最大可表示大小必须至少为2^32.大多数单精度浮点格式都满足这些要求

作为需要浮点数据的GL命令的输入，任何可表示的浮点值都是合法的。向这样的命令提供一个非浮点数的值的结果是未指定的，但不能导致GL中断或终止。例如，在IEEE算术中，向GL命令提供负零或非规范化数字会产生可预测的结果，而提供NaN或无穷大则会产生未指定的结果。

2.3.4.2 16-Bit Floating-Point Numbers 16位浮点数

A 16-bit floating-point number has a 1-bit sign (S), a 5-bit exponent (E), and a 10-bit mantissa (M). The value V of a 16-bit floating-point number is determined by the following:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DxQoTTCP-1620876920140)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512182754608.png)]

If the floating-point number is interpreted as an unsigned 16-bit integer N, then

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kryr1zkA-1620876920141)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512182809184.png)]

Any representable 16-bit floating-point value is legal as input to a GL command that accepts 16-bit floating-point data. The result of providing a value that is not a floating-point number (such as Inf or NaN ) to such a command is unspecified, but must not lead to GL interruption or termination. Providing a denormalized number or negative zero to GL must yield predictable results.

16位浮点数的表示方式是1位符号位，5位指数，10位尾数.16位浮点数的值V由以下公式确定

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YLV2WayS-1620876920142)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512182754608.png)]

如果浮点数被解释为无符号16位整数N，则

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-woN3Xc4V-1620876920143)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210512182809184.png)]

作为接受16位浮点数据的GL命令的输入，任何可表示的16位浮点值都是合法的。向这样的命令提供非浮点数的值（如Inf或NaN）的结果是未指定的，但不能导致GL中断或终止。向GL提供非规范化数字或负零必须产生可预测的结果

2.3.4.3 Unsigned 11-Bit Floating-Point Numbers 无符号11位浮点数

a 5-bit exponent (E), and a 6-bit mantissa (M).

…

2.4 Rendering Commands 渲染命令

GL commands performing rendering into a framebuffer are sometimes treated specially by other GL operations such as conditional rendering (see section 10.9).
Such commands are called rendering commands, and include the drawing commands Draw (see section 10.4) and Begin / End (see section 10.7), as well as these additional commands:

执行渲染到帧缓冲区的GL命令有时会被其他GL操作（如条件渲染）特别处理（见第10.9节）.

这些命令称为渲染命令，包括绘图命令Draw（见第10.4节）和Begin/End（见第10.7节）以及这些附加命令:

• Accum (see section 17.4.5)
• Bitmap (see section 14.8)
• BlitFramebuffer (see section 18.3.2)
• Clear (see section 17.4.3)
• ClearBuffer* (see section 17.4.3.1)
• CopyPixels (see section 18.3)
• DispatchCompute* (see section 19)
• DrawPixels (see section 18.1)
• EvalMesh1 and EvalMesh2 (see section 21.1)

2.5 Context State 状态机

​ Context state is state that belongs to the GL context as a whole, rather than to instances of the different object types described in section 2.6. Context state controls fixed-function stages of the GPU, such as clipping, primitive rasterization, and framebuffer clears, and also specifies bindings of objects to the context specifying which objects are used during command execution.

Context state also controls the fixed-function stages described as legacy alternatives to shaders for performing transformation, lighting, and texturing

上下文状态是一个整体上属于GL上下文的状态，而不是2.6节中描述的不同对象类型的实例。上下文状态控制GPU的固定功能阶段，例如剪切，原始光栅化和帧缓冲区清除，还指定对象与上下文的绑定，从而指定在命令执行期间使用哪些对象。

上下文状态还控制了固定功能阶段，这些阶段被描述为用于执行转换，照明和纹理化的着色器的传统替代品.

​ The Specification describes all visible context state variables and describes how each one can be changed. State variables are grouped somewhat arbitrarily by their function. Although we describe operations that the GL performs on the framebuffer, the framebuffer is not a part of GL state.

​ There are two types of context state. Server state resides in the GL server; the majority of GL state falls into this category. Client state resides in the GL client. Unless otherwise specified, all state is server state; client state is specifically identified. Each instance of a context includes a complete set of server state; each connection from a client to a server also includes a complete set of client state.

​ 规范描述了所有可见的上下文状态变量，并描述了如何更改每个变量。”状态变量按其功能任意分组。尽管我们描述了GL对帧缓冲区执行的操作，但帧缓冲区不是GL状态的一部分。

有两种类型的上下文状态。服务器状态位于GL服务器中； GL的大多数都属于此类。客户端状态位于GL客户端中。除非另有说明，否则所有状态均为服务器状态；客户端状态是专门确定的。上下文的每个实例instance都包括完整的服务器状态集；例如：从客户端到服务器的每个连接还包括一组完整的客户端状态

While an implementation of OpenGL may be hardware dependent, the Specifi- cation is independent of any specific hardware on which it is implemented. We are concerned with the state of graphics hardware only when it corresponds precisely to GL state” 虽然OpenGL的实现可能依赖于硬件，但该规范与实现它的任何特定硬件无关。只有当图形硬件与GL状态完全对应时，我们才关心图形硬件的状态。

2.5.1 Generic Context State Queries

Context state queries are described in detail in chapter 22.上下文状态查询将在第22章中详细描述

2.6 Objects and the Object Model 对象和对象模型

​ Many types of objects are defined in the remainder of the Specification. Applications may create, modify, query, and destroy many instances of each of these object types, limited in most cases only by available graphics memory. Specific instances of different object types are bound to a context. The set of bound objects define the shaders which are invoked by GL drawing operations; specify the buffer data, texture image, and framebuffer memory that is accessed by shaders and directly by GL commands; and contain the state used by other operations such as fence synchronization and timer queries.

​ Each object type corresponds to a distinct set of commands which manage objects of that type. However, there is an object model describing how most types of objects are managed, described below. Exceptions to the object model for specific object types are described later in the Specification together with those object types.

​ Following the description of the object model, each type of object is briefly described below, together with forward references to full descriptions of that object type in later chapters of the Specification. Objects are described in an order corresponding to the structure of the remainder of the Specification.

​ 规范的其余部分定义了许多类型的对象。应用程序可能会创建，修改，查询和销毁每种对象类型的许多实例，大多数情况下仅受可用图形内存的限制。不同对象类型的特定实例绑定到上下文。绑定对象的集合定义了由GL绘制操作调用的着色器。指定由着色器直接通过GL命令访问的缓冲区数据，纹理图像和帧缓冲区内存；并包含其他操作（例如篱笆同步和计时器查询）使用的状态

​ 每个对象类型对应于一组不同的命令，这些命令管理该类型的对象。但是，有一个对象模型描述了如何管理大多数类型的对象，如下所述。特定对象类型的对象模型的例外情况将在后面的规范中与这些对象类型一起进行描述.

​ 在对象模型的描述之后，下面将简要描述每种类型的对象，并在规范的后续章节中对该对象类型的完整描述进行前瞻性引用。按照与规范其余部分的结构相对应的顺序描述对象。

2.6.1 Object Management 对象管理

2.6.1.1 Name Spaces, Name Generation, and Object Creation 命名空间，生成名称和创建对象

​ Each object type has a corresponding name space. Names of objects are represented by unsigned integers of type uint. The name zero is reserved by the GL;for some object types, zero names a default object of that type, and in others zero will never correspond to an actual instance of that object type.

​ Names of most types of objects are created by generating unused names using commands starting with Gen followed by the object type. For example, the command GenBuffers returns one or more previously unused buffer object names.

​ Generated names are marked by the GL as used, for the purpose of name generation only. Object names marked in this fashion will not be returned by additional calls to generate names of the same type until the names are marked unused again by deleting them (see below).

​ Generated names do not initially correspond to an instance of an object. Objects with generated names are created by binding a generated name to the context. For example, a buffer object is created by calling the command BindBuffer with a name returned by GenBuffers, which allocates resources for the buffer object and its state, and associate the name with that object. Sampler objects may also be created by commands in addition to BindSampler, as described in section 8.2.

​ Objects may also be created directly by functions that return a new name or names representing a freshly initialized object. Some functions return a single object name directly whereas others are able to create a large number of new objects,returning their names in an array. Examples of the former are CreateProgram for program objects and FenceSync for fence sync objects. Examples of the latter are CreateBuffers, CreateTextures and CreateVertexArraysfor buffers, textures and vertex arrays, respectively.

​ 每个对象类型都有对应的名称空间。对象名称由uint类型的无符号整数表示。 GL保留名称零；对于某些对象类型，零名称是该类型的默认对象，而在其他名称中，零将永远不对应于该对象类型的实际实例。

​ 大多数类型的对象的名称是通过使用以Gen开头的命令以及对象类型生成未使用的名称来创建的。例如，命令GenBuffers返回一个或多个先前未使用的缓冲区对象名称

​ GL将生成的名称标记为已使用，仅用于生成名称的目的。以这种方式标记的对象名称将不会通过其他调用返回，以生成相同类型的名称，直到通过删除它们再次将它们标记为未使用的名称为止（请参见下文）

​ 生成的名称最初并不对应于对象的实例。通过将生成的名称绑定到上下文来创建具有生成的名称的对象。例如，通过使用GenBuffers返回的名称调用命令BindBuffer来创建缓冲区对象，该命令为缓冲区对象及其状态分配资源，并将该名称与该对象相关联。如第8.2节中所述，除BindSampler外，还可以通过命令来创建采样器对象。

​ 对象也可以由返回新名称或代表新初始化对象的名称的函数直接创建。一些函数直接返回单个对象名称，而其他函数则可以创建大量新对象，并以数组形式返回其名称。前者的示例是用于程序对象的CreateProgram和用于fence同步对象的FenceSync。后者的示例分别是用于缓冲区，纹理和顶点数组的CreateBuffers，CreateTextures和CreateVertexArrays。

2.6.1.2 Name Deletion and Object Deletion 名字和对象删除

​ Objects are deleted by calling deletion commands specific to that object type. For example, the command DeleteBuffers is passed an array of buffer object names to delete. After an object is deleted it has no contents, and its name is once again marked unused for the purpose of name generation. If names are deleted that do not correspond to an object, but have been marked for the purpose of name generation, such names are marked as unused again. If unused and unmarked names are deleted they are silently ignored, as is the name zero.

​ If an object is deleted while it is currently in use by a GL context, its name is immediately marked as unused, and some types of objects are automatically unbound from binding points in the current context, as described in section 5.1.2. However, the actual underlying object is not deleted until it is no longer in use. This situation is discussed in more detail in section 5.1.3.

​ 通过调用特定于该对象类型的删除命令来删除对象。例如，命令DeleteBuffers传递了要删除的缓冲区对象名称数组。删除对象后，该对象将不包含任何内容，并且将其名称再次标记为未使用，以进行名称生成。如果删除的名称与对象不对应，但已被标记为用于名称生成，则将这些名称再次标记为未使用。如果删除了未使用和未标记的名称，它们将被静默忽略，名称为零。

​ 如果在GL上下文当前正在使用某个对象时删除了该对象，则其名称会立即标记为未使用，并且某些对象类型会自动从当前上下文中的绑定点取消绑定，如5.1.2节中所述。但是，直到不再使用实际的基础对象，才将其删除。这种情况在第5.1.3节中有更详细的讨论。

2.6.1.3 Shared Object State 共享对象状态

​ It is possible for groups of contexts to share some server state. Enabling such sharing between contexts is done through window system binding APIs such as those described in section 1.3.6. These APIs are responsible for creation and management of contexts, and are not discussed further here. More detailed discussion of the behavior of shared objects is included in chapter 5. Except as defined below or specific object types, all state in a context is specific to that context only.

​ 上下文组可能共享某些服务器状态。启用上下文之间的共享是通过窗口系统绑定API（如1.3.6节中描述的API）完成的。这些API负责上下文的创建和管理，这里不再赘述。在第5章中将对共享对象的行为进行更详细的讨论。

除以下定义或特定对象类型外，上下文中的所有状态仅特定于该上下文。

2.6.2 Buffer Objects 缓冲区对象

​ The GL uses many types of data supplied by the client. Some of this data must be stored in server memory, and it is desirable to store other types of frequently used client data, such as vertex array and pixel data, in server memory for performance reasons, even if the option to store it in client memory exists.

​ Buffer objects contain a data store holding a fixed-sized allocation of server memory, and provide a mechanism to allocate, initialize, read from, and write to such memory. Under certain circumstances, the data store of a buffer object may be shared between the client and server and accessed simultaneously by both.

Buffer objects may be shared. They are described in detail in chapter 6.

GL使用了客户端提供的许多类型的数据。其中一些数据必须存储在服务器内存中，出于性能方面的考虑，即使选择将其存储在客户端内存中，也希望将其他类型的经常使用的客户端数据（例如顶点数组和像素数据）存储在服务器内存中。

缓冲对象包含一个数据存储器，该存储器中存储着服务器内存的固定大小分配，并提供了一种分配，初始化，读取和写入此类内存的机制。在某些情况下，缓冲区对象的数据存储区可以在客户端和服务器之间共享，并由两者同时访问

缓冲区对象可以共享。在第6章中对其进行了详细说明

2.6.3 Shader Objects 着色器对象

​ The source and/or binary code representing part or all of a shader program that is executed by one of the programmable stages defined by the GL (such as a vertex or fragment shader) is encapsulated in one or more shader objects.

表示由GL定义的可编程阶段之一执行的着色器程序的部分或全部的源代码和/或二进制代码（例如顶点或片段着色器）被封装在一个或多个着色器对象中

Shader objects may be shared. They are described in detail in chapter 7

可以共享着色器对象。它们在第7章中有详细描述。

2.6.4 Program Objects 程序对象

​ Shader objects that are to be used by one or more of the programmable stages of the GL are linked together to form a program object. The shader programs that are executed by these programmable stages are called executables. All information necessary for defining each executable is encapsulated in a program object.

将由GL的一个或多个可编程阶段使用的着色器对象链接在一起以形成一个程序对象。由这些可编程阶段执行的着色器程序称为可执行文件。定义每个可执行文件所需的所有信息都封装在程序对象中

Program objects may be shared. They are described in detail in chapter 7.

2.6.5 Program Pipeline Objects

​ Program pipeline objects contain a separate program object binding point for each programmable stage. They allow a primitive to be processed by independent programs in each programmable stage, instead of requiring a single program object for each combination of shader operations. They allow greater flexibility when combining different shaders in various ways, without requiring a program object for each such combination.

Program pipeline objects are container objects including references to program objects, and are not shared. They are described in detail in chapter 7.

​ 程序管线对象为每个可编程阶段包含一个单独的程序对象绑定点。它们允许在每个可编程阶段中由独立程序处理原语，而不是为着色器操作的每种组合都要求单个程序对象。当以各种方式组合不同的着色器时，它们提供了更大的灵活性，而无需为每种这样的组合使用程序对象

程序管线对象是容器对象，包括对程序对象的引用，并且不共享。它们将在第7章中详细介绍

2.6.6 Texture Objects 纹理对象

​ Texture objects or textures include a data store containing a collection of texture images built from arrays of image elements. The image elements are referred to as texels. There are many types of texture objects varying by dimensionality and structure; the different texture types are described in detail in the introduction to chapter 8.

​ Texture objects also include state describing the image parameters of the texture images, and state describing how sampling is performed when a shader accesses a texture.

​ Shaders may sample a texture at a location indicated by specified texture coordinates, with details of sampling determined by the sampler state of the texture. The resulting texture samples are typically used to modify a fragment’s color, in order to map an image onto a geometric primitive being drawn, but may be used for any purpose in a shader.

Texture objects may be shared. They are described in detail in chapter 8

纹理对象或纹理包括一个数据存储，其中包含从图像元素数组构建的纹理图像的集合。图像元素称为纹理像素。有许多类型的纹理对象随尺寸和结构的不同而变化。在第8章的导言中详细描述了不同的纹理类型

纹理对象还包括描述纹理图像的图像参数的状态，以及描述在着色器访问纹理时如何执行采样的状态

着色器可以在指定的纹理坐标表示的位置对纹理进行采样，采样的详细信息由纹理的采样器状态决定。生成的纹理样本通常用于修改片段的颜色，以将图像映射到要绘制的几何图元上，但可以用于着色器中的任何目的。

纹理对象可以共享。它们将在第8章中详细描述。

2.6.7 Sampler Objects 采样器对象

​ Sampler objects contain the subset of texture object state controlling how sampling is performed when a shader accesses a texture. Sampler and texture objects may be bound together so that the sampler object state is used by shaders when sampling
the texture, overriding equivalent state in the texture object. Separating texture image data from the method of sampling that data allows reuse of the same sampler state with many different textures without needing to set the sampler state in each texture.

Sampler objects may be shared. They are described in detail in chapter 8.

采样器对象包含纹理对象状态的子集，该子集控制在着色器访问纹理时如何执行采样。采样器和纹理对象可以绑定在一起，以便着色器在采样纹理时使用采样器对象状态，从而覆盖纹理对象中的等效状态。将纹理图像数据从采样方法中分离出来，该数据允许在许多不同纹理上重复使用同一采样器状态，而无需在每个纹理中都设置采样器状态。

采样器对象可以共享。它们将在第8章中详细描述。

2.6.8 Renderbuffer Objects 渲染缓冲区对象

​ Renderbuffer objects contain a single image in a format which can be rendered to. Renderbuffer objects are attached to framebuffer objects (see below) when performing off-screen rendering.

Renderbuffer objects may be shared. They are described in detail in chapter 9

Renderbuffer对象包含可以渲染的格式的单个图像。执行屏幕外渲染时，Renderbuffer对象将附加到framebuffer对象（请参见下文）。

渲染缓冲区对象可以共享。它们将在第9章中详细介绍

2.6.9 Framebuffer Objects 帧缓冲对象

​ Framebuffer objects encapsulate the state of a framebuffer, including a collection of color, depth, and stencil buffers. Each such buffer is represented by a renderbuffer object or texture object attached to the framebuffer object.

​ Framebuffer objects are container objects including references to renderbuffer and/or texture objects, and are not shared(Framebuffer objects created with the commands defined by the GL_EXT_framebuffer_object extension are defined to be shared, while FBOs created with commands defined by the OpenGL core or GL_ARB_framebuffer_object extension are defined to not be shared. Undefined behavior results when using FBOs created by EXT commands through non-EXT interfaces, or vice-versa.). They are described in detail in chapter 9.

帧缓冲区对象封装了帧缓冲区的状态，包括颜色，深度和模板stencil缓冲区的集合。每个此类缓冲区均由附加到帧缓冲区对象的渲染缓冲区对象或纹理对象表示。

帧缓冲区对象是渲染缓冲区和纹理缓冲区的容器，不可共享（用GL_EXT_framebuffer_object扩展定义的命令创建的帧缓冲对象被定义为共享，而用 OpenGL 核心或GL_ARB_framebuffer_object扩展定义的命令创建的 FBO 则定义为不共享。使用 EXT 命令通过非 EXT 接口创建的 FBO 时，会产生未定义的行为结果，反之亦然）

它们在第9章中有详细描述

2.6.10 Vertex Array Objects 顶点数组对象

​ Vertex array objects represent a collection of sets of vertex attributes. Each set is stored as an array in a buffer object data store, with each element of the array having a specified format and component count. The attributes of the currently bound vertex array object are used as inputs to the vertex shader when executing drawing commands.

​ Vertex array objects are container objects including references to buffer objects, and are not shared. They are described in detail in chapter 10.

顶点数组对象表示顶点属性集的集合。每个集合作为一个数组存储在缓冲区对象数据存储中，数组的每个元素都具有指定的格式和组件计数。当前绑定的顶点数组对象的属性在执行绘图命令时用作顶点着色器的输入

顶点数组对象是容器对象，包括对缓冲区对象的引用，**是不共享的。**它们在第10章中有详细描述

2.6.11 Transform Feedback Objects 转换反馈对象

​ Transform feedback objects are used to capture attributes of the vertices of transformed primitives passed to the transform feedback stage when transform feedback mode is active. They include state required for transform feedback together with references to buffer objects in which attributes are captured.

ransform feedback objects are container objects including references to buffer objects, and are not shared. They are described in detail in section 13.3.1

转换反馈对象用于捕捉变换反馈模式激活时传递到变换反馈阶段的变换原语顶点的属性。它们包括转换反馈所需的状态以及对捕获属性的缓冲区对象的引用。
转换反馈对象是容器对象，包括对缓冲区对象的引用，不共享。第13.3.1节对其进行了详细说明

2.6.12 Query Objects 查询对象

​ Query objects return information about the processing of a sequence of GL commands, such as the number of primitives processed by drawing commands; the number of primitives written to transform feedback buffers; the number of samples that pass the depth test during fragment processing; and the amount of time required to process commands.

Query objects are not shared. They are described in detail in section 4.2.

查询对象返回有关处理一系列GL命令的信息，例如由绘图命令处理的原语的数目；为转换反馈缓冲区而编写的原语的数目；碎片处理过程中通过深度测试的样本数量；以及处理命令所需的时间

查询对象不共享。第4.2节对此进行了详细说明。

2.6.13 Sync Objects 同步对象

A sync object acts as a synchronization primitive – a representation of events whose completion status can be tested or waited upon. Sync objects may be used for synchronization with operations occurring in the GL state machine or in the graphics pipeline, and for synchronizing between multiple graphics contexts, among other purposes.

Sync objects may be shared. They are described in detail in section 4.1

sync对象充当同步原语，表示可以测试或等待其完成状态的事件。Sync对象可用于与GL状态机或图形管道中发生的操作进行同步，以及在多个图形上下文之间进行同步，以及其他目的。

可以共享同步对象。第4.1节对其进行了详细描述。

2.6.14 Display Lists “显示列表”

​ A display list is an object representing a group of GL commands and their parameters which have been stored in server memory for subsequent execution. This may be desirable for performance reasons when the GL client and server are separated
by a network, or when the CPU to GPU interface is too slow to keep the GPU fully fed. Most of the benefits of display lists can be more easily achieved in modern graphics architectures by storing as much data as possible in GL objects in server memory, and display lists have been deprecated.

Display lists may be shared. They are described in detail in chapter 21.4

显示列表是一个对象，表示一组GL命令及其参数，这些命令和参数已存储在服务器内存中以供后续执行。当GL客户机和服务器被网络分开时，或者当CPU到GPU的接口太慢而无法保持GPU完全供电时，出于性能原因，这可能是需要的。在现代图形体系结构中，通过在服务器内存中的GL对象中存储尽可能多的数据，可以更容易地实现显示列表的大部分好处，显示列表已被弃用。

“显示列表可以共享。它们在第21.4章中有详细描述。”

3.Dataflow Model 数据流模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9r4xqHht-1620876920144)(/home/zhangzhijie/.config/Typora/typora-user-images/image-20210513111715549.png)]

​ Figure 3.1 shows a block diagram of the GL. Some commands specify geometric objects to be drawn while others specify state controlling how objects are handled by the various stages, or specify data contained in textures and buffer objects. Most commands may be accumulated in a display list for processing by the GL at a later time. Otherwise, commands are effectively sent through a processing pipeline. Different stages of the pipeline use data contained in different types of buffer objects. Some pipeline stages may use data in client memory instead of, or in addition to data in buffer objects. Data in client memory are not shown in the block diagram, but are described later in the specification as part of the description of those pipeline stages.

​ The first stage assembles vertices to form geometric primitives such as points, line segments, and polygons. In the next stage vertices may be transformed and lit, followed by assembly into geometric primitives. Tessellation and geometry shaders may then generate multiple primitives from a single input primitive. Optionally, the results of these pipeline stages may be fed back into buffer objects using transform feedback.

​ The final resulting primitives are clipped to a clip volume in preparation for the next stage, rasterization. The rasterizer produces a series of framebuffer addresses and values using a two-dimensional description of a point, line segment, or polygon. Each fragment so produced is fed to the next stage that performs operations on individual fragments before they finally alter the framebuffer. These operations include conditional updates into the framebuffer based on incoming and previously stored depth values (to effect depth buffering), blending of incoming fragment colors with stored colors, as well as masking, stenciling, and other logical operations on fragment values.

​ There is a way to bypass the vertex processing portion of the pipeline to send a block of fragments directly to the individual fragment operations, eventually causing a block of pixels to be written to the framebuffer, and pixels may also be read back from the framebuffer or copied from one portion of the framebuffer to another. These transfers may include some type of decoding or encoding.

​ Some additional stages are not shown in figure 3.1. One such stage computes vertices by evaluating polynomial functions of input values, providing an efficient means for approximating curve and surface geometry rather than specifying each vertex explicitly. Another operates on pixel data in the process of reading from or writing to the framebuffer or texture images.

​ Finally, compute shaders which may read from and write to buffer objects may be executed independently of the pipeline shown in figure 3.1.

​ This ordering is meant only as a tool for describing the GL, not as a strict rule of how the GL is implemented, and we present it only as a means to organize the various operations of the GL. Objects such as curved surfaces, for instance, may be transformed before they are converted to polygons.

​ 图3.1显示了GL的数据流框图。一些命令指定要绘制的几何对象，而其他命令指定控制对象如何被各个阶段处理的状态，或者指定纹理和缓冲对象中包含的数据.大多数命令可能会累积在显示列表中，以供GL稍后处理。 否则，命令将通过处理管道有效发送。流水线的不同阶段使用包含在不同类型的缓冲区对象中的数据. 某些流水线阶段可能会使用客户端内存中的数据来代替缓冲区对象中的数据，或者除了缓冲区对象中的数据之外，还会使用这些数据。客户端存储器中的数据未在框图中显示，但将在本规范的后面部分描述，作为这些流水线阶段描述的一部分。

​ 第一阶段组装顶点以形成几何图元，例如点，线段和多边形。在下一阶段，可以对顶点进行变换和照亮，然后将其组装成几何图元.镶嵌器和几何着色器可以从单个输入图元生成多个图元。可选地，可以使用转换反馈将这些流水线阶段的结果反馈到缓冲区对象中.

​ 最终生成的图元将被裁剪到一个裁剪卷中，以准备进行下一阶段的光栅化，光栅化器使用点，线段或多边形的二维描述来生成一系列帧缓冲区地址和值。这样产生的每个片段将被馈送到下一个阶段，在它们最终改变帧缓冲区之前，对各个片段执行操作.这些操作包括基于传入的和先前存储的深度值（以实现深度缓冲）对帧缓冲区进行条件更新，将传入的片段颜色与所存储的颜色混合，以及对片段值进行屏蔽，模板化和其他逻辑操作.

​ 有一种方法可以绕过流水线的顶点处理部分，直接将片段块发送到各个片段操作，最终导致将像素块写入帧缓冲区，还可以从帧缓冲区读回像素或从帧缓冲区的一部分复制到另一部分。这些传输可能包括某种类型的解码或编码。

​ 其他一些阶段未在图3.1中显示。一个这样的阶段通过评估输入值的多项式函数来计算顶点，从而提供了一种有效的方法来逼近曲线和曲面几何形状，而不是显式指定每个顶点。另一个在读取或写入帧缓冲区或纹理图像的过程中对像素数据进行操作.最后，可以从缓冲区对象读取和写入缓冲区对象的计算着色器可以独立于图3.1中所示的管道执行.

​ 此顺序仅是用于描述GL的工具，而不是作为GL实现的严格规则，我们仅将其呈现为组织GL各种操作的一种手段。例如，曲面之类的对象可以先转换，然后再转换为多边形