Let's upstream all profiles in common/ to nixos

[Mic92]

Having generic hardware modules profiles available allows us to include them automatically
in tools like nixos-generate-config and co.

Hence I am proposing to upstream all our modules in common and remove them from this repository:

• common/cpu/intel/tiger-lake/default.nix
• common/cpu/intel/sandy-bridge/default.nix
• common/cpu/intel/kaby-lake/default.nix
• common/cpu/intel/cpu-only.nix
• common/cpu/intel/default.nix
  • Note: We are currently doing igpu configuration in our CPU configuration. We should probably separate these two things when upstreaming, since not all Intel CPUs have a GPU.
• common/cpu/intel/jasper-lake/default.nix
• common/cpu/intel/elkhart-lake/default.nix
• common/cpu/intel/comet-lake/default.nix
• common/cpu/amd/raphael/igpu.nix
• common/cpu/amd/zenpower.nix
• common/cpu/amd/default.nix
• common/cpu/amd/pstate.nix
• common/pc/default.nix
• common/pc/ssd/default.nix
• common/pc/hdd/default.nix
• common/pc/laptop/acpi_call.nix
• common/pc/laptop/hdd/default.nix
• common/pc/laptop/default.nix
• common/hidpi.nix
• common/gpu/nvidia/prime-sync.nix
• common/gpu/nvidia/prime.nix
• common/gpu/nvidia/disable.nix
• common/gpu/nvidia/default.nix
• common/gpu/amd/default.nix
• common/gpu/amd/sea-islands/default.nix
• common/gpu/amd/southern-islands/default.nix
• common/gpu/intel/default.nix
• common/gpu/intel/disable.nix

Open questions:

• Do we upstream them as module options or as importable profiles?

[SuperSandro2000]

I want to throw the following snippet from nixos-modules into the ring, too.

    hardware.opengl = {
      extraPackages = with pkgs; [
        intel-compute-runtime # OpenCL library for iGPU
        # video encoding/decoding hardware acceleration
        intel-media-driver # broadwell or newer
        intel-vaapi-driver # older hardware like haswell
      ];
      extraPackages32 = with pkgs.pkgsi686Linux; [
        # video encoding/decoding hardware acceleration
        intel-media-driver # broadwell or newer
        intel-vaapi-driver # older hardware like haswell
      ];
    };

I think we should not upstream them as is, otherwise we have 20+ new modules which only contain minimal things. We should probably combine them into a general intel module where we have some options for CPU/GPU/etc.

[Mic92]

We should be soon able to drop the amdgpu module from nixos-hardware after https://nixpk.gs/pr-tracker.html?pr=319865 landed.

[Lyndeno]

I like the idea of configurable modules. Then we can have generic cpu/gpu modules where we can specify say, "kaby lake" or "rdna2", etc.

[Lyndeno]

Something along the idea of:

hardware.graphics.family = "rdna2";
hardware.processor.family = "zen3";
hardware.graphics.opencl.enable = true;
hardware.processor.enableMicrocode = true;

Then have the modules enable the proper settings: opencl packages, vaapi, thermald, patches, microcode (if unsupported in tree, perhaps for apple m series?) all configured for the given hardware families.

Since it is possible to have multiple GPUs, perhaps the graphics.family setting could take a list of families, and ensure setup for each.

[Mic92]

We should have at least a vendor for both gpu and cpus, to avoid collision names between family names.

[Mic92]

We want to provide the needed information with this project: https://github.com/numtide/nixos-facter

[MattSturgeon]

What's the migration path if I'm using some of the deprecated/removed modules?

Neither the warning or the issue description describe what I should do as an end-user 😉

The PR talks about upstreaming stuff, but I can't see any obvious recent changes in nixpkgs/nixos/hardware's history 🤔

---

For my case specifically:

I was using the common-cpu-intel-kaby-lake module, which was renamed to common-gpu-intel-kaby-lake without any deprecation warnings or aliases.
I just got an "attr doesn't exist" error after updating my lockfile, so I had to go hunting for recent changes.

The new name has a deprecation warning, but I can't work out what the alternative is supposed to be?

[Lyndeno]

There is no alternative currently.

I plan to upstream some of this soon. Perhaps we should not have a deprecation warning until then.