| 15 May 2024 |
Atemu | Mainly the container setup thingy | 20:11:21 |
Atemu | The FHSEnv | 20:11:28 |
Atemu | Absolutely no chance of getting a high priority queue inside of a userns without patching the kernel to always allow it | 20:12:17 |
Tumble | Why are there things that do work though? | 20:14:47 |
Atemu | WDYM? | 20:17:14 |
Atemu | Except for the cap for the high priority queue, everything else should theoretically work | 20:17:48 |
Atemu | Well "work" as it's still SteamVR we're talking about here | 20:18:07 |
Tumble | In reply to @atemu12:matrix.org Absolutely no chance of getting a high priority queue inside of a userns without patching the kernel to always allow it Is it easy to patch the kernel? | 20:54:23 |
Atemu | Almost trivial thanks to NixOS but it theoretically opens you up to local DOS and you need to build every kernel update yourself | 20:59:15 |
Atemu | (Meaning on your hardware; you don't have to do any work here, just your PC) | 21:00:07 |
| jottr joined the room. | 21:18:03 |
matthewcroughan | In reply to @atemu12:matrix.org Absolutely no chance of getting a high priority queue inside of a userns without patching the kernel to always allow it I still want to know how to patch the kernel to achieve this | 21:47:31 |
matthewcroughan | steam works perfectly with programs.steam.enable = true; and steamvr + alvr via programs.alvr.enable = true also works very well, via nvidia/sway/vulkan | 21:48:10 |
matthewcroughan | but the problem is that alvr/steamvr timeout due to incredibly poor performance that is only observed in VR. Running the game works perfectly without steamvr | 21:48:36 |
matthewcroughan | the reason is likely due to the lack of capabilities due to fhsenv as outlined in https://github.com/NixOS/nixpkgs/issues/217119 | 21:49:17 |
matthewcroughan | I haven't even been able to verify what happens when you set nvidia.enable = true, though was advised by scrumplex to try hardcoding line 375 here https://github.com/NVIDIA/open-gpu-kernel-modules/blob/083cd9cf17ab95cd6f9fb50a5349c21eaa2f7d4b/kernel-open/nvidia/os-interface.c#L373-L376 | 21:50:48 |
matthewcroughan | * I haven't even been able to verify what happens when you set hardware.nvidia.open.enable = true, though was advised by scrumplex to try hardcoding line 375 here https://github.com/NVIDIA/open-gpu-kernel-modules/blob/083cd9cf17ab95cd6f9fb50a5349c21eaa2f7d4b/kernel-open/nvidia/os-interface.c#L373-L376 | 21:51:18 |
matthewcroughan | How are you supposed to confirm that the nvidia open drivers are loaded and being used? nvidia-smi doesn't really report it | 21:51:49 |
Atemu | Well, yes that's how you'd do it. Here's how he does it for AMDGPU: https://github.com/Scrumplex/pkgs/blob/dab552abe93c42e579cf5b8d8cbed3e286bb173f/kernelPatches/cap_sys_nice_begone.patch#L1 | 21:53:59 |
Atemu | * Well, yes that's how you'd do it. Here's how he does it for AMDGPU: https://github.com/Scrumplex/pkgs/blob/dab552abe93c42e579cf5b8d8cbed3e286bb173f/kernelPatches/cap_sys_nice_begone.patch | 21:54:02 |
matthewcroughan | Yeah I just have trouble confirming that I'm even using the open drivers in any tangible way | 21:54:32 |
Atemu | Can't help you with Nvidia stuff | 21:54:47 |
Atemu | Though I guess just look at the kernel modules? | 21:55:03 |
matthewcroughan | My solution has just been to use makeWindowsImage from github.com/MatthewCroughan/NixThePlanet to make a bootable windows disk, and just run that lol | 21:55:26 |
Atemu | Or simply check the kernel taint; it will tell you when proprietary modules are loaded | 21:55:34 |
matthewcroughan | In reply to @atemu12:matrix.org Though I guess just look at the kernel modules? I believe they're both called nvidia lol | 21:55:58 |
Atemu | Hm | 21:56:07 |
Atemu | Check /run/booted-system/kernel-modules/...? | 21:56:31 |
matthewcroughan | sway even has the same rendering errors, and tells me "you're using proprietary drivers" | 21:56:34 |
Atemu | modinfo etc. | 21:56:42 |