You have the hardware itself, which is rather static and non-changeable after it was manufactured.
Then the firmware is the software that runs inside the card itself in some dedicated chip with interface to control that hardware. It is programmable and replaceable.
Then the driver is the software that runs on the OS, and acts as an interface for other softwares that run on the same OS to talk to if they want to use the GPU. The driver would use the interface that the firmware exposes. Since each OS has a different way of writing hardware interfaces drivers are written for a specific OS.
Then you have software like DirectX or OpenGL that provide yet another standardized interface, only this time between different manufacturers like NVidia, AMD, Intel, etc to talk to supported GPU drivers.
Then you would have the software itself, like a game engine, video player, whatever.
This is the most accurate description in this thread so far. You’re just missing bootcode, which is more like the step between hardware and software mentioned in the OP. It’s functionally like software (written in assembly and/or a programming language like C, compiled, assembled, and linked into an executable), but it’s stored in a ROM, which makes it like hardware. Unless there’s a patching system built in to the bootcode, you can’t modify it without a respin of the hardware (which is expensive and time consuming).
The microprocessor (mp) it runs on is hard-coded to load bootcode’s entry point when the mp is brought out of hard reset, and the code itself does the essential initialization of the SoC. It can handle things like enabling performance features, setting up default interrupt handlers, training links, bringing various other parts of the chip out of hard reset, repairing internal SRAM, setting up the chip to properly handle the parts that are and aren’t fused off, etc. Once it finishes, it starts the bios on CPUs (which is basically the bootcode for the motherboard, though it isn’t hard-coded but usually stored in a flash chip so it can be updated), or if it’s an embedded mp it can start firmware or just wait for an interrupt.
The bios sets up the motherboard and then starts the bootloader, which is located on a boot partition of a storage drive. The bootloader will then select and start the OS, which loads the drivers and provides the framework for software to find the relevant ones.
It’s all one big layers system.
For sake of example let’s take a GPU.
You have the hardware itself, which is rather static and non-changeable after it was manufactured.
Then the firmware is the software that runs inside the card itself in some dedicated chip with interface to control that hardware. It is programmable and replaceable.
Then the driver is the software that runs on the OS, and acts as an interface for other softwares that run on the same OS to talk to if they want to use the GPU. The driver would use the interface that the firmware exposes. Since each OS has a different way of writing hardware interfaces drivers are written for a specific OS.
Then you have software like DirectX or OpenGL that provide yet another standardized interface, only this time between different manufacturers like NVidia, AMD, Intel, etc to talk to supported GPU drivers.
Then you would have the software itself, like a game engine, video player, whatever.
This is the most accurate description in this thread so far. You’re just missing bootcode, which is more like the step between hardware and software mentioned in the OP. It’s functionally like software (written in assembly and/or a programming language like C, compiled, assembled, and linked into an executable), but it’s stored in a ROM, which makes it like hardware. Unless there’s a patching system built in to the bootcode, you can’t modify it without a respin of the hardware (which is expensive and time consuming).
The microprocessor (mp) it runs on is hard-coded to load bootcode’s entry point when the mp is brought out of hard reset, and the code itself does the essential initialization of the SoC. It can handle things like enabling performance features, setting up default interrupt handlers, training links, bringing various other parts of the chip out of hard reset, repairing internal SRAM, setting up the chip to properly handle the parts that are and aren’t fused off, etc. Once it finishes, it starts the bios on CPUs (which is basically the bootcode for the motherboard, though it isn’t hard-coded but usually stored in a flash chip so it can be updated), or if it’s an embedded mp it can start firmware or just wait for an interrupt.
The bios sets up the motherboard and then starts the bootloader, which is located on a boot partition of a storage drive. The bootloader will then select and start the OS, which loads the drivers and provides the framework for software to find the relevant ones.