6 ms·

> why can't the hardware designer do something simple and clean If it was easy, it would not need firmware in the first place. Firmware is there because people

> why can't the hardware designer do something simple and clean If it was easy, it would not need firmware in the first place. Firmware is there because people expect certain features and quality of life. See softmodems. > write some assembly (without abusing the assembler preprocessor...) You want https://terralang.org/ https://terralang.org/ and not "just C"/"just Assembler" instead ?

trasz 4y ago
Firmware often decreases the quality of life. See Intel remote management/backdoor mechanism for example.
- pca006132 4y ago
  They can probably implement something similar directly in the silicon. It doesn't have to be software.
  - sylware 4y ago
    Ofc, it could be indeed 100% silicon... but for very complex hardware like GPUs, better to have some jingle software room in order to be able to fix "complexity bugs".
  - trasz 4y ago
    Implement the entire TCP/IP stack in silicon, as a backdoor? Nah.
- ElectricalUnion 4y ago
  > Firmware often decreases the quality of life. See Intel remote management/backdoor mechanism for example. IME is a bad example here. That's an entire upgradeable MINIX OS embedded in your system - if it was really firmware, Intel would not be able to update it, or you be able to neuter it.
sylware 4y ago
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 (which you would be able to update to fix "bugs") or we end up like what we have now, namely massive drivers locked-in with the gcc C kernel dialect, only there to expose a few 2^n bytes ring buffers (3D/dma/compute/irq/video_encode/video_decode) with their hardware doorbells. if risc-v is a success we don't need anything except a risc-v assembler: then the main pitfall would be the abuse of the macro preprocessor.
- ElectricalUnion 4y ago
  > 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.

trasz 4y ago

Firmware often decreases the quality of life. See Intel remote management/backdoor mechanism for example.

pca006132 4y ago
They can probably implement something similar directly in the silicon. It doesn't have to be software.
- sylware 4y ago
  Ofc, it could be indeed 100% silicon... but for very complex hardware like GPUs, better to have some jingle software room in order to be able to fix "complexity bugs".
- trasz 4y ago
  Implement the entire TCP/IP stack in silicon, as a backdoor? Nah.
ElectricalUnion 4y ago
> Firmware often decreases the quality of life. See Intel remote management/backdoor mechanism for example. IME is a bad example here. That's an entire upgradeable MINIX OS embedded in your system - if it was really firmware, Intel would not be able to update it, or you be able to neuter it.

sylware 4y ago

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 (which you would be able to update to fix "bugs") or we end up like what we have now, namely massive drivers locked-in with the gcc C kernel dialect, only there to expose a few 2^n bytes ring buffers (3D/dma/compute/irq/video_encode/video_decode) with their hardware doorbells. if risc-v is a success we don't need anything except a risc-v assembler: then the main pitfall would be the abuse of the macro preprocessor.

ElectricalUnion 4y ago
> 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.