4 ms·
A driver is always required in order for the OS to speak to hardware. That's essentially what a driver is: an interface between software and hardware. With CPU
by runeks 12y ago
A driver is always required in order for the OS to speak to hardware. That's essentially what a driver is: an interface between software and hardware.
With CPUs, the code needed to run in the host OS (the driver) is fairly simple code that gives access to the CPU hardware more or less as it is: practically speaking, everything the CPU itself can do, the compiler can output code to do directly. The output of the compiler (eg. gcc) is sent more or less as-is to the CPU for execution.
With a GPU, we have a large chunk of proprietary code running in the host OS (the GPU driver), which provides a 3D API interface, such as OpenGL or Direct3D, to the GPU hardware. There is a huge difference between what is sent to this driver code, and what the driver sends to the GPU hardware.
Applications submit, eg., OpenGL instructions to this driver, the driver compiles these OpenGL instructions into code that will execute on the GPU, and sends it to the GPU. So the GPU driver essentially acts as a closed source compiler, that compiles from OpenGL/Direct3D into whatever intermediate language the GPU accepts, which the GPU may further compile into something that its processors can execute.
So for a CPU, the compiler does most of the work, while for a GPU, the driver does most of the work, and actually functions as a closed source compiler. On top of that the driver handles memory management, and automatically allocates memory according which OpenGL instructions are executed.
Imagine if Intel provided a CPU that you could only use to execute Python code. It would require a closed source driver to work. This closed source driver would compile Python code submitted to it into some unknown instructions that execute on this CPU. It would also have exclusive control over an area of memory, that the driver would automatically allocate portions of, to store data from Python variables. That's essentially what nVidia and AMD offer, except the hardware is a processing unit that comes with its own RAM, and the language is OpenGL/Direct3D and not Python.
- nightski 12y agoWasn't this approach taken with good reason though? So the effort to get code running on multiple GPUs was a reasonable? Remember the days of when games would only support select GPUs? Sure you could have a standard like i386. But isn't it the case that there is a lot more innovation happening in the GPU architecture space making this very difficult?
- tree_of_item 12y agoThis is the rhetoric GPU vendors will use to justify their behavior, of course, but $billions and modern technology can address this if AMD and Nvidia feel that it is important.
- chongli 12y agoGCC supports waaaaay more different CPU architectures than these drivers do for GPU architectures. This argument has no merit. The only purpose for these closed architectures is vendor lock-in.
- anon4 12y agoAnd every vendor has an HLSL and a GLSL shader compiler. You also usually don't ship ten different binaries for ten different architectures, which you would need to do for GPUs.
- gnoway 12y agoIn this model I think you'd distribute something in an intermediate bytecode, like .NET does w/ MSIL, and then the target system would be responsible for precompiling. Edit: just saw this: https://news.ycombinator.com/item?id=9140001 https://news.ycombinator.com/item?id=9140001
- runeks 12y ago> Sure you could have a standard like i386. We're not talking about standardizing hardware (the ISA), but the API: Vulkan. It really doesn't matter in which form your hardware processing unit comes, as long as its driver accepts SPIR-V and can execute it on said processing unit.
- semi-extrinsic 12y agoApropos your hypothetical Intel throwing restrictions scenario: Intel has been considering [0] dropping OpenCL support on the Xeon Phi. Which is exactly that kind of asshole move. Not to say that Nvidia or AMD are good guys in this respect... [0] https://plus.google.com/105097056044353520580/posts/81ddzBqq2m9 https://plus.google.com/105097056044353520580/posts/81ddzBqq...
- semi-extrinsic 12y agoApropos your hypothetical Intel throwing restrictions scenario: Intel has been considering [0] dropping OpenCL support on the Xeon Phi. Which is exactly that kind of asshole move. Not to say that Nvidia or AMD are good guys in this respect... [0] https://plus.google.com/105097056044353520580/posts/81ddzBqq2m9 https://plus.google.com/105097056044353520580/posts/81ddzBqq...