Vulkan规范：第一章

1. 简介

本章，除了“术语”、“规范化参考”小节，都是介绍性的信息。

这份文档，被称为“Vulkan 规范”或者此后仅称为“规范”，描述了Vulkan图形系统： 它是什么，它怎么行动，和实现它需要做什么。我们假设读者对计算机图形学有基础的 了解。这表示要对计算机图形学算法、术语，和现代化的GPU（Graphic Processing Units）熟悉。

官方版本的规范在Vulkan注册机构可获取，在下面的链接中

http://www.khronos.org/registry/vulkan/

1.1. Vulkan图形系统是什么?

Vulkan是一个图形和计算硬件的API（Application Programming Interface）。 这个API由很多命令组成，它们允许程序员指定着色器程序，计算内核，对象和操作 产生高质量的图像，特别是三维对象的彩色图像。

1.1.1. 程序员的视角看Vulkan

对程序员来讲，Vulkan是一些命令的集合，允许内核或者着色器，和shader执行的外部 Vulkan aspect控制，使用着色器程序或者着色器和数据。 通常，数据是指二维或者三维几何物体和纹理图像，着色器和内核控制数据的处理， 几何物体的光栅化，光栅化产生的光照和阴影的片段，及最终把几何对象渲染到帧缓冲区。

一个典型的Vulkan程序以调用系统函数打开窗口或者准备程序绘制显示的设备为开始。 然后，调用命令打开队列，并向其提交命令缓冲区。 命令缓冲区包含一系列命令，它们将会被底层的硬件执行。 应用程序能够做到：分配设备内存，关联内存和资源，从命令缓冲区中引用这些资源。 绘制命令可调用应用程序的着色器程序，然而使用资源里的数据并产生图像。 为了展示结果图像，一些平台相关的命令需要把结果图像转移到显示设备或者窗口。

1.1.2. 实现者的角度看Vulkan

对于实现者，Vulkan是一系列命令的集合，它允许构造命令缓冲区并提交到设备。 现代化的设备几乎对所有Vulkan操作都加速了，把数据和帧缓冲区存储在高速内存， 在专用的GPU上执行着色器。 实现者的任务是在主机端提供软件lib，它实现了Vulkan API，把每一个Vulkan命令适当的 映射到图形硬件以利用物理设备的能力。

1.1.3. 我们的视角看Vulkan

我们把Vulkan看作拥有绘制操作可调用的可编程阶段和状态驱动固定阶段的管线。 我们期待这个模型可产生一个规范，满足程序员和Vulkan实现者的需要。 然而，它并不提供如何实现的模型。Vulkan实现必须产生符合这些特定方法产生的结果，但是， 可以执行比指定方法更加高效率的计算方法。

1.2. Bug报告

Issues with and bug reports on the Vulkan Specification and the API Registry can be filed in the Khronos Vulkan GitHub repository, located at URL

http://github.com/KhronosGroup/Vulkan-Docs

Please tag issues with appropriate labels, such as “Specification”, “Ref Pages” or “Registry”, to help us triage and assign them appropriately. Unfortunately, GitHub does not currently let users who do not have write access to the repository set GitHub labels
on issues. In the meantime, they can be added to the title line of the issue set in brackets, e.g. ''[Specification]''.

1.3. 术语

The key words must, required, shall should, recommend, may,
and optional in this document are to be interpreted as described in RFC 2119:

http://www.ietf.org/rfc/rfc2119.txt

must

When used alone, this word, or the term required, means that the definition is an absolute requirement of the specification. When followed by not (“must not”
), the phrase means that the definition is an absolute prohibition of the specification.

should

When used alone, this word, or the adjective recommended, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood
and carefully weighed before choosing a different course. When followed by not (“should not”),
the phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications shouldbe
understood and the case carefully weighed before implementing any behavior described with this label.

may

This word, or the adjective optional, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels
that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option must be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.
In the same vein an implementation which does include a particular option must be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).

The additional terms can and cannot are to be interpreted as follows:

can

This word means that the particular behavior described is a valid choice for an application, and is never used to refer to implementation behavior.

cannot

This word means that the particular behavior described is not achievable by an application. For example, an entry point does not exist, or shader code is not capable of expressing an operation.

Note There is an important distinction between cannot and must not, as used in this Specification. Cannotmeans something the application literally is unable to express or accomplish through the API, while must not means something that the application is capable of expressing through the API, but that the consequences of doing so are undefined and potentially unrecoverable for the implementation.

editing-note TODO (Jon) - We might need to augment the RFC 2119 definition of must not to include some of the previous note, since at present it is defined solely in terms of implementation behavior. See Gitlab issue #9.

1.4. Normative References

Normative references are references to external documents or resources to which implementers of Vulkan must comply.

IEEE Standard for Floating-Point Arithmetic, IEEE Std 754-2008, http://dx.doi.org/10.1109/IEEESTD.2008.4610935,
August, 2008.

A. Garrard, Khronos Data Format Specification, version 1.1,https://www.khronos.org/registry/dataformat/specs/1.1/dataformat.1.1.html,
June, 2016.

J. Kessenich, SPIR-V Extended Instructions for GLSL, Version 1.00, https://www.khronos.org/registry/spir-v/,
February 10, 2016.

J. Kessenich and B. Ouriel, The Khronos SPIR-V Specification, Version 1.00, https://www.khronos.org/registry/spir-v/,
February 10, 2016.

J. Leech and T. Hector, Vulkan Documentation and Extensions: Procedures and Conventions,https://www.khronos.org/registry/vulkan/,
July 11, 2016

Vulkan Loader Specification and Architecture Overview, https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md,
August, 2016.