4 ms·

> It depends on the context: GPUs are probably the most complex chips out there, and if you want to them to be ready to render at power on, they probably need f

> It depends on the context: GPUs are probably the most complex chips out there, and if you want to them to be ready to render at power on, they probably need firmware Nvidia believes in shipping a garbage, throttled down and limited firmware to get you some initial rendering, but if you need anything that's not basic rendering, you load a proprietary signed blob, with proprietary "microcode" for it's proprietary GPU instruction set when you initialize the OS graphics driver. For AMD GPUs the situation is more or less the same, except that without said "binary blob" the GPU isn't on-purpose throttled down near as much. Or are you implying that we need RISC-V success as a GPU ISA too?

sylware 4y ago
Regarding AMD GPU firmware, let's take the linux case, "bug fixed" firmware images are shipped in the linux firmware repo. The drivers loads those images once some AMD GPU is detected. What's weird is the huge amount of additional work the driver does after loading the firmware images in order to setup the hardware programing interfaces (the command ring buffers and the irq ring buffer). It should be near-0 work beyond loading the "bug fixed" firmware images. The now open sourced nvidia kernel modules should do something similar I guess: loading "bug fixed" firmware images. The "near-zero" drivers means the default firmware does provide already the hardware programing interfaces at power on. On such complex hardware, expect bugs in this default firmware. Currently, we have a driver written in gcc kernel C dialect and for linux, not ideal. I spotted a RISC-V GPU the other day. I guess I wish for CPU/GPU ISAs without toxic PI tied to them (like x86/arm) to succeed. I dunno if AMD GPU isa has any PI tied to them though a la arm though. Rumors: AMD may be interested in RISC-V ISAs for its GPUs and CPUs.
- ElectricalUnion 4y ago
  > What's weird is the huge amount of additional work the driver does after loading the firmware images in order to setup the hardware programing interfaces (the command ring buffers and the irq ring buffer). It should be near-0 work beyond loading the "bug fixed" firmware images. Some (most?) programs expect a high level OpenGL GPU API, instead of dealing with Vulkan/bare-metal directly. Converting some very high level OpenGL calls to actual API is part of what is expected from the driver. To implement this, you would most likely require a high performance, high IPC CPU embedded in the GPU - a waste since you already have one in the system. > The now open sourced nvidia kernel modules should do something similar I guess Those open sourced nvidia kernel modules does this - it is "near-zero" as you describe - they just moved almost everything important to the proprietary binary blob loaded to the GPU. > Rumors: AMD may be interested in RISC-V ISAs Everyone is interested in RISC-V, not necessarily in user-visible RISC-V ISAs.
  - sylware 4y ago
    When I said the AMD drivers were doing tons of things beyond simple firmware image loading, that was not to prepare for opengl. It is a sh*t ton of additional hardware setup in order to get the basic hardware programing interfaces, those used by opengl _and_ vulkan. If you say that nvidia was successful at getting a near-0 driver once the firmware images were loaded, that would explained the rumors that AMD would like a near-0 driver too. If true for nvidia, it means their kernel driver is almost empty, some firmware loading, and only memory mappings around for the ring buffers (dunno if nvidia has virtual memory spaces). Without the compute/3D pipeline programing from userspace, the lapsus hackers will feel kind of even more ripped off, since the kernel modules are somewhat basic. Ofc, when I was talking about RISC-V ISAs, I was actually talking about user visible ISAs.

sylware 4y ago

Regarding AMD GPU firmware, let's take the linux case, "bug fixed" firmware images are shipped in the linux firmware repo. The drivers loads those images once some AMD GPU is detected. What's weird is the huge amount of additional work the driver does after loading the firmware images in order to setup the hardware programing interfaces (the command ring buffers and the irq ring buffer). It should be near-0 work beyond loading the "bug fixed" firmware images. The now open sourced nvidia kernel modules should do something similar I guess: loading "bug fixed" firmware images. The "near-zero" drivers means the default firmware does provide already the hardware programing interfaces at power on. On such complex hardware, expect bugs in this default firmware. Currently, we have a driver written in gcc kernel C dialect and for linux, not ideal. I spotted a RISC-V GPU the other day. I guess I wish for CPU/GPU ISAs without toxic PI tied to them (like x86/arm) to succeed. I dunno if AMD GPU isa has any PI tied to them though a la arm though. Rumors: AMD may be interested in RISC-V ISAs for its GPUs and CPUs.

ElectricalUnion 4y ago
> What's weird is the huge amount of additional work the driver does after loading the firmware images in order to setup the hardware programing interfaces (the command ring buffers and the irq ring buffer). It should be near-0 work beyond loading the "bug fixed" firmware images. Some (most?) programs expect a high level OpenGL GPU API, instead of dealing with Vulkan/bare-metal directly. Converting some very high level OpenGL calls to actual API is part of what is expected from the driver. To implement this, you would most likely require a high performance, high IPC CPU embedded in the GPU - a waste since you already have one in the system. > The now open sourced nvidia kernel modules should do something similar I guess Those open sourced nvidia kernel modules does this - it is "near-zero" as you describe - they just moved almost everything important to the proprietary binary blob loaded to the GPU. > Rumors: AMD may be interested in RISC-V ISAs Everyone is interested in RISC-V, not necessarily in user-visible RISC-V ISAs.
- sylware 4y ago
  When I said the AMD drivers were doing tons of things beyond simple firmware image loading, that was not to prepare for opengl. It is a sh*t ton of additional hardware setup in order to get the basic hardware programing interfaces, those used by opengl _and_ vulkan. If you say that nvidia was successful at getting a near-0 driver once the firmware images were loaded, that would explained the rumors that AMD would like a near-0 driver too. If true for nvidia, it means their kernel driver is almost empty, some firmware loading, and only memory mappings around for the ring buffers (dunno if nvidia has virtual memory spaces). Without the compute/3D pipeline programing from userspace, the lapsus hackers will feel kind of even more ripped off, since the kernel modules are somewhat basic. Ofc, when I was talking about RISC-V ISAs, I was actually talking about user visible ISAs.