'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries
will go to linux-firmware.git and then where do those go?
My (current) thinking is to have 2 categories:
- AMD CPU related
- AMD GPU/graphics related
Current products only put the IPU/NPU in APU chips, but who is to stay;
those might end up in SoCs without graphics in the future too.
I think it's important to facilitate people having f.e. the following combos:
- Intel CPU with AMD GPU
- AMD CPU with Nvidia GPU
- AMD CPU with AMD GPU (discrete or integrated)
Preferably without having to install 100s of MB of firmware files of which 95%
the user doesn't actually need. (See f.e. https://bugs.debian.org/1057786)
You don't currently split up the AMD APU integrated graphics and dGPU,
and I doing this is a bad idea as it's possible to reuse IP versions on
APU and dGPU hardware. If they are the same then they would use the
same firmware binaries.
For reference on the size:
$ du -sh amdgpu
60M amdgpu
$ du -sh du -sh amdtee/
20K amdtee/
$ du -sh amd-ucode/
112K amd-ucode/
$ du -sh amd
268K amd
These aren't yet upstream, but so you can see the size:
$ du -sh amdnpu/
3.3M amdnpu/
How would you feel about making a master "amd" metapackage that pulls
them all? You can split as you see fit then and people who want the
'easy button' can just install that package.
I'm not much of a fan of such metapackages. I think it mostly indicates that
the purpose of the various packages isn't clear, so let's install all of them.
Clarifying the purpose better is a better solution imo.
I'm aware others feel different: https://bugs.debian.org/522415
I prefer to keep that discussion out of this bug though, feel free to open a
new bug for that if you do want it.
I think your suggestion to combine all the non graphics related binaries
to a single package and all graphics related binaries to another is fine.
