GPU随想——OpenGL函数加载流程

淩亂°似流年 2023-02-22 10:56 8阅读 0赞

导航： GLX基本流程 OpenGL函数的分发 到底什么是context？

\-----------------------------读前须知-------------------------

历代dri：dri1、dri2、dri3 根据wikipedia词条等整理。另，对X窗口系统方面有兴趣的读者可以阅览Keith Packard（80年代就开始参与设计并开发X窗口系统了，无需赘言……btw，另一位厉害的人物是Kristian Høgsberg）的博客，wikipedia中的不少内容也借鉴与此。

dri1： 在这最早的dri架构中，由于彼时的显存大小有限，因此其中只存在一份“前台/后台/深度/模板缓冲区”实例。所有的应用程序都会在这唯一的实例中，小心维护自己的缓冲区子集。这种工作模式完全是排他的（exclusive），在某一应用开始渲染前，必须锁定硬件，将其他应用锁在外面，哪怕某些有些应用的操作与之毫无冲突也要排除在外。与X server同步的时候，要利用信号与共享内存缓冲区（此缓冲区也被称为SAREA）。（试想你清早起床想去撇大条，而附近的厕所里只有一个坑儿，你排除万难，抢到优先权，势必先回身锁好门，防止有人强行窃取革命胜利的果实，神圣的利益不容侵犯！任门外的街坊跳脚骂街也无所畏惧！！就算是有人要去小便池小便也管不得了！！！） dri1效率的低效是一目了然的，所以这个模型现在被彻底废弃了。

![format_png][]

dri1模式下，众应用抢占渲染权

dri2： 到了由Kristian Høgsberg实现的dri2，情况发生了大转变。 每个应用都可以分配到自己的缓冲区，所以无需加锁即可进行渲染，因而也就不必为此而争得鼻青脸肿了。 彼时开始流行composite窗口管理器（或称compositor），也就是为每个不同的应用程序赋予一个窗口的“离屏缓冲区（off-screen buffer）”，令其将各自的窗口内容绘制到此缓冲区中，再根据这些窗口的前后顺序等信息，通过compositor，将它们“复合”（PS？）成一张“图片”，最后送至显存，绘制并程序到显示器中。在X窗口系统中，composite功能是由扩展的形式来实现的。。 对此，dri2的策略是：当dri2客户端（也就是用户的应用程序）将数据渲染至前台缓冲区时，其实绘制到的是一个“伪前台缓冲区（`fake front buffer`）”。而实际的“前台缓冲区”则由X窗口系统管理，在特定的“同步点（synchronization points）”上，再把“伪前台缓冲区”中的数据自动复制到“真·前台缓冲区”中。 另外，如果当server端实现有DRI2SwapBuffers功能时，也可以采用此方法来交换前后台缓冲区（X server当前有实现）。 另外，还可以利用DRI2CopyRegion函数，在“伪·前台缓冲区”与“真·前台缓冲区”之间复制数据。但是，此方法较之DRI2SwapBuffers方法更难以管理；再者，由于使用DRI2CopyRegion时并没有同步的机制，因此可能会造成画面撕裂（tearing）的现象。（比如，下一帧画面还没有复制完成，就将帧缓冲区中的数据刷新到屏幕上了……） 关于dri2的更多细节请参见dri2proto项目。

![format_png 1][]

dri2模式下，各回各家，完美

dri3：

Wayland： 前面提到，当前显示图像的常见方式是将不同窗口的内容composite成一张图片，最后显示在屏幕上。X中，compositor是以扩展的形式出现，而且由于历史包袱等原因，其处理流程复杂、效率低下。它的工作简图如下（可将evdev简单地理解为用户的输入，这会影响窗口间的关系，如前后关系，这样就将触发CS的一系列互动，从而使显示内容发生变化）：

![format_png 2][]

X系统显示基本流程（from Wayland官网wayland.freedesktop.org）

这时，dri2的实现者Kristian Høgsberg牵头，新构想了一种显示协议，即Wayland，其compositor参考实现为Weston。在此协议中，Wayland Compositor本身就是服务器，即Wayland Server。另外，Wayland去掉了X背负的历史包袱，精简了客户端与服务器端的交互，并将两端要执行的任务进行更加合理的分配，使显示效率更高，开发起来也更为容易。再者，Wayland还与X保持了一定的兼容方式。根据这些优点不难发现，Wayland应该是Linux下显示方面的发展方向（虽然实际上从2008年开始发展到现在还是磕磕绊绊……）。

![format_png 3][]

Wayland系统显示基本流程（from Wayland官网wayland.freedesktop.org）

到底什么是context？

这个词翻译有很多，如上下文、语境、环境等等。我认为把它看作是“资源集合”更好。context其实就是程序要用的资源，执行一个函数可能要用到此时的状态（寄存器、内存等）、前面计算出来的某些数据等等。我们把自己想象成一个木匠，做木工需要有自己的家伙什，锛凿斧锯。而木匠在出外工作（执行函数）时，就要随身带上工具包装好自己趁手的工具（执行函数要用的各种资源打包成“context”），在打磨木材时便打开工具包拿出工具（引用“context”中的各种资源）开始工作。 而OpenGL亦有它自己的context，即OpenGL context。众所周知，OpenGL采用的模型为状态机（所谓状态机可以说是每个函数执行步骤间的影响与联系），因此，OpenGL context里的关键内容之一就是执行过程中的状态。glx即创建OpenGL context的工具。

\-----------------------------GLX基本流程-------------------------

GLX是建立X之上的拓展，因此在使用GLX函数之前要建立与X server的连接，并创建好X窗口（详细参见上一篇《GPU随想——OpenGL辅助工具》）。所以，这里分析的前提是满足上述条件。另，此处讨论的是mesa3d中的glx实现。

mesa3d中glx的实现当前位于src/glx文件夹下（mesa3d与其他开源项目差不多，经常更新，所以也经常会有所变动，这里只是针对当前版本进行讨论。其实这种讨论更应该抽离主要流程，而非实际的函数名、文件地址等，但这样讨论起来确实比较直观些，希望再若干年后不会反而成为某种羁绊。简而言之，关键在于处理流程与其中的思想）。从名字可以看出，glxcmds.c为glx调用命令函数集，其实现又依赖于其他文件，如低层根据dri1/dri2/dri3等版本又分为dri2.c/dri2.h等文件。

在执行GLX函数之前，会检测是否对GLX进行初始化，GLX的初始化依赖于当前程序中与X server所建立连接的Display（从GLX大多函数中必有Display参数这一点亦可以看出）。在GLX的实现代码中，我们首先要确定程序中定义了三个宏： GLX\_DIRECT\_RENDERING（采用GLX直接渲染模式，即绘制任务由GLX client客户端自行绘制），GLX\_USE\_DRM（利用DRI框架进行GPU硬件加速），HAVE\_DRI3（系统中支持dri3）。

既然GLX是X的一种扩展，那就要围绕X中的关键结构体增加扩展信息。如X中Display（也就是连接的X server信息），GLX对其扩展的信息存于glx\_display结构体中。

初始GLX的过程，其实就是填写glx\_display等结构体的过程，glx\_display中保存着与此前Display有关的GLX拓展的私有信息。此结构体关键成员如下：

struct glx\_display \{ // 指向此glx\_display描述的Display Display \*dpy; // X对于所有拓展都指定了对应的编码，这里用于存储GLX的拓展协议编码 XExtCodes \*codes; // 指向下一个glx\_display，用于构建glx\_display类型链表 struct glx\_display \*next; // glx拓展的major opcode编号。X的拓展有各自的major opcode，范围为128-255，根据X server的具 // 体实现版本动态分配 int majorOpcode; // X服务器端支持的GLX拓展版本号 const char \*serverGLXversion; // 此Display中所有显示设备screen的对应glx信息 struct glx\_screen \*\*screens; // 只有开启GLX\_DIRECT\_RENDERING才会使用以下几项 // driswDisplay即dri sw（software rasterizer）display，用于创建dri软光栅器的glx\_screen和销毁GLX // 扩展数据 // driDisplay， 用于创建dri1的glx\_screen和销毁dri1的GLX扩展数据 // driDisplay2，用于创建dri2的glx\_screen和销毁dri2的GLX扩展数据 // driDisplay3，用于创建dri3的glx\_screen和销毁dri3的GLX扩展数据 \_\_GLXDRIdisplay \*driswDisplay; \_\_GLXDRIdisplay \*driDisplay; \_\_GLXDRIdisplay \*dri2Display; \_\_GLXDRIdisplay \*dri3Display; \};

根据

typedef struct \_\_GLXDRIdisplayRec \_\_GLXDRIdisplay;

struct \_\_GLXDRIdisplayRec \{ void (\*destroyDisplay) (\_\_GLXDRIdisplay \* display); struct glx\_screen \*(\*createScreen)(int screen, struct glx\_display \* priv); \};

可知，\_\_GLXDRIdisplay结构体中其实保存的是对应dri版本的destroyDisplay()与createScreen()函数实现。destroyDisplay()用于销毁对应Display的dri拓展（其实就是销毁其对应结构体中的数据）。createScreen()则用来为对应的screen显示设备进行设置，并创建对应的glx扩展数据。（根据前面文章可知，Display即客户端与服务端的连接，而screen则是对应Display中的显示设备，Display中的显示设备也许并非唯一，所以需要指定。其实也能看出这是对具体硬件的一层抽象……）

GLX针对screen的扩展数据用结构体glx\_screen来表示，列出主要成员：

struct glx\_screen \{ // 此glx\_screen所附属的glx\_display struct glx\_display \*display; // 此显示设备的显示模式，如帧缓冲区有关配置等 struct glx\_config \*visuals, \*configs; \}

struct glx\_config \{ // 指向下一个显示模式的指针 struct glx\_config \* next; // 仅列出部分关键属性，知此结构用意即可 GLboolean rgbMode; GLboolean floatMode; GLboolean colorIndexMode; GLuint doubleBufferMode; GLuint stereoMode; GLint redBits, greenBits, blueBits, alphaBits; /\* bits per comp \*/ GLuint redMask, greenMask, blueMask, alphaMask; GLint rgbBits; /\* total bits for rgb \*/ GLint indexBits; /\* total bits for colorindex \*/ GLint accumRedBits, accumGreenBits, accumBlueBits, accumAlphaBits; GLint depthBits; GLint stencilBits; …… \} GLX中维系着一个glx\_display类型的链表： static struct glx\_display \*glx\_displays;

每当调用GLX函数时，都会首先遍历此链表，看是否存在与调用的GLX函数参数相同的Display（例如，glXDestroyContext(Display \* dpy, GLXContext ctx)中的第一个参数Display \* dpy），如果存在则采用此Display所在的glx\_display结构体实现GLX函数的执行逻辑；否则以GLX参数中传来的Display创建对应的glx\_display，将创建的glx\_display加入这个链表中，再实现GLX函数的执行逻辑。这便是GLX初始化的全部工作了。

\-----------------------------\_\_glXInitialize()基本流程-------------------------

\_\_glXInitialize()初始化函数的主要流程（由于OpenGL可以支持多线程，因此会涉及多线程处理机制，后面我们为了简化描述GLX与OpenGL的逻辑流程，去掉了多线程部分，但在关键处仍会提及。错误处理机制亦是如此，能省则省。另外，为了直观可能会用到伪代码等描述方式）：

struct glx\_display \*dpyPriv; for (dpyPriv = glx\_displays; dpyPriv; dpyPriv = dpyPriv->next) \{ // 如存在与GLX函数传来的Display相同的glx\_display，则借此实现GLX函数执行逻辑 // 否则根据此Display创建对应的glx\_display，并加入到glx\_displays之中，再将其返回实现GLX函数 if (dpyPriv->dpy == dpy) \{ return dpyPriv; \} \} // glx\_displays中不存在对应的glx\_display，那我们就来为之对应地创建一个 dpyPriv = calloc(1, sizeof \*dpyPriv); // 利用GLX函数参数传入的Display \*dpy来初始化此对应X server连接上的GLX扩展 dpyPriv->codes = XInitExtension(dpy, "GLX");

dpyPriv->dpy = dpy; dpyPriv->majorOpcode = dpyPriv->codes->major\_opcode;

Linux中有几种环境变量会影响mesa dri驱动的调用，如LIBGL\_ALWAYS\_INDIRECT（设置为1、true或yes则采用dri indirect间接渲染）、LIBGL\_ALWAYS\_SOFTWARE（设置为1、true或yes则全程采用CPU软光栅器进行渲染）、LIBGL\_DRI3\_DISABLE（设置为1、true或yes则禁用dri3渲染）。

而我们则假设并不在环境变量中设置这三种变量，也就是默认皆为0。

依次为每个dri版本创建对应的\_\_GLXDRIdisplay：

dpyPriv->dri3Display = dri3\_create\_display(dpy); dpyPriv->dri2Display = dri2CreateDisplay(dpy); dpyPriv->driDisplay = driCreateDisplay(dpy); dpyPriv->driswDisplay = driswCreateDisplay(dpy);

xxooCreateDisplay除了创建\_\_GLXDRIdisplay以外，还负责为对应的dri拓展填写其他数据信息，以及挂载其他对应的低层调用函数。以下针对dri2CreateDisplay进行讨论。

\-----------------------------dri2CreateDisplay基本流程-------------------------

dri2CreateDisplay的实际工作其实就是填写dri2\_display结构体，顾名思义，此结构体描述的即display对应的dri2扩展信息。

dri2\_display结构体中的关键成员如下：

struct dri2\_display \{ \_\_GLXDRIdisplay base; // dri2也分细分具体版本，早期版本的X server不支持后面加入的一些特性，这里我们不多加讨论 // 假设当前实现的dri2即为最高版本1.4 int driMajor; int driMinor; // dri2中的扩展函数 const \_\_DRIextension \*loader\_extensions\[5\]; \} struct dri2\_display \*pdp; // 为dri2\_display结构体开辟内存空间 pdp = malloc(sizeof \*pdp);

// 查询当前display支持的dri2具体版本，这一步需要与X server进行交互 DRI2QueryVersion(dpy, &pdp->driMajor, &pdp->driMinor); // 挂载dri2对应\_\_GLXDRIdisplay中的函数 pdp->base.destroyDisplay = dri2DestroyDisplay; pdp->base.createScreen = dri2CreateScreen; // 告知dri2扩展函数的实现版本 i = 0; pdp->loader\_extensions\[i++\] = &dri2LoaderExtension.base; pdp->loader\_extensions\[i++\] = &dri2UseInvalidate.base; pdp->loader\_extensions\[i++\] = &driBackgroundCallable.base; pdp->loader\_extensions\[i++\] = NULL; 其中， static const \_\_DRIdri2LoaderExtension dri2LoaderExtension = \{ .base = \{ \_\_DRI\_DRI2\_LOADER, 3 \},

.getBuffers = dri2GetBuffers, .flushFrontBuffer = dri2FlushFrontBuffer, .getBuffersWithFormat = dri2GetBuffersWithFormat, \}; static const \_\_DRIuseInvalidateExtension dri2UseInvalidate = \{ .base = \{ \_\_DRI\_USE\_INVALIDATE, 1 \} \}; static const \_\_DRIbackgroundCallableExtension driBackgroundCallable = \{ .base = \{ \_\_DRI\_BACKGROUND\_CALLABLE, 2 \},

.setBackgroundContext = driSetBackgroundContext, .isThreadSafe = driIsThreadSafe, \}; 上述3种结构体中的成员分两部分，.base中2项的为当前结构中的拓展名及其实现版本；后面则挂载具体的实现函数。 最后， return &pdp->base; dri2CreateDisplay函数返回设置好的\_\_GLXDRIdisplay结构体，回传给dpyPriv->dri2Display，即赋予其实际的dri2版destroyDisplay()与createScreen()执行函数。

\-----------------------------dri2CreateDisplay基本流程再见-------------------------

接下来调用AllocAndFetchScreenConfigs(dpy, dpyPriv)函数，此函数为glx函数参数Display \*dpy中管控的显示设备screen分配配置内存空间，并为之填写实际配置数据。

\-----------------------------AllocAndFetchScreenConfigs基本流程------------------------- // 此Display中有多少显示设备? screens = ScreenCount(dpy); // 为这些设备的配置信息分配空间 priv->screens = malloc(screens \* sizeof \*priv->screens); // 此Display支持的GLX版本号？ priv->serverGLXversion = \_\_glXQueryServerString(dpy, priv->majorOpcode, 0, GLX\_VERSION); for (i = 0; i < screens; i++, psc++) \{ psc = NULL; // 这里采用前面xoxoCreateDisplay设置好的createScreen()函数配置显示设备并创建对应的glx扩展数 // 据 if (priv->dri3Display) psc = (\*priv->dri3Display->createScreen) (i, priv); if (psc == NULL && priv->dri2Display) psc = (\*priv->dri2Display->createScreen) (i, priv); if (psc == NULL && priv->driDisplay) psc = (\*priv->driDisplay->createScreen) (i, priv); // 再失败就用软光栅器进行绘制 if (psc == NULL && priv->driswDisplay) psc = (\*priv->driswDisplay->createScreen) (i, priv); // 还不行就只好交给X server进行绘制 if (psc == NULL) psc = indirect\_create\_screen(i, priv); // 保存每个显示设备的对应配置数据 priv->screens\[i\] = psc; \} SyncHandle(); return GL\_TRUE; -----------------------------AllocAndFetchScreenConfigs基本流程再见------------------------- // 其实就是根据上述设置流程配置显示给服务器端的客户端扩展信息（如GLX等等） // （不过经粗看之后，这个函数似乎并没有起什么作用） \_\_glX\_send\_client\_info(dpyPriv); // 将我们本次创建的struct glx\_display \*dpyPriv;加入全局glx\_displays链中（略过多线程处理流程） dpyPriv->next = glx\_displays; // 给需要此display拓展结构体的glx函数实现后续流程 return dpyPriv;

\-----------------------------\_\_glXInitialize()基本流程再见-------------------------

最后，我们再讨论\*priv->dri2Display->createScreen，根据上文可知，也就是dri2CreateScreen函数。

\-----------------------------dri2CreateScreen基本流程-------------------------

首先，dri2CreateScreen函数参数有二： int screen; // 当前正在设置的显示设备编号 struct glx\_display \* priv; // 当前创建的Display glx扩展结构体

struct dri2\_screen \*psc; psc = calloc(1, sizeof \*psc); // 分配dri2\_screen空间，此为dri2对显示设备的扩展结构体

psc->fd = -1;

// 与X server交互，获取对应显示设备的信息，并将其填写至相应的glx扩展结构体中 // 要填写的关键glx扩展结构体是struct glx\_config，即显示设备的显示模式 glx\_screen\_init(&psc->base, screen, priv);

// 返回与当前显示设备screen关联的窗口所对应的驱动名driverName与设备名deviceName // 即从X server端返回的驱动与设备信息 DRI2Connect(priv->dpy, RootWindow(priv->dpy, screen), &driverName, &deviceName);

// 打开DRM设备（DRM device，针对DRM子系统，将GPU抽象而映射出来的文件， // 地址通常为/dev/dri/cardX，X是系统中GPU的编号） psc->fd = loader\_open\_device(deviceName);

// dri2的安全验证机制，只有通过此验证，客户端才能访问内核渲染管理器 drmGetMagic(psc->fd, &magic); DRI2Authenticate(priv->dpy, RootWindow(priv->dpy, screen), magic);

// 这次靠mesa自己来根据fd获取驱动名，也就是凭借客户端本地信息来获取最为适用的驱动， // 如果能找到就以此作为当前待加载的驱动名 char \*loader\_driverName; loader\_driverName = loader\_get\_driver\_for\_fd(psc->fd); if (loader\_driverName) \{ free(driverName); driverName = loader\_driverName; \}

// 加载dri驱动，即名为xo\_dri.so的文件，如i965\_dri.so psc->driver = driOpenDriver(driverName);

// 挂载驱动对应的扩展 const \_\_DRIextension \*\*extensions; extensions = driGetDriverExtensions(psc->driver, driverName);

for (i = 0; extensions\[i\]; i++) \{ // 挂载dri核心扩展 if (strcmp(extensions\[i\]->name, \_\_DRI\_CORE) == 0) psc->core = (\_\_DRIcoreExtension \*) extensions\[i\]; // 挂载dri2扩展 if (strcmp(extensions\[i\]->name, \_\_DRI\_DRI2) == 0) psc->dri2 = (\_\_DRIdri2Extension \*) extensions\[i\]; \}

// 创建对应屏幕的私有驱动信息 psc->driScreen = psc->dri2->createNewScreen2(screen, psc->fd, (const \_\_DRIextension \*\*)&pdp->loader\_extensions\[0\], extensions, &driver\_configs, psc);

至于createNewScreen2在哪里？ 在dri\_util.c文件中有：

/\*\* DRI2 interface \*/ const \_\_DRIdri2Extension driDRI2Extension = \{ .base = \{ \_\_DRI\_DRI2, 4 \}, .createNewScreen = dri2CreateNewScreen, .createNewDrawable = driCreateNewDrawable, .createNewContext = driCreateNewContext, .getAPIMask = driGetAPIMask, .createNewContextForAPI = driCreateNewContextForAPI, .allocateBuffer = dri2AllocateBuffer, .releaseBuffer = dri2ReleaseBuffer, .createContextAttribs = driCreateContextAttribs, .createNewScreen2 = driCreateNewScreen2, \};

// 为struct dri2\_screen \*psc挂载扩展的实现函数，并标明当前平台对这些扩展的实际支持情况 dri2BindExtensions(psc, priv, driverName);

// 根据刚创建dri2 screen，将其显示模式转换为的glx\_config格式 configs = driConvertConfigs(psc->core, psc->base.configs, driver\_configs); visuals = driConvertConfigs(psc->core, psc->base.visuals, driver\_configs);

// 由于每个显示设备实际仅采用一种显示模式，因此仅保留当前环境中使用的这一种模式，而销毁其他 // 模式 glx\_config\_destroy\_list(psc->base.configs); psc->base.configs = configs; glx\_config\_destroy\_list(psc->base.visuals); psc->base.visuals = visuals;

// 记录所创建dri2 screen的驱动信息 psc->driver\_configs = driver\_configs;

// vtable的类型为glx\_screen\_vtable，其中包含4个函数指针，分别为：create\_context、 // create\_context\_attribs、query\_renderer\_integer、query\_renderer\_string // 另外，在dri2的实现中，dri2\_screen\_vtable的定义为： // static const struct glx\_screen\_vtable dri2\_screen\_vtable = \{ // .create\_context = dri2\_create\_context, // .create\_context\_attribs = dri2\_create\_context\_attribs, // .query\_renderer\_integer = dri2\_query\_renderer\_integer, // .query\_renderer\_string = dri2\_query\_renderer\_string, // \}; psc->base.vtable = &dri2\_screen\_vtable;

// \_\_GLXDRIscreen结构体中包括的函数有：destroyScreen、createContext、createDrawable、 // swapBuffers、copySubBuffer、getDrawableMSC、waitForMSC、waitForSBC、setSwapInterval、 // getSwapInterval、getBufferAge \_\_GLXDRIscreen \*psp; psp = &psc->vtable; psc->base.driScreen = psp; // 开始挂载各种函数…… psp->destroyScreen = dri2DestroyScreen; psp->createDrawable = dri2CreateDrawable; psp->swapBuffers = dri2SwapBuffers; psp->getDrawableMSC = dri2DrawableGetMSC; psp->waitForMSC = dri2WaitForMSC; psp->waitForSBC = dri2WaitForSBC; psp->setSwapInterval = dri2SetSwapInterval; psp->getSwapInterval = dri2GetSwapInterval; psp->getBufferAge = NULL;

// 以下拓展用来实现精确垂直同步，详见拓展文档GLX\_OML\_sync\_control.txt // 什么？configQueryb函数在哪？见文件dri\_util.c： // const \_\_DRI2configQueryExtension dri2ConfigQueryExtension = \{ // .base = \{ \_\_DRI2\_CONFIG\_QUERY, 1 \}, // .configQueryb = dri2ConfigQueryb, // .configQueryi = dri2ConfigQueryi, // .configQueryf = dri2ConfigQueryf, // \}; unsigned char disable; // 根据平台对GLX\_OML\_sync\_control扩展的支持情况，而开启此扩展 if (psc->config->configQueryb(psc->driScreen, "glx\_disable\_oml\_sync\_control", &disable) || !disable) \_\_glXEnableDirectExtension(&psc->base, "GLX\_OML\_sync\_control");

// 挂载dr2的copySubBuffer函数实现 psp->copySubBuffer = dri2CopySubBuffer; // 开启GLX\_MESA\_copy\_sub\_buffer扩展 \_\_glXEnableDirectExtension(&psc->base, "GLX\_MESA\_copy\_sub\_buffer");

// 驱动对应的函数已加载完毕，释放其字符串内存 free(driverName); free(deviceName);

return &psc->base;

\-----------------------------dri2CreateScreen基本流程再见------------------------- again，大多glx函数的实现都依赖glx\_display，也就是Display的对应glx扩展。所以在glx函数实现中都会先调用\_\_glXInitialize()索取glx\_display。\_\_glXInitialize()会在全局glx\_displays链中查找对应的glx\_display结构体，如果不存在（如第一次调用glx函数），则会根据传入的Display \*参数构造出对应的glx\_display，加入全局glx\_displays链供后续使用，并将此glx\_display返回供glx函数执行后续逻辑。

有人可能会问，既然是glx direct + dri直接渲染模式为什么还有那么多代码涉及X的交互？那是因为dri只管GPU加速渲染，而实际的显示工作却是在X的管控下，因此，当然也就需要有X部分参与进来~

\-----------------------------正题-------------------------

解决完\_\_glXInitialize()后，现在按《OpenGL辅助工具》里OpenGL应用程序中glx函数的调用顺序简单进行讲解。

glXGetProcAddressARB()函数可用于加载glXCreateContextAttribsARB()。在mesa的实现中，glx维护了一个下列结构体构成的表： struct name\_address\_pair \{ const char \*Name; GLvoid \*Address; \}; 第一项Name即glx函数名，如glXCreateContextAttribsARB。第二项Address则是其地址。这样，glXGetProcAddressARB()即可借助此name\_address\_pair表来查询要加载的函数，并返回其实际地址。此函数还可加载其他glx或gl函数，此暂不讨论。

glXGetFBConfigs()、 glXGetFBConfigAttrib()与glXGetVisualFromFBConfig()三个函数的流程都很简单，即根据\_\_glXInitialize()中与X server交互所得到并记录的平台显示设备信息（如显示模式、帧缓冲区的设置组合），来获取平台所支持的设定，从而令程序员根据查询结果针对OpenGL应用进行相应的设置。

接下来轮到一个关键函数glXCreateContextAttribsARB()，目前位于src/glx/create\_context.c文件中。

\-----------------------------glXCreateContextAttribsARB()你好-------------------------

\-----------------------------glXCreateContextAttribsARB()再见-------------------------

btw，Windows平台上窗口系统与GPU加速渲染（D3D）都是微软自己供应，且限制在一个平台上，所以后面好多流程都不用用户操心。像swapchain交换链这样的操作其实是需要窗口系统协作的，在Linux系统需要X与GLX、mesa3d（OpenGL）的交互，而Windows中抽象为DXGI，用户只需轻松调用几个函数，了解下基本的工作机制就能上手了。这也就是统一平台的优势吧！

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWc5LmRvdWJhbmlvLmNvbS92aWV3L25vdGUvbC9wdWJsaWMvcDYwMDc0MTc0LndlYnA?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWc5LmRvdWJhbmlvLmNvbS92aWV3L25vdGUvbC9wdWJsaWMvcDYwMTc4OTg0LndlYnA?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWczLmRvdWJhbmlvLmNvbS92aWV3L25vdGUvbC9wdWJsaWMvcDYwODA3MDUwLndlYnA?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcxLmRvdWJhbmlvLmNvbS92aWV3L25vdGUvbC9wdWJsaWMvcDYwODA3MDc3LndlYnA?x-oss-process=image/format,png