5 ms·

So does anyone know now if AMD Vulkan GPU's are fully open sourced? i.e. can we build everything from source, firmware, drivers, app and then use it without hav

So does anyone know now if AMD Vulkan GPU's are fully open sourced? i.e. can we build everything from source, firmware, drivers, app and then use it without having to trust any blobs?

boudin 8y ago
Firmware isn't opensource. Kernel and userland drivers are. There's RADV as an alternative to AMDVLK which was created while AMDVLK was closed source. Both are maintained.
- zepearl 8y ago
  But it's correct to say that the firmware used under Linux is the same one that is used as well under Windows (maybe as well MacOS)... or not? (I personally understand that the "firmware" does the low-level stuff, and the drivers of the OS provide the abstraction through their functions, but I might be terribly wrong)
  - woodrowbarlow 8y ago
    yes, the firmware is the same regardless of your OS. think of it like using an open-source client for slack: it still hits the API of a closed blob (the slack servers).
    - zepearl 8y ago
      Thx! Then, if the performance is "worse" or "better" for a specific OS, it's just because the code of the open-source part (kernel and/or userland progs) and/or the app (game/application/whatever) is not written as well as on the other OSs, right? Indirectly asking as well: even if the firmware is alway the same one, there is no "part" of the firmware that is dedicated to only a specific OS?
      - boudin 8y ago
        Performance-wise yes, logicaly the difference would come from the driver part. For the firmware, it's hard to know, i think only someone from AMD can answer this. It's technically possible if part of a firmware is used only by the Windows driver for example. After, I have no idea, if it's the case...
      - woodrowbarlow 8y ago
        performance differences come down to how the driver utilizes the firmware, or how the applications utilize the driver. there may be some other factors, like how the OS manages memory buffers. it's unlikely that the firmware has OS-specific code. it's more likely that the firmware exposes functionality that happens to be taken advantage of by one OS' drivers more than it is by another OS' drivers -- perhaps in part because of differences in driver execution models on different kernels. or sometimes (as with nvidia) because a proprietary closed-source windows driver was written by the company with access to private documentation of all the firmware's features while the community-written linux OSS driver was written with incomplete knowledge of the firmware's features derived from reverse engineering.
- makomk 8y ago
  One of the obnoxious consequences of the firmware not being open source is that, even though both RADV and AMDVLK support GPUs as far back as the 7xxx series, the AMDGPU driver required to use them can't be enabled by default. The released firmware for the UVD video decode unit doesn't support the framebuffer addresses used by AMDGPU, meaning that it can't support hardware video decode until they release an up-to-date firmware: https://lists.freedesktop.org/archives/amd-gfx/2017-November/015795.html https://lists.freedesktop.org/archives/amd-gfx/2017-November... So far users have been waiting for over a year and heard only silence. I suspect, given their attitude to older hardware, the required firmware will never be released.
vardump 8y ago
I think open source GPU firmware will be very unlikely to happen for any high-performance part in the near-medium term future.
monocasa 8y ago
Some of the firmware has been reverse engineered, with community supplied patches, but that's not supported at all by AMD. https://github.com/fail0verflow/radeon-tools/tree/master/f32 https://github.com/fail0verflow/radeon-tools/tree/master/f32 What's interesting is there's not a clear reason for the firmware to not be opened other than it's probably a huge amount of work to document. It looks like an unexpected house design so there shouldn't be IP issues, and it's pretty mundane stuff so there shouldn't be trade secret issues either. : /
- rhn_mk1 8y ago
  That has actually been discussed by an AMD employee [0]. Commentary [1]. [0] https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able_to_game_anytime_soon_using_amd/e3qgqp3/ https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able... [1] https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_an_amd_employee_commented_on_the/ https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_...
  - Hackbraten 8y ago
    I always knew bibliographies started at 0!
  - monocasa 8y ago
    A lot of that falls flat. Part of what he's saying is in regard to signed updates, but the microcode on at least some pretty new chips isn't signed, as the fail0verflow guys were able to patch it.
bayindirh 8y ago
AMD beta tester here. AMD separated HDCP and DRM related silicon from video acceleration units some time ago to be able to open source their GPUs completely sans the NDA bound stuff. Even this is a very big generosity and step from them for the Linux community. I'm sure that the firmware contains some highly proprietary and revealing information about some of their secret sauce. So, they won't be able to do it even if they want to.
- novaRom 8y ago
  What HDL is in use at AMD - Verilog like at Nvidia or SystemC like at Intel?
  - bayindirh 8y ago
    Sorry, that's beyond my knowledge.
- shmerl 8y ago
  There is no secret sauce in the firmware, but it has HDCP garbage (which is causing it to remain a blob). AMD could provide one without HDCP as an open option, but I suppose they didn't see enough demand for it.
  - bayindirh 8y ago
    I think it also had the clocks, memory settings, thermal thresholds and other hardware tuning parameters. So opening the firmware may also lead to many many fried boards. Also, if the core enablement and configuration is done in the firmware, some vendors may find themselves in a hard position, since they may be selling crippled GPUs as lower spec cards. Last, but not the least if folks enable faulty CUs in their cards and see the faults, they may create some (albeit unjustified) noise in "teh internets", which will return as bad press. So, while the firmware is good for research and educational purposes, it's also a Pandora's box IMHO.
    - shmerl 8y ago

So does anyone know now if AMD Vulkan GPU's are fully open sourced? i.e. can we build everything from source, firmware, drivers, app and then use it without having to trust any blobs?

boudin 8y ago

Firmware isn't opensource. Kernel and userland drivers are. There's RADV as an alternative to AMDVLK which was created while AMDVLK was closed source. Both are maintained.

zepearl 8y ago
But it's correct to say that the firmware used under Linux is the same one that is used as well under Windows (maybe as well MacOS)... or not? (I personally understand that the "firmware" does the low-level stuff, and the drivers of the OS provide the abstraction through their functions, but I might be terribly wrong)
- woodrowbarlow 8y ago
  yes, the firmware is the same regardless of your OS. think of it like using an open-source client for slack: it still hits the API of a closed blob (the slack servers).
  - zepearl 8y ago
    Thx! Then, if the performance is "worse" or "better" for a specific OS, it's just because the code of the open-source part (kernel and/or userland progs) and/or the app (game/application/whatever) is not written as well as on the other OSs, right? Indirectly asking as well: even if the firmware is alway the same one, there is no "part" of the firmware that is dedicated to only a specific OS?
    - boudin 8y ago
      Performance-wise yes, logicaly the difference would come from the driver part. For the firmware, it's hard to know, i think only someone from AMD can answer this. It's technically possible if part of a firmware is used only by the Windows driver for example. After, I have no idea, if it's the case...
    - woodrowbarlow 8y ago
      performance differences come down to how the driver utilizes the firmware, or how the applications utilize the driver. there may be some other factors, like how the OS manages memory buffers. it's unlikely that the firmware has OS-specific code. it's more likely that the firmware exposes functionality that happens to be taken advantage of by one OS' drivers more than it is by another OS' drivers -- perhaps in part because of differences in driver execution models on different kernels. or sometimes (as with nvidia) because a proprietary closed-source windows driver was written by the company with access to private documentation of all the firmware's features while the community-written linux OSS driver was written with incomplete knowledge of the firmware's features derived from reverse engineering.
makomk 8y ago
One of the obnoxious consequences of the firmware not being open source is that, even though both RADV and AMDVLK support GPUs as far back as the 7xxx series, the AMDGPU driver required to use them can't be enabled by default. The released firmware for the UVD video decode unit doesn't support the framebuffer addresses used by AMDGPU, meaning that it can't support hardware video decode until they release an up-to-date firmware: https://lists.freedesktop.org/archives/amd-gfx/2017-November/015795.html https://lists.freedesktop.org/archives/amd-gfx/2017-November... So far users have been waiting for over a year and heard only silence. I suspect, given their attitude to older hardware, the required firmware will never be released.

vardump 8y ago

I think open source GPU firmware will be very unlikely to happen for any high-performance part in the near-medium term future.

monocasa 8y ago

Some of the firmware has been reverse engineered, with community supplied patches, but that's not supported at all by AMD. https://github.com/fail0verflow/radeon-tools/tree/master/f32 https://github.com/fail0verflow/radeon-tools/tree/master/f32 What's interesting is there's not a clear reason for the firmware to not be opened other than it's probably a huge amount of work to document. It looks like an unexpected house design so there shouldn't be IP issues, and it's pretty mundane stuff so there shouldn't be trade secret issues either. : /

rhn_mk1 8y ago
That has actually been discussed by an AMD employee [0]. Commentary [1]. [0] https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able_to_game_anytime_soon_using_amd/e3qgqp3/ https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able... [1] https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_an_amd_employee_commented_on_the/ https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_...
- Hackbraten 8y ago
  I always knew bibliographies started at 0!
- monocasa 8y ago
  A lot of that falls flat. Part of what he's saying is in regard to signed updates, but the microcode on at least some pretty new chips isn't signed, as the fail0verflow guys were able to patch it.

bayindirh 8y ago

AMD beta tester here. AMD separated HDCP and DRM related silicon from video acceleration units some time ago to be able to open source their GPUs completely sans the NDA bound stuff. Even this is a very big generosity and step from them for the Linux community. I'm sure that the firmware contains some highly proprietary and revealing information about some of their secret sauce. So, they won't be able to do it even if they want to.

novaRom 8y ago
What HDL is in use at AMD - Verilog like at Nvidia or SystemC like at Intel?
- bayindirh 8y ago
  Sorry, that's beyond my knowledge.
shmerl 8y ago
There is no secret sauce in the firmware, but it has HDCP garbage (which is causing it to remain a blob). AMD could provide one without HDCP as an open option, but I suppose they didn't see enough demand for it.
- bayindirh 8y ago
  I think it also had the clocks, memory settings, thermal thresholds and other hardware tuning parameters. So opening the firmware may also lead to many many fried boards. Also, if the core enablement and configuration is done in the firmware, some vendors may find themselves in a hard position, since they may be selling crippled GPUs as lower spec cards. Last, but not the least if folks enable faulty CUs in their cards and see the faults, they may create some (albeit unjustified) noise in "teh internets", which will return as bad press. So, while the firmware is good for research and educational purposes, it's also a Pandora's box IMHO.
  - shmerl 8y ago