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.

[ahydronous]

Before you upstream things, a large corrective+feature pass would be nice to do, as I assume afterwards it might be harder to get things in there.

#1205
#1243
#1244
#1245
#1246

In general the Intel GPU side needs a lot of work. There is for example a comet-lake.nix, but no such Intel iGPU generation exists. 10th gen (Comet Lake) CPUs use the Ice Lake GPU generation. There's a lot of places where psr, fbc and guc are manually set to 1 or 2 when they already already set to -1 ( = turn on, unless problematic) by default by the kernel for those devices.

It'd also just be nice to add all the CPU and GPU gens, even if it'll be mostly copy-paste/boilerplate. Perhaps also nice to either add the generation name in the filename or file itself. For example for Intel CPUs, doing skylake-7.nix and coffeelake-8.nix. Most people don't know their CPU generation's name, but they know 11400 = 11th gen.

I'm fully willing to do the labor for that once I have the time, but I thought I should bring it up before an upstream happens.

[Mic92]

Why not bring it up, while you upstream a module? The modules that we bring upstream do not need to be literally the same but can be improved version. They just need to cover the same area so. But you can also do pull requests in nixos-hardware if you want. Sorry, I don't have time to go and address your issues, but I would merge your pull requests.