3 ms·

I applaud this effort. I hope we can get to a point where a GPU requires as many drivers as a CPU. I think one of the primary reasons more people don't target

by runeks 12y ago

I applaud this effort. I hope we can get to a point where a GPU requires as many drivers as a CPU. I think one of the primary reasons more people don't target GPUs to offload computation, is because it -- most often -- requires proprietary drivers running on the host OS, for it to work (at an acceptable speed). Imagine if putting an AMD of nVidia card in your box was the same as adding a CPU. If you wanted to write OpenCL to execute on the GPU, thread allocation, memory management etc. for that would be part of an open source OpenCL library, that your application links to, and then you can write OpenCL kernels that execute on the GPU via these libraries. No need for proprietary driver blobs running on the host machine. I hope we can get to a point where trying to sell a GPU that requires a proprietary driver running in the host OS is as viable as trying to sell a CPU that requires the same.

moron4hire 12y ago
I thought CPUs did have binary blob drivers, both in the BIOS and on the operating system.
- a-priori 12y ago
  Are you referring to the microcode updates that operating systems apply on startup? Those are binary blobs, but they're only to correct CPU errata.
  - moron4hire 12y ago
    I'm not really sure what exactly they are. I know I've had to update my BIOS to be able to use newer versions of CPUs that still fit in the old sockets before [1]. I know I've seen Windows updates for both the motherboard's chipset and for the CPU. But what difference any of that has made, I don't know. [1] Actually, that particular instance was a complete pain in the ass, because I had bought all of the parts new, but the motherboard didn't have the latest BIOS on it, and I didn't have a compatible CPU on hand. This was also before the liberal return policies that online vendors now have, so I ended up just ordering a different motherboard completely.
    - graycoder 12y ago
      You seem to be mixing up different concepts. The BIOS runs outside of the OS and helps all the parts of your computer speak to each other. This is why the process is a bit more involved than just running an update from your OS's update manager. The "binary blob" that's referred to when talking about GPU's is the huge piece of software that you have to download and install in order to make you graphics card able to use all of its features. Some graphics cards won't even use a display's full resolution without the correct driver. This is different to the CPU in that there is no big downloaded driver sitting between you and it. If you really want to understand where everything sits, you should check out a book or search for information on Computer Architecture.
      - gergytree 12y ago
        > You seem to be mixing up different concepts. This is oversimplifying but my understand is that graphics programs like games send data and instructions as a job into a queue managed by operating system to the CPU which then has to then quickly decide what to do with it. GPU's function as a sort of co-processor in that the CPU will offload a portion or all of the instructions/data of jobs where GPU processing is indicated in the job instructions. This is why all GPU processing involves CPU overhead. Also GPU's are somewhat bottle-necked by this whole process. It's my impression that current trends like Mantle, DX12 and Vulkan are trying to reduce the amount of stuff the CPU has to do to process jobs intended for the GPU. But they can never really eliminate the role of the CPU even in something like an ARM chip is embedded on the GPU board that handles most of the processing that the CPU would have done. tl;dr - CPU is what makes the computer happen but the GPU is like a dedicated graphics co-processor. Feel free to correct me if I'm wrong.
      - moron4hire 12y ago
        I took the post to which I originally replied to be more concerned about the proprietary nature of the driver, rather than the size. The BIOS is a type of simplistic set of drivers, even a basic operating system, in essence. My point was that the comparison to CPUs with regards to not needing proprietary drivers was not apt, as there are certainly several layers of proprietary code in between you and your CPU, for most systems.
- 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 ago
    Wasn'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?
    - 12y ago
mattnewport 12y ago
There have been significant benefits to having a driver / runtime layer between the application and the GPU. It has enabled a competitive ecosystem of GPU vendors and I don't think we would have seen as rapid a pace of innovation and performance improvements if we had had a de facto low level hardware interface proprietary to a particular vendor. This is not to criticize Vulkan, the trend to lower level APIs like Vulkan, DirectX 12 and Metal is a good one but I don't think the goal should be to eliminate the driver entirely or get rid of any hardware abstraction layer on non console platforms.
- TD-Linux 12y ago
  Having open GPU ISA's is not the same as requiring them all to be the same. GCC and LLVM both compile to a variety of architectures but manage to share a lot of code and optimizations between all of the targets. Having the same for GPUs, where the vendor gives you an ISA and you can use whatever compiler you like (even hand written assembly), would be a lot more preferable. This is what the open-source Gallium3D stack does, though it's hindered by relying on reverse-engineered information.

by runeks 12y ago

moron4hire 12y ago

I thought CPUs did have binary blob drivers, both in the BIOS and on the operating system.

a-priori 12y ago
Are you referring to the microcode updates that operating systems apply on startup? Those are binary blobs, but they're only to correct CPU errata.
- moron4hire 12y ago
  I'm not really sure what exactly they are. I know I've had to update my BIOS to be able to use newer versions of CPUs that still fit in the old sockets before [1]. I know I've seen Windows updates for both the motherboard's chipset and for the CPU. But what difference any of that has made, I don't know. [1] Actually, that particular instance was a complete pain in the ass, because I had bought all of the parts new, but the motherboard didn't have the latest BIOS on it, and I didn't have a compatible CPU on hand. This was also before the liberal return policies that online vendors now have, so I ended up just ordering a different motherboard completely.
  - graycoder 12y ago
    You seem to be mixing up different concepts. The BIOS runs outside of the OS and helps all the parts of your computer speak to each other. This is why the process is a bit more involved than just running an update from your OS's update manager. The "binary blob" that's referred to when talking about GPU's is the huge piece of software that you have to download and install in order to make you graphics card able to use all of its features. Some graphics cards won't even use a display's full resolution without the correct driver. This is different to the CPU in that there is no big downloaded driver sitting between you and it. If you really want to understand where everything sits, you should check out a book or search for information on Computer Architecture.
    - gergytree 12y ago
      > You seem to be mixing up different concepts. This is oversimplifying but my understand is that graphics programs like games send data and instructions as a job into a queue managed by operating system to the CPU which then has to then quickly decide what to do with it. GPU's function as a sort of co-processor in that the CPU will offload a portion or all of the instructions/data of jobs where GPU processing is indicated in the job instructions. This is why all GPU processing involves CPU overhead. Also GPU's are somewhat bottle-necked by this whole process. It's my impression that current trends like Mantle, DX12 and Vulkan are trying to reduce the amount of stuff the CPU has to do to process jobs intended for the GPU. But they can never really eliminate the role of the CPU even in something like an ARM chip is embedded on the GPU board that handles most of the processing that the CPU would have done. tl;dr - CPU is what makes the computer happen but the GPU is like a dedicated graphics co-processor. Feel free to correct me if I'm wrong.
    - moron4hire 12y ago
      I took the post to which I originally replied to be more concerned about the proprietary nature of the driver, rather than the size. The BIOS is a type of simplistic set of drivers, even a basic operating system, in essence. My point was that the comparison to CPUs with regards to not needing proprietary drivers was not apt, as there are certainly several layers of proprietary code in between you and your CPU, for most systems.
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 ago
  Wasn'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?
  - 12y ago

mattnewport 12y ago

There have been significant benefits to having a driver / runtime layer between the application and the GPU. It has enabled a competitive ecosystem of GPU vendors and I don't think we would have seen as rapid a pace of innovation and performance improvements if we had had a de facto low level hardware interface proprietary to a particular vendor. This is not to criticize Vulkan, the trend to lower level APIs like Vulkan, DirectX 12 and Metal is a good one but I don't think the goal should be to eliminate the driver entirely or get rid of any hardware abstraction layer on non console platforms.

TD-Linux 12y ago
Having open GPU ISA's is not the same as requiring them all to be the same. GCC and LLVM both compile to a variety of architectures but manage to share a lot of code and optimizations between all of the targets. Having the same for GPUs, where the vendor gives you an ISA and you can use whatever compiler you like (even hand written assembly), would be a lot more preferable. This is what the open-source Gallium3D stack does, though it's hindered by relying on reverse-engineered information.