blocks|key|3171409|text|C/C%2B%2B编译器/链接器只做一件事:它们将文本文件转换为在CPU上运行的一系列特定于机器的操作码。OpenGL和Direct3D仅仅是C/C%2B%2B+API；它们不能神奇地将C/C%2B%2B编译器/链接器转换为图形处理器的编译器/链接器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3171410|您编写的每一行C/C%2B%2B代码都将在CPU上执行。对OpenGL/Direct3D的调用将调用C/C%2B%2B库，无论是静态的还是动态的。|3171411|只有当你的代码显式地创建着色器时，"gpu程序“才会发挥作用。也就是说，如果在OpenGL/D3D中进行API调用，导致对着色器进行编译和链接。为此，您(在运行时，而不是C/C%2B%2B编译时)生成或加载以某种着色器语言表示着色器的字符串。然后将它们推送到着色器编译器中，并在该API中返回表示该着色器的对象。然后将一个或多个着色器应用于特定的渲染命令。这些步骤中的每一个都显式地发生在您的C/C%2B%2B代码的指导下，如前所述，这些代码在CPU上运行。|3171412|许多着色器语言使用类似C/C%2B%2B的语法。但这并不能使它们等同于C/C%2B%2B。|3171413|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

C/C++ compilers/linkers do exactly one thing: they convert text files into a series of machine-specific opcodes that are run on the CPU. OpenGL and Direct3D are just C/C++ APIs; they cannot magically convert your C/C++ compiler/linker into a compiler/linker for the GPU.

Every line of C/C++ code you write will be executed on the CPU. Calls to OpenGL/Direct3D will call into C/C++ libraries, static or dynamic as the case may be.

The only place when a "gpu program" would come into play is if your code explicitly creates shaders. That is, if you make the API calls into OpenGL/D3D that cause the compiling and linking of shaders. To do this, you (at runtime, not C/C++ compile-time) either generate or load strings that represent shaders in some shader language. You then shove them through the shader compiler, and get back an object in that API that represents that shader. You then apply one or more shaders to a particular rendering command. Each of these steps happen explicitly at the direction of your C/C++ code, which as previously stated runs on the CPU.

Many shader languages use C/C++-like syntax. But that doesn't make them equivalent to C/C++.

blocks|key|2957475|text|您的程序不是针对任何特定的图形处理器进行编译的；它只是针对将实现OpenGL的库进行动态链接。实际的实现可能涉及将OpenGL命令发送到GPU、运行软件回退、编译着色器并将其发送到GPU，甚至使用OpenGL命令的着色器回退。图形环境相当复杂。谢天谢地，链接将您与大多数驱动程序的复杂性隔离开来，让驱动程序实现者可以自由地使用他们认为合适的任何技术。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2957476|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Your program is not compiled for any particular GPU; it is just dynamically linked against a library that will implement OpenGL. The actual implementation might involve sending OpenGL commands to the GPU, running software fallbacks, compiling shaders and sending them to the GPU, or even using shader fallbacks to OpenGL commands. The graphics landscape is fairly complicated. Thankfully linking insulates you from most of the drivers' complexity, leaving driver implementers free to use whatever techniques they see fit.

blocks|key|2957501|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2957502|当我编译这个程序时，它是否会变成一系列ioctl调用，然后gpu驱动程序会向gpu发送适当的命令，所有旋转三角形和以适当的颜色设置适当像素的逻辑都会连接到gpu？或者程序会被编译成一个"gpu程序“，加载到gpu上并计算旋转等？|blockquote|2957503|2957504|2957505|你离得不远了。您的程序调用可安装的客户端驱动程序(这不是一个真正的驱动程序，它是一个用户空间共享库)。它将使用ioctl或类似的机制将数据传递给内核驱动程序。|2957506|对于下一部分，它取决于硬件。较老的显卡有一个所谓的“固定功能管道”。显卡中有用于矩阵的专用内存空间，以及用于纹理查找、混合等的专用硬件。视频驱动程序将为每个单元加载正确的数据和标志，然后设置DMA来传输顶点数据(位置、颜色、纹理坐标等)。|2957507|较新的硬件在显卡中具有处理器核心(“着色器”)，它们与CPU的不同之处在于，它们各自的运行速度要慢得多，但它们中有更多的处理器是并行工作的。对于这些视频卡，驱动程序准备在GPU着色器上运行的程序二进制文件。|2957508|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|N|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|O|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|P|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|R|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|S|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|T|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|U|7|@]|8|@]|9|$]]]|M|$]]

<blockquote>
 When I compile this program, will it be turned into a series of ioctl-calls, and the gpu driver then sends the appropriate commands to the gpu, where all the logic of rotating the triangle and setting the appropriate pixels in the appropriate color is wired in? Or will the program be compiled into a "gpu program" which is loaded onto the gpu and computes the rotation etc.? 
</blockquote>

You're not far off. Your program calls the installable client driver (which is not really a driver, it's a userspace shared library). That will use ioctl or a similar mechanism to pass data to the kernel driver.

For the next part, it depends on the hardware. Older video cards had what is called a "fixed-function pipeline". There were dedicated memory spaces in the video card for matrices, and dedicated hardware for texture lookup, blending, etc. The video driver would load the right data and flags for each of these units and then set up DMA to transfer your vertex data (position, color, texture coordinates, etc).

Newer hardware has processor cores ("shaders") inside the video card, which differ from your CPU in that they each run much slower, but there are many more of them working in parallel. For these video cards, the driver prepares program binaries to run on the GPU shaders.

blocks|key|2957532|text|这个问题几乎不可能回答，因为OpenGL本身只是一个前端应用程序接口，只要实现遵循规范，结果符合规范，就可以按照您喜欢的任何方式完成。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2957533|问题可能是:+OpenGL驱动程序如何在最低层上工作。现在，这又是不可能在一般情况下回答的，因为驱动程序与某个硬件紧密相关，无论开发人员如何设计，这些硬件可能会再次执行某些操作。|2957534|因此，问题应该是：“在OpenGL和图形系统的幕后，它的平均外观如何？”让我们从下往上看：|2957535|2957536|在最底层有一些图形设备。如今，这些GPU提供了一组控制其操作的寄存器(这些寄存器完全依赖于设备)，具有一些用于着色器的程序内存，用于输入数据(顶点、纹理等)的大容量内存。以及到系统其余部分的I/O通道，它通过该通道接收/发送数据和命令流。|ordered-list-item|2957537|图形驱动程序跟踪GPU状态和使用该GPU的所有资源应用程序。此外，它还负责转换或任何其他处理应用程序发送的数据(将纹理转换为GPU支持的像素格式，在GPU的机器代码中编译着色器)。此外，它还为应用程序提供了一些抽象的、依赖于驱动程序的接口。|2957538|然后是依赖于驱动程序的OpenGL客户端库/驱动程序。在Windows上，它由代理通过opengl32.dll加载，在Unix系统上，它驻留在两个位置：|2957539|2957540|-+X11+GLX+module+and+driver+dependent+GLX+driver
-+and+/usr/lib/libGL.so+may+contain+some+driver+dependent+stuff+for+direct+rendering|code-block|syntax|javascript|2957541|在MacOS+X上，这恰好是"OpenGL框架“。|2957542|正是这一部分将OpenGL调用转换为对(2)中描述的驱动程序部分中的驱动程序特定函数的调用。|2957543|2957544|最后是实际的OpenGL+API库，在Windows中是opengl32.dll，在Unix+/usr/lib/libGL.so上；这主要是将命令传递给正确的OpenGL实现。|2957545|2957546|实际通信是如何发生的不能一概而论：|2957547|在Unix中，3<->4连接可以通过套接字(是的，它可以，如果您愿意的话，也可以通过网络)或通过共享内存进行连接。在Windows中，接口库和驱动程序客户端都被加载到进程地址空间中，因此没有太多的通信，只是简单的函数调用和变量/指针传递。在Windows中，这类似于Windows，只是在OpenGL界面和驱动程序客户端之间没有分离(这就是为什么MacOS+X跟不上新的OpenGL版本的原因，它总是需要完全的操作系统升级才能提供新的框架)。|2957548|2之间的通信可以通过ioctl、读/写，或者通过将一些存储器映射到进程地址空间并配置MMU以在对该存储器的改变完成时触发一些驱动程序代码。这在任何操作系统上都非常相似，因为您总是必须跨越内核/用户的边界:最终，您需要经历一些syscall。|2957549|系统与GPU之间的通信是通过外围总线及其定义的访问方式实现的，因此PCI、AGP、PCI-E等都是通过Port-I/O、内存映射I/O、DMA、IRQ等方式工作的。|2957550|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1D|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|1F|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|1G|8|@]|9|@]|A|$]]|$1|L|3|M|5|I|7|1H|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|1J|8|@]|9|@]|A|$R|S]]|$1|T|3|U|5|6|7|1K|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1L|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|I|7|1N|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1P|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1R|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|1S|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|1A|$]]

This question is almost impossible to answer because OpenGL by itself is just a front end API, and as long as an implementations adheres to the specification and the outcome conforms to this it can be done any way you like.

The question may have been: How does an OpenGL driver work on the lowest level. Now this is again impossible to answer in general, as a driver is closely tied to some piece of hardware, which may again do things however the developer designed it.

So the question should have been: "How does it look on average behind the scenes of OpenGL and the graphics system?". Let's look at this from the bottom up:

<ol>
<li>At the lowest level there's some graphics device. Nowadays these are GPUs which provide a set of registers controlling their operation (which registers exactly is device dependent) have some program memory for shaders, bulk memory for input data (vertices, textures, etc.) and an I/O channel to the rest of the system over which it recieves/sends data and command streams.</li>
<li>The graphics driver keeps track of the GPUs state and all the resources application programs that make use of the GPU. Also it is responsible for conversion or any other processing the data sent by applications (convert textures into the pixelformat supported by the GPU, compile shaders in the machine code of the GPU). Furthermore it provides some abstract, driver dependent interface to application programs.</li>
<li>Then there's the driver dependent OpenGL client library/driver. On Windows this gets 
loaded by proxy through opengl32.dll, on Unix systems this resides in two places:

<ul>
<li>X11 GLX module and driver dependent GLX driver</li>
<li>and /usr/lib/libGL.so may contain some driver dependent stuff for direct rendering</li>
</ul>

On MacOS X this happens to be the "OpenGL Framework".

It is this part that translates OpenGL calls how you do it into calls to the driver specific functions in the part of the driver described in (2).</li>
<li>Finally the actual OpenGL API library, opengl32.dll in Windows, and on Unix /usr/lib/libGL.so; this mostly just passes down the commands to the OpenGL implementation proper.</li>
</ol>

How the actual communication happens can not be generalized:

In Unix the 3&lt;->4 connection may happen either over Sockets (yes, it may, and does go over network if you want to) or through Shared Memory. In Windows the interface library and the driver client are both loaded into the process address space, so that's no so much communication but simple function calls and variable/pointer passing. In MacOS X this is similar to Windows, only that there's no separation between OpenGL interface and driver client (that's the reason why MacOS X is so slow to keep up with new OpenGL versions, it always requires a full operating system upgrade to deliver the new framework).

Communication betwen 3&lt;->2 may go through ioctl, read/write, or through mapping some memory into process address space and configuring the MMU to trigger some driver code whenever changes to that memory are done. This is quite similar on any operating system since you always have to cross the kernel/userland boundary: Ultimately you go through some syscall.

Communication between system and GPU happen through the periphial bus and the access methods it defines, so PCI, AGP, PCI-E, etc, which work through Port-I/O, Memory Mapped I/O, DMA, IRQs.

I understand how to write OpenGL/DirectX programs, and I know the maths and the conceptual stuff behind it, but I'm curious how the GPU-CPU communication works on a low level.

Say I've got an OpenGL program written in C that displays a triangle and rotates the camera by 45 degrees. When I compile this program, will it be turned into a series of ioctl-calls, and the gpu driver then sends the appropriate commands to the gpu, where all the logic of rotating the triangle and setting the appropriate pixels in the appropriate color is wired in? Or will the program be compiled into a "gpu program" which is loaded onto the gpu and computes the rotation etc.? Or something completely different?

Edit:
A few days later I found this article series, which basically answers the question:
<a href="http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/" rel="noreferrer">http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/</a>

How does OpenGL work at the lowest level?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我知道如何编写OpenGL/DirectX程序，我知道它背后的数学和概念知识，但我很好奇GPU-CPU通信是如何在低级别上工作的。假设我有一个用C语言编写的OpenGL程序，它显示一个三角形，并将相机旋转45度。当我编译这个程序时，它会被转换成一系列的ioctl调用，然后gpu驱动程序会向gpu发送适当的命令，在gpu...

问OpenGL在最底层是如何工作的？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OpenGL在最底层是如何工作的？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OpenGL在最底层是如何工作的？
EN