Vulkan是一个跨平台的2D和3D绘图应用程序接口（API），最早由科纳斯(Khronos)组织在2015年游戏开发者大会（GDC）上发表。旨在替代OpenGL，提高图形性能。
   基于OpenGL的图形引擎，其渲染过程粗略可分为 主机端资源准备，设备端数据交互与管线准备 及 每帧循环的渲染 三个部分。 Vulkan的最大任务不是竞争DirectX，而是取代OpenGL，所以重点要看和后者的对比。
   Vulkan在很大程度上汲取了AMD Mantle的灵感，但是进行了大幅度的扩展和增强，构成了一个完善的开发体系，功能和性能都十分丰富，拥有最新图形技术、通用目的计算、预编译着色器、多核心多线程高效率、底层驱动过载、横跨桌面/移动/主机/嵌入式、底层GPU硬件控制、精炼API。Vulkan 是完全从零开始设计，以最小化驱动器中的 CPU 开销，并能让您的应用更直接地控制 GPU 操作。Vulkan 还允许多个线程同时执行工作，如命令缓冲区构建，以获得更好的并行化。
   Vulkan支持的操作系统包括：Linux, Windows XP to Windows 10, android等。Vulkan还可以支持主流的GPU，包括：AMD, NVIDIA, Adreno, PowerVR, Mali等桌面GPU和移动GPU。
   Vulkan的shading language环境： Vulkan不再使用GLSL作为shading language的输入，而是使用一个统一的中间代码(SPIR)作为输入。OpenGL/OpenGL ES或者游戏引擎使用的GLSL都会被一个SPIR-V解释器翻译成SPIR表示。未来其它的shading language或者通用计算的语言也会被翻译成SPIR作为Vulkan的输入。这可以使Vulkan驱动专注于shader的后端优化，而不是前端的语法解析，语义分析等。对于GLSL转SPIR，Khronos正在考虑实现一个编译器前端来帮助应用程序转换。
 
The Khronos Group ，vulkan 开源集- https://github.com/KhronosGroup
 关于Vulkan的详细使用参考这个Demo- https://github.com/SaschaWillems/Vulkan
 Vulkan标准参考Khronos官网- https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
 OpenGL的替代者 Vulkan- https://blog.csdn.net/coloriy/article/details/79908631
 
  OpenGL还算是对初学者比较友好的API，但到了Vulkan，由于严格把pipeline、descriptor、buffer分开，初学者上手难度变大了，App开发者直接调用图形API的情况将会减少，更多地会依赖于图形引擎。因此，Vulkan标准的渐渐普及会加速开发者的层级分划，使用Vulkan的人将是专业研究图形引擎或作GPGPU算法引擎的人。
   对于有志于研究图形的初学者，可以直接学习Vulkan，不用去学习OpenGL了，Vulkan标准与GPU工作原理更为贴近，学习 Vulkan更有利于掌握图形显示的知识。

OpenGL的替代者——Vulkan
 
Vulkan是一个跨平台的2D和3D绘图应用程序接口（API），最早由科纳斯(Khronos)组织在2015年游戏开发者大会（GDC）上发表。旨在替代OpenGL，提高图形性能。
 
基于OpenGL的图形引擎性能瓶颈
 
基于OpenGL的图形引擎，其渲染过程粗略可分为 主机端资源准备，设备端数据交互与管线准备 及 每帧循环的渲染 三个部分。
 
资源加载
 
这一过程跟GPU没有太大关系，主要是为了进行显示之前的图片解码、字体解析、3D模型解析等等。一般可以放到其他线程中执行，避免影响显示。
 
数据交互与管线准备
 

 这一过程主要是将必要的数据传到GPU可以读到内存中去，以及准备GPU的指令。
 1､纹理上传
 2､Shader的编译与Program的链接
 3､VBO的数据上传
 
每帧的图形渲染
 

 1､数据交互耗时。
 这里主要需要设常量区的数据。我们绝大部分情况都是在绘制变化的物体，而变化相关的属性主要体现在常量区，因此每帧渲染都需要重新设一遍常量数据。
 2､调用Drawcall耗时。
 DrawCall指真正执行绘制任务的图形API，如glDrawArrays, glDrawElements。调用这些API时，GPU驱动需要产生GPU硬件所能识别的任务，并发送到内核，等待调度执行。
 
Vulkan编程
 
关于Vulkan的详细使用参考这个Demo：
https://github.com/SaschaWillems/Vulkan
 
Vulkan标准参考Khronos官网：
https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
 
编程流程
 
基本的Vulkan编程流程：

 这个流程和OpenCL的使用流程很像，就是找到设备——创建上下文——创建命令队列——准备任务——发送执行。
 
Vulkan的窗口系统(WSI)（与EGL标准类似）：

 注意到，在移动设备上使用OpenGL时，我们必须通过egl的API先准备好Surface和Context，而在Vulkan标准里面，WSI只是为Command Buffer 提供了 VkFrameBuffer，这个是图形渲染的输出。
 
Pipeline
 
创建Command Buffer 的三个重要元素分别为 VkDescriptorSet（纹理和常量）、VkPipeline（着色器和状态）和VkBuffer（顶点数组）。
 官网上对Pipeline由下图描述：
 
以前的GLProgram现在对应于一个VkPipeline，但VkPipeline除了Program之外，还覆盖了 blend，cull face 等状态：

 Vulkan中的Shader只支持spv的标准二进制格式，我们所写的glsl都必须通过官方的一个转换器转换为二进制格式。这样做就不需要GPU驱动去做语法解析等编译前端工作了。
 
以前在OpenGL中用的Texture 现在由VkImage描述：
 
Command Buffer
 
一个用于图形渲染的 VkCommandBuffer 制作过程如下图：

 如图所示，Command Buffer 里面设定了图形渲染所需要的视口、裁剪、管线（各种状态配置和着色器）、顶点数组、描述（纹理、程序常量等）这些属性，之后再发送到命令队列(VkQueue)中就可以执行。
 
Vulkan的优势
 
效率上的提升
 
Vulkan在效率上的提升主要是它天然支持多线程：
 
异步数据交互
 
使用OpenGL时，如果把数据交互放到另一个独立线程中完成，将会引起冲突，这个原因是上传资源和进行绘制时都需要改变上下文：
 
用Vulkan则没有这个问题：
 
并行绘制
 
由于绘制时要改变上下文，OpenGL的并行绘制无疑也不可能了：
 
Vulkan可以并行创建Command Buffer，但由于Command Buffer 提交后就都是GPU驱动怎么执行的事了，执行的过程没必要也没可能用多线程加速。
 
复用Command Buffer
 
OpenGL 每帧绘制时，都需要在驱动层重新建一个Command Buffer 传递下去，而 Vulkan 是在应用层建好 Command Buffer，每帧绘制时Sub上去。
 
便于模块化
 
虽然初看上去Vulkan比OpenGL复杂了许多，需要多写不少代码，但真正到软件开发时，由于Vulkan、OpenGL大部分情况都是用来写引擎，中间件的，维护代码的时间会远大于开发代码的时间，多写那几行代码根本不算啥。
 Vulkan更容易封装，各子模块之间互不影响，软件架构设计会轻松不少，开发维护起来更为方便。
 而基于OpenGL开发的各子模块之间总有各种各样因为状态机的缘故引发的Bug，比如：
 1､A模块用了VBO，B模块没有用，集成在一起时由于B模块没有把GL_ARRAY_BUFFER 重新绑定为0,出现段错误。
 2､A模块内部使用了FBO，使用FBO时重新设置了裁剪区域和视口大小，使用完成后没有恢复，导致集成之后，后续的模块绘制出现问题。
 如果基于Vulkan开发，上述的状态不一致的问题将会少很多。
 
当然，基于Vulkan开发的引擎一般会用多线程加速，这个也会有不少坑，但为了更好的性能，也是值得的。
 
Vulkan对开发者的影响
 
OpenGL还算是对初学者比较友好的API，但到了Vulkan，由于严格把pipeline、descriptor、buffer分开，初学者上手难度变大了，App开发者直接调用图形API的情况将会减少，更多地会依赖于图形引擎。因此，Vulkan标准的渐渐普及会加速开发者的层级分划，使用Vulkan的人将是专业研究图形引擎或作GPGPU算法引擎的人。
 
对于有志于研究图形的初学者，可以直接学习Vulkan，不用去学习OpenGL了，Vulkan标准与GPU工作原理更为贴近，学习 Vulkan更有利于掌握图形显示的知识。

#define KPI 3.1415926
void Perspective(GLfloat fovy, GLfloat aspect, GLfloat zNear,  GLfloat zFar)
{
	glMatrixMode(GL_PROJECTION);
	glLoadIdentity();

	double xmin, xmax, ymin, ymax;
	ymax = zNear * tan(fovy * KPI / 360);
	ymin = -ymax;
	xmin = ymin * aspect;
	xmax = ymax * aspect;

	glFrustumf(xmin, xmax, ymin, ymax, zNear, zFar);
	glMatrixMode(GL_MODELVIEW);
	glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);	
	glDepthMask(GL_TRUE);
}

void gluLookAt(GLfloat eyex, GLfloat eyey, GLfloat eyez,

			   GLfloat centerx, GLfloat centery, GLfloat centerz,

			   GLfloat upx, GLfloat upy, GLfloat upz)

{

	GLfloat m[16];

	GLfloat x[3], y[3], z[3];

	GLfloat mag;


	/* Make rotation matrix */

	/* Z vector */

	z[0] = eyex - centerx;

	z[1] = eyey - centery;

	z[2] = eyez - centerz;

	mag = sqrt(z[0] * z[0] + z[1] * z[1] + z[2] * z[2]);

	if (mag) {                   /* mpichler, 19950515 */

		z[0] /= mag;

		z[1] /= mag;

		z[2] /= mag;

	}

	/* Y vector */

	y[0] = upx;

	y[1] = upy;

	y[2] = upz;

	/* X vector = Y cross Z */

	x[0] = y[1] * z[2] - y[2] * z[1];

	x[1] = -y[0] * z[2] + y[2] * z[0];

	x[2] = y[0] * z[1] - y[1] * z[0];

	/* Recompute Y = Z cross X */

	y[0] = z[1] * x[2] - z[2] * x[1];

	y[1] = -z[0] * x[2] + z[2] * x[0];

	y[2] = z[0] * x[1] - z[1] * x[0];

	/* mpichler, 19950515 */

	/* cross product gives area of parallelogram, which is < 1.0 for

	* non-perpendicular unit-length vectors; so normalize x, y here

	*/

	mag = sqrt(x[0] * x[0] + x[1] * x[1] + x[2] * x[2]);

	if (mag) {

		x[0] /= mag;

		x[1] /= mag;

		x[2] /= mag;

	}
	mag = sqrt(y[0] * y[0] + y[1] * y[1] + y[2] * y[2]);

	if (mag) {

		y[0] /= mag;

		y[1] /= mag;

		y[2] /= mag;

	}

#define M(row,col)  m[col*4+row]

	M(0, 0) = x[0];

	M(0, 1) = x[1];

	M(0, 2) = x[2];

	M(0, 3) = 0.0;

	M(1, 0) = y[0];

	M(1, 1) = y[1];

	M(1, 2) = y[2];

	M(1, 3) = 0.0;

	M(2, 0) = z[0];

	M(2, 1) = z[1];

	M(2, 2) = z[2];

	M(2, 3) = 0.0;

	M(3, 0) = 0.0;

	M(3, 1) = 0.0;

	M(3, 2) = 0.0;

	M(3, 3) = 1.0;

#undef M

	glMultMatrixf(m);
	/* Translate Eye to Origin */
	glTranslatef(-eyex, -eyey, -eyez);
}

unsigned char *loadBMP(char *filename, BITMAPINFOHEADER *bmpInfo)
{
	FILE *file;
	BITMAPFILEHEADER bmpFile;
	unsigned char *bmpImage = NULL;
	unsigned char tmpRGB;

	file = fopen(filename,"rb");

	if (!file)
	{
		::MessageBox(NULL, L"Can't Find Bitmap", L"Error", MB_OK);
		return NULL;
	}

	fread(&bmpFile,sizeof(BITMAPFILEHEADER),1,file);

	if (bmpFile.bfType != 0x4D42)
	{
		::MessageBox(NULL, L"Incorrect texture type", L"Error", MB_OK);
		fclose(file);
		return NULL;
	}

	fread(bmpInfo,sizeof(BITMAPINFOHEADER),1,file);

	fseek(file,bmpFile.bfOffBits,SEEK_SET);

	bmpImage = new unsigned char[bmpInfo->biSizeImage];

	if (!bmpImage)
	{
		::MessageBox(NULL, L"Out of Memory", L"Error", MB_OK);
		delete[] bmpImage;
		fclose(file);
		return NULL;
	}

	fread(bmpImage,1,bmpInfo->biSizeImage,file);

	if (!bmpImage)
	{
		::MessageBox(NULL, L"Error reading bitmap", L"Error", MB_OK);
		fclose(file);
		return NULL;
	}

	for (unsigned int i = 0; i < bmpInfo->biSizeImage; i+=3)
	{
		tmpRGB = bmpImage[i];
		bmpImage[i] = bmpImage[i+2];
		bmpImage[i+2] = tmpRGB;
	}

	fclose(file);

	return bmpImage;
}

BOOL LoadTexture(char *filename, GLuint *id)
{    
	BITMAPINFOHEADER info;
	unsigned char *bitmap;

	bitmap = loadBMP(filename, &info);

	if (!bitmap)
		return false;

	glGenTextures(1, id);
	glBindTexture(GL_TEXTURE_2D, *id);
	glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
	glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
	glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, info.biWidth, info.biHeight, 0, GL_RGB, GL_UNSIGNED_BYTE, bitmap); 

	return TRUE;
}

▌苹果意欲淘汰跨平台图形技术 OpenGL 和 OpenCL
日前的 WWDC 大会上，为了推广自家的 Metal 图形技术，苹果宣布了一个不太好的消息：随着 MacOS 10.14 Mojave 的发布，后续版本中将停用 OpenGL 和 OpenCL 接口——很多开发者对此十分不满，特别是游戏开发者，这两种跨平台图形技术的停用将会大大提高移植游戏的难度，甚至有部分游戏开发商扬言要“放弃 macOS 平台”。

在 MacOS 10.14 的文档中，苹果表示使用 OpenGL 和 OpenCL 构建的应用还可以继续在 macOS 10.14 中运行（但是即使 macOS 支持 OpenGL ，其内置版本依然是 8 年前发布的 OpenGL 3.3 ，而不是去年发布的 4.6）。
不过苹果表示，这些“遗留技术”并不推荐使用。所以，所有使用 OpenGL 的游戏和应用建议转向 Metal ；同样，使用 OpenCL 进行计算任务的应用也建议采用 Metal 和 Metal Performance Shaders 。
很明显，苹果此举是想要大力推广 Metal 图形技术，来替换掉“古老”的 OpenGL 接口和 OpenCL 接口。
▌苹果力推 Metal 究竟意欲何为？
在讨论这个问题之前，我们先讨论 OpenGL、OpenCL 和 Metal 三个技术。
OpenGL 是一个关于图形 API 的详述定义，规定了很多函数和其参数返回型，以及要实现的行为和管线操作。其具体的实现由硬件厂商完成。目前，OpenGL 是行业领域中最为广泛接纳的 2D/3D 图形 API。在包含CAD、内容创作、能源、娱乐、游戏开发、制造业、制药业及虚拟现实等行业领域中，OpenGL 帮助程序员实现在 PC、工作站、超级计算机等硬件设备上的高性能、极具冲击力的高视觉表现力图形处理软件的开发。
OpenCL 是由苹果公司发起，业界众多著名厂商共同制作的面向异构系统通用目的并行编程的开放式、免费标准，也是一个统一的编程环境。便于软件开发人员为高性能计算服务器、桌面计算系统、手持设备编写高效轻便的代码，而且广泛适用于多 CPU、GPU、Cell 类型架构以及 DSP 等其他并行处理器，在游戏、娱乐、科研、医疗等各种领域都有广阔的发展前景。
目前，OpenGL 和 OpenCL 接口都是游戏行业普遍应用的跨平台图形技术，特别是前者，十分受游戏开发商的欢迎。对开发商来说，OpenGL 不仅能够做到多平台通用，而且极大降低了多平台游戏开发的成本。
而 Metal，则是一种低层次的渲染应用程序编程接口，它是苹果公司 2014 年 WWDC 上为游戏开发者推出的新的平台技术。Metal 提供了软件所需的最低层，能够为 3D 图像提高 10 倍的渲染性能，保证软件可以运行在不同的图形芯片上。目前，Metal 已支持了很多用户熟悉的游戏引擎及公司，比如《现代战争》、《狂野飙车》等等。
在 6 月 5 日的 WWDC 上，苹果推出了最新的 Metal 2 图形技术，并且鼓励所有开发者和开发商采用这个技术。但是这一技术的推广很可能是要以替换掉 OpenGL 接口和 OpenCL 接口为代价的。

但是，Metal 2 图形技术在多平台通用、成本方面明显都不如 OpenGL 有优势，那为什么苹果还要顶着被游戏开发厂商“抛弃”的风险力推呢？
事实上，对于苹果来说，OpenGL 和 OpenCL 图形技术的使用一直存在性能发挥不够好的问题，远不用充分利用 MacBook 等一系列电脑产品的硬件配置，但是 Metal 2 图形技术在这方面的性能提升却非常显著。
因此，苹果想要弃用 OpenCL 和 OpenGL 的意图十分明显。近几年，苹果一直在推动 Metal API 在 MacOS 和 iOS 上的应用，而 OpenGL Stack 多年来却一直没有更新，已严重落后于 Khronos Group 的 OpenGL 4.x 。由苹果公司开发且拥有商标权的 OpenCL 发展得也并非一帆风顺，随着 macOS 的弃用，现在已经很难看到 OpenCL 出现在桌面应用中了。

所以，虽然苹果目前还没有明确表示会删除实际的 OpenCL 和 OpenGL 驱动程序支持，但时间估计也不会太久了。
事实上，在图形技术领域，OpenGL、OpenCL 和 Metal 三者之间的关系一直是极其微妙的。随着 Vulkan（和 OpenGL 一样，同样由 Khronos 集团开发）、CUDA（NVIDIA 推出的通用并行计算架构）、DirectX（微软推出的多媒体编程接口）等市场角色的不断加入，正如@知乎用户（https://www.zhihu.com/question/279905495）所述，它们之间就无可避免地会有不断取代、消亡和进化的关系发生。

 
OpenGL 已停止更新，未来将由 Vulkan 接替。Vulkan 在 2015 年 GDC 上推出之初，就是旨在替代 OpenGL，以提高图形性能。
 
OpenCL 的未来也已经由 Khronos 作出决定，合并入 Vulkan。
 
macOS 官方支持的 OpenGL 最新版本只到4.1，在此之前很长一段时间停留在3.x。抛弃 OpenGL 早在预料之中。苹果的想法是依靠庞大的 iOS 设备和用户数反过来吸引 macOS 开发者（能不能成真另当别论）。另一个利好是抛弃 OpenGL 陈旧的历史负担，减少系统维护开发成本。
 
OpenCL 有点意思，因为它的原始创始者是苹果自己。对比 CUDA，OpenCL 开放跨平台的优势付出的代价是没有 NVIDIA 这类鼎力支持的厂商，开发调试过程极其复杂，生态圈也被 CUDA 远远抛开。苹果很长一段时间内倒是大力支持，还为此在 Mac 产品线上全线配备 AMD 图形卡，抛弃 NVIDIA（这是一个原因，最主要的是选择 AMD 成本更低，获得的主导权更大）。到 OpenCL 2.2发布时，Khronos决定未来将其与 Vulkan 融合。未来更新版本的、单独的 OpenCL 也将不复存在。
 
为什么不支持 Vulkan？自己一人说了算当然比一群人开会来的爽啊，问题是能不能做到像微软和 NVIDIA 那样自己爽大家也爽？难。
 
未来的标准，CUDA、DirectX、DirectCompute 没有主导权，Vulkan 不能自己说了算，Metal 当然被确立为自家官方未来的标准。
 
借由摒弃（OpenGL、CL）这几项标准这事，可以预测一下苹果未来工作站级别电脑会是什么情况——只能用于 macOS/iOS/tvOS 平台的 API，只支持此标准的操作系统，持观望和否定态度的广大开发者，大概率不支持此标准的 NVIDIA 等硬件厂商——没准下一代 Mac Pro 遭到的恶评比本代更多：圆柱体 Mac Pro 至少兼容性不是大问题。

所以，全平台兼容性终究是开发者们无法避开的问题了。
▌广大开发者，特别是游戏厂商该如何抉择？
那么苹果 Metal 2 图形技术的推出，会让广大开发者主动适配吗？面对跨平台移植和成本这两大因素，不同的厂商有不同的考量，以游戏厂商为例。
目前，其实已经有不少研发资源丰富的大厂商推出了基于 Metal 的 Mac 版游戏，包括耳熟能详的魔兽世界、杀出重围、见证者和尘埃拉力赛等。但这对于中小型厂商而言仍然是十分纠结的难题。
对于中小型游戏开发商来说，OpenGL 图形技术意味着多平台游戏开发成本的降低，而如果在 macOS 平台上单独采用 Metal 2 图形技术，则意味着开发成本会大幅上涨。“Mac 的市场份额实在太低了”、“维护 Metal 环境的成本明显高于 Mac 市场的潜力”、“把游戏转到 64 位并不困难（macOS 未来将不再支持 32 位应用），但是转到 Metal 是不可能的”......种种言论之下，厂商们会如何选择几乎一目了然了。
Vlambeer 公司的设计师 Rami 即表示：“Metal 和 DirectX 的问题非常相似，它们都不是跨平台的，我们不得不增加支持的图像引擎，某个平台独享的图形 API 令人感到痛苦。”
但是得益于 Windows 平台庞大的游戏用户数量，大部分游戏开发商都不会放弃 Windows 平台。然而 macOS 上的游戏用户数量远不如 Windows 等其他平台，所以在游戏开发产出比根本不合算的情况下，游戏开发者会放弃 macOS 平台也是不得已而为之的选择了。
▌写在最后
当年苹果与 Adobe 之间对于 iPhone 是否支持 Flash 的争论似乎已经过去很久了。当时，大家还对苹果的这一举动各执一词：有人认为Flash 是落后的技术应该淘汰，也有人认为苹果放弃高性能的Flash 是极为不明智的。
而现在，苹果又要移除 OpenGL 支持了。
无论开发者的态度是什么，是支持抑或是反对，苹果在其软硬件大一统的道路上都越走越远了，此次“舍弃”OpenGL 也只是其中的一小步而已。
而全平台兼容的难题，只能留给开发者们慢慢解决了。