graphics模块做什么的

电脑 2023-05-11 00:22:03 0

淘宝搜：【天降红包222】领超级红包，京东搜：【天降红包222】
淘宝互助，淘宝双11微信互助群关注公众号【淘姐妹】

一、GPU Graphics的一些开源代码

N【【微信】】：

https://github.com/NVIDIA/【【微信】】les

AMDGPU:

https://github.com/GPUOpen-Drivers

https://gitlab.freedesktop.org/agd5f

https://lore.kernel.org/amd-gfx/

https://lists.freedesktop.org/mailman/listinfo/amd-gfx

https://github.com/GPUOpen-LibrariesAndSDKs

libdrm / Mesa 3D

https://dri.freedesktop.org/libdrm/

https://archive.【【微信】】.org/

https://docs.【【微信】】.org/index.html

To be best：

https://blog.csdn.net/linyingzhan/article/details/8265125

二、Mesa简介

除了游戏等3D应用程序外，现代显示服务(Xorg的Glamor和Wayland的Weston)也使用OpenGL和EGL；因此所有的图形通常都要用到Mesa。

Mesa也称为Mesa3D，是OpenGL、Vulkan和其他图形API规范的开源软件实现，Mesa将这些规范转换为特定于供应商的图形硬件驱动程序。所以可以将mesa看成二部分：

一套兼容OpenGL等标准的实现

这部分是为应用程序提供标准的OpenGL等API。

DRI驱动(通常被称为3D驱动)

其中包括Pipeline的软件实现，也就是说即使GPU没有任何3D计算能力，那么mesa也完全可以使用CPU来完成3D渲染功能；另外3D驱动还负责将3D渲染命令翻译成GPU可以理解并且能执行的指令；不同的GPU有各自的"指令集"，因此mesa中不同的GPU都有各自的3D驱动。

其最重要的用户是二个图形驱动程序，它们主要由Intel和AMD为各自的硬件开发和资助(AMD在不推荐的AMD Catalyst上推广其Mesa驱动程序Radeon和RadeonSI, Intel只支持Mesa驱动程序)。专有的图形驱动程序(如N【【微信】】驱动程序和Catalyst)取代了所有Mesa，提供了自己的图形API实现，开发名为Nouveau的【【微信】】驱动程序的开源工作主要由社区开发。

DRI的三代变化

DRI的实现有三代，即DRI1、DRI2、DRI3。

DRI1

首先要说，DRI1已经不在考虑使用了，这里说一下它的原理：

DRI1由于当时图形卡内存大小，只有一个屏幕【【微信】】+back buffer由所有DRI clients和X server使用，【【微信】】和back buffer就像现在显示系统的双缓冲一样，所有要做渲染操作的实体都直接渲染到back buffer，然后执行swap就更新画面，front变back，back变front。另外所有渲染实体在开始渲染时，都会独占DRM设备，就像互斥锁保护的内存资源，其他的渲染实体就要等，并且渲染实体在释放设备时，所有之前上传的数据(如纹理等)都会丢失，总之，性能不行。

DRL2

DRI2和DRI3现在都在使用，但是DRI3性能更好一些，说一下DRI2原理：

后来的DRI2依赖KMS/GEM，每个DRI应用使用单独的渲染缓冲区，性能上有所改善。

DRI2是进入compositor时代的设计，buffer开始变成离屏buffer，并且离屏buffer可以做直接渲染，DRM也经过了一次大更新；每个DRI client都有自己的back buffer(附带着深度和模版缓冲区)，DRI client在back buffer做完渲染后的swap也不再是直接显示出去，而是变成提交给compositor作为一个compose源，最终的屏幕内容是compositor根据各个源的叠加、透明、边界裁剪得到，并swap到真的【【微信】】。

为了管理各个DRI client都有自己的back buffer这个事儿，DRM加了新功能，内存管理TTM，但是后来又重写成GEM。但是有了这个内存管理之后，DRI2 client渲染时不再锁定整个DRM设备，并且在暂停渲染时也不必释放所有显存资源。

DRL3

最新的DRI3依赖DMA_BUF，改进了缓冲区对象的传递和共享方式(从GEM名称改成了PRIME DMA_BUF)，性能和安全都有所增强。

DRI3 client申请自己的渲染buffer，而不是去调用X server来做申请(这是DRI2 支持的方法)，这带来了易于改变窗口大小、重复利用之前的buffer等特性(compositor刷帧只需要更新部分缓存内容即可)；DRI3放弃了不安全的基于GEM共享buffer的机制，转而使用DMA的fd来传递，并且DRI3PixmapFromBuffer和DRI3BufferFromPixmap可以完成X ser【【微信】】与DMA buffer的转换，同样一块内存，在DRI client和X server之间传递。

三、2D渲染(结合X窗口系统，以Intel GPU为例)

可以形象地将2D渲染比喻为绘画，其中有二个关键地方，一个是画布，另一个是画笔。X Server启动后，将加载GPU的2D驱动，2D驱动将请求内核中的DRM创建帧缓冲，这个帧缓存就相当于画布。然后X Server按照绘图需要，从画笔盒子中挑选合适的画笔(CPU or GPU)进行绘画(比如绘制矩形，绘制圆弧，绘制实心多边形等)。

当然最初的这些绘制操作均是由CPU负责完成，也就是我们常说的软件渲染，X中的fb层就是软件渲染的实现(xorg-server/fb/fbgc.c)，随着GPU的发展，这部分工作就慢慢开始由GPU来做了。

X的渲染架构: XAA/EXA/UXA/SNA/Glamor

X的渲染架构也随着GPU的发展而不断演进。在XFree86 3.3的时候，X的开发者设计了XAA(XFree86 acceleration Architecture)架构；在X.org Server 6.9版本，开发者用改进的EXA取代了XAA；当DRM中使用了GEM后，Intel的GPU驱动开发者门重新实现了EXA，并命名为UXA(Unified Acceleration Architecture)；随着Intel推出Sandy Bridge及i【【微信】】芯片组，Intel又开发了SNA(SandyBridge's New Acceleration)。这里需要注意Nvidia和AMD显卡只有EAX。

在Intel的2D GPU驱动里可以发现在UXA架构下，X的画笔盒子定义(xf86-【【微信】】/uxa/uxa-accel.c)如下。在uxa_ops里有一部分画笔来自GPU，有一部分呢来自CPU。

最后，X Server采用了类似Wayland的方法，所有的图形加速全部使用3D驱动取代，将2D驱动精简成一个包装层，这就是Glamor加速方法

X的2D渲染过程

以UXA架构为例，对于每一个绘图操作：

如果GPU支持这个绘制操作，UXA首先将绘制的命令翻译成GPU可以识别的指令，并将这个指令、绘制所需要的相关数据，以及保存像素阵列的BO在显存地址空间中的地址，一同保存在用户空间的批量缓冲(Batch Buffer)，然后通过DRM将用户空间的批量缓冲复制到内核为批量缓冲创建的BO，之后通知GPU从BO中读取指令和数据进行绘制。实际上，DRM按照Intel GPU的要求在批量处理缓冲和GPU之间还组织了一个环形缓冲区(RingBuffer)，但是我们暂时忽略它，这对于理解2D渲染过程没有任何影响。

如果GPU不支持这个操作，那么UXA将代表帧缓冲的BO映射到X Server的用户空间，X Server借助fb层中的实现，使用CPU进行绘制。

创建前缓冲

在X环境下，在不开启复合(Composite)扩展的情况下，所有的程序共享一个前缓冲。对于2D程序，所有的绘制动作生成的图像的像素阵列最终都输出到这个前缓冲上，窗口只不过是前缓冲中的一块区域而已。这里需要注意一旦开启了复合扩展，那么每个窗口都将被分配一个离屏(offscreen)的缓冲，类似于OpenGL环境中的后缓冲；应用将生成的像素阵列输出到这个离屏的缓冲中，在绘制完后，X Server将向复合管理器(Composite Manager)发送Damage事件，复合管理器收到这个事件后，将离屏缓冲区的内容合成到前缓冲。这里的2D渲染流程和接下来的3D渲染流程都暂时不涉及复合扩展。

在X中，Window和Pixmap是2个绘制发生的地方，Window代表屏幕上的窗口，Pixmap代表离屏的一个存储区域。所以自然而然地，X使用数据结构Pixmap来表示前缓冲。因为这个前缓冲对应整个屏幕，而且不属于某一个应用，因为开发者也将代表前缓冲地这个Pixmap称为Screen Pixmap。显然这个Screen Pixmap也是显示器（Screen）的资源。

1）创建前缓冲的BO：前缓冲的BO是在X Server启动过程中，2D驱动程序初始化设备时向DRM模块申请创建的。

2）将前缓冲保存到屏幕对象：创建了前缓冲的BO后，X Server就会为前缓冲创建Pixmap对象(即Screen Pixmap)，然后将前缓冲保存到屏幕对象。

3）窗口与前缓冲的绑定：前缓冲已经建立起来了，但是显然需要将窗口与前缓冲关联起来，否则在窗口上的绘制并不能体现到屏幕上。我们在编写具有图形界面的程序时，在绘制之前首先需要创建绘制所在的窗口。恰恰是在创建窗口时，窗口与前缓冲绑定了。X中创建窗口的函数(xorg-server/【【微信】】.c)如下：

fbCreateWindow调用函数fbGetScreenPixmap获取Screen Pixmap，并将窗口对象与Screen Pixmap绑定。

显然，所谓的创建窗口事实上就是将窗口与前缓冲关联起来，以后凡是发生在窗口上的绘制，都将直接绘制到前缓冲中。

GPU渲染和CPU渲染

GPU又称硬件渲染/硬件加速，从软件层面所做工作就是将数学模型按照GPU的规定，翻译为GPU可以识别的指令和数据，传给GPU，生成像素阵列等图像密集型计算则由GPU完成。在Intel GPU的2D驱动中定义了使用一种所谓的批量缓冲来保存这些命令和数据，将驱动准备的命令和数据放到这个缓冲，然后批量让GPU来读取。GPU内部处理分为多个微核，处理不同的命令，处理2D指令的微核称为BLT引擎。

CPU渲染又称为软件渲染，BO是由DRM模块在内核空间分配的，因此运行在用户空间的X(2D驱动)想要访问这个内存，必须首先要将其映射到用户空间，这是由uxa_prepare_access来完成的。然后X使用CPU在映射到用户空间的BO上进行绘制。

所谓的软件渲染和硬件加速，本质都是生成图像的像素阵列，只不过一个是由CPU来计算，另一个是由GPU来计算。当然对于硬件加速，CPU要充当一个翻译，将数学模型按照GPU的要求翻译为其可以识别的指令和数据。

四、3D渲染(基于X窗口系统和Mesa，以Intel GPU为例)

直接渲染

X-Window所提供的XLib只提供2D渲染功能，3D功能是由Mesa提供的。现在的Mesa实现了DRI(Direct Rendering Infrastructure)功能，不通过【【微信】】，直接与内核/硬件进行交互。

OpenGL应用程序和窗口系统的结合

GLX扩展和DRI扩展

Pipeline最后将生成好的像素阵列输出到帧缓冲，但是这这还不够，因为最后的输出需要显示到屏幕上。而屏幕的显示是由具体的窗口系统控制的，因此帧缓冲还需要与具体的窗口系统相结合。但是X的核心协议并不包含OpenGL等相关的协议，因此开发者门开发了GL的扩展GLX(GL Extension)。为了支持DRI开发者又开发了DRI扩展。显然GLX以及DRI扩展在X和Mesa中均需要实现。

运行在X窗口系统上的OpenGL应用程序的渲染过程(可以分为三个阶段，如上图所示)

1）应用创建OpenGL的上下文，包括向X Server申请创建帧缓冲。OpenGL应用程序为什么不自己直接向内核的DRM模块请求创建帧缓冲呢？从技术上讲，OpenGL应用自己请求DRM创建帧缓存没有任何问题，但是为了将帧缓冲与具体的窗口系统绑定，OpenGL应用只能委屈一些，放低姿态请求X Server为指定窗口创建帧缓冲对应的BO，帧缓冲中包含多个缓冲，当然是创建多个BO了，X Server收到应用程序的请求后，为各个缓冲创建BO(在X中帧缓冲由【【微信】】创建，然后创建完后，将BO的名字等相关信息告知OpenGL应用，应用收到BO信息后便可以更新GPU的状态，比如告诉GPU画板在哪里)。这样X Server就掌握了应用的帧缓存的一手资料，在需要时将帧缓冲显示到屏幕。帧缓冲是OpenGL应用的"画板"，因此创建完成后，X Server需要将帧缓冲的BO信息返回给OpenGL应用。

2）OpenGL应用创建数学模型，并通过OpenGL的API将数学模型的数据写入顶点缓冲区【【微信】】；更新GPU的状态，若指定后缓冲，用来存储Pipeline输出的像素阵列；然后启动Pipeline进行渲染。

3）渲染完成后，OpenGL应用向X Server发出swap请求。这里的swap有二种方式，一种是copy，即将后缓冲的内容复制到前缓冲，这里是由GPU的BLT引擎负责的。但是这种copy的方式效率相对较低，所以开发者又设计了一种称为页反转(page flip)的模式，在这种模式下不需要copy动作，而是通过GPU的显示引擎控制显示控制器扫描哪个帧缓冲，这个被扫描的缓冲此时扮演前缓冲，而另外一个不被扫描的帧缓冲则作为应用的"画板"，也就是所说的后缓冲。

esxi6.7 虚拟交换机设置 EXSi 管理虚拟机esxi6.5安装教程,esxi6.5,esxi6.0,esxi6.7安装教程

ESXi专为运行虚拟机、最大限度降低配置要求和简化部署而设计。只需几分钟时间，客户便可完成从安装到运行虚拟机的全过程，特别是在下载并安装预配置虚拟设备的时候。有些时候需要整合利用一些显卡硬件资源，并且想便于讲一个机器给不同的人使用（不同需求），这个时候EXSI虚拟机会很方便达到我们的目的。

硬件列表