On Monday, 12 February 2024 21:25:35 CET Mario Limonciello wrote: > > My logic was that this is about AMD TEE (Trusted Execution Environment), > > which I *assumed* is part of/tied to the CPU. This thought is based on > > that on ARM platforms, you also have a TEE and that is part of the CPU > > (and implemented in TF-A IIUC). I can be wrong here ofc. > > To me using the nomenclature of "CPU" is confusing. We should be > calling these SoCs. While SoC may be technically more accurate, I'm not in favor of using it in this context as it doesn't give any hint on what it does. I'd use CPU for general processing and GPU for graphics processing. > Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly > called PSP) and various others. I would describe an APU as a CPU with integrated GPU. My guess is most people/end-users aren't even aware of the ASP/PSP. I would classify the various ASICs (like IPU/NPU) as part of the CPU, but it is (by definition?) an arbitrary qualification/separation. > > There's no need to pick an existing binary package. I could add it to amd- > > graphics, but I consider that a poor choice. I could create a new binary > > package `amdtee` in firmware-nonfree (source package). > > That would be fine afaic. > > > > So I have no strong feelings about it, just trying to find the best place > > for the `amdtee` dir. > > My general feeling is that having separated binary packages for all the > AMD 'things' makes things "generally" confusing for end users and is > needless extra work for you to maintain. I mostly agree. It isn't (much) extra work for 'me' though. > '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) > 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.
Attachment:
signature.asc
Description: This is a digitally signed message part.