| 9 Apr 2026 |
 K900 | So an application can be given more real-VRAM allocation | 15:54:23 |
 anji | On Windows that prioritization can be per allocation, with various heuristics in UMD, KMD and vidmm itself. | 15:59:11 |
| K900 | This is already a thing on Linux as well | 15:59:31 |
| K900 | Mesa and the kernel both have heuristics on what to evict | 15:59:41 |
| K900 | And what to allocate where | 15:59:46 |
| anji | Yeah it makes sense. Just from that blog post "The real problem is that to the kernel driver, all memory looks the same. The kernel doesn’t know if it’s dealing with a highly-important object from a game or a static image from a random web app running in the background - all it sees is a list of buffers. As long as all buffers look the same, it is impossible to have the same approach work well for every one of all the wildly different situations a driver may encounter." | 15:59:51 |
| K900 | The kernel doesn't know which processes are more important | 16:00:17 |
| anji | I guess "the kernel" here just means the lower level mechanics not Mesa/dmemcg etc | 16:00:25 |
| K900 | Neither does Mesa really | 16:00:33 |
| K900 | The reason you need the KDE glue is because the desktop environment is what actually knows that information | 16:00:51 |
| anji | What is foreground yes. But internal prioritization mostly depends on the work submission, resource types, etc. UMD/KMD stuff. | 16:02:10 |
| K900 | The kernel does know and use that | 16:02:43 |
| anji | Regardless foreground application prioritization really is the most essential. So I hope all that can come together soon | 16:02:45 |
| anji | What system in the kernel does this? As far as I know dmemcg is just a small set of APIs to control vram priorization in regions? It's not a full system level memory manager is it? | 16:05:41 |
| K900 | It's not, the actual eviction heuristics are in the drivers | 16:06:17 |
| anji | Right. So different drivers have to make different prioritization decisions without necessarily seeing the total system picture. | 16:06:48 |
| anji | Which is different than vidmm | 16:06:55 |
| anji | I'm not arguing Linux necessarily needs such a complex video memory manager btw. Just trying to understand what is currently there and how it works. And it's cool to see progress here, because vram overcommit is/was pretty bad. | 16:13:17 |
 niklaskorz | The Nvidia open kernel modules support Linux heterogenous memory management but I don't know if this automatically entails memory eviction from vram to ram | 23:17:43 |
| 10 Apr 2026 |
 ccicnce113424 | https://github.com/NixOS/nixpkgs/pull/498612 | nixos/nvidia, linuxPackages.nvidia-x11: split proprietary kernel modules, use source-built ICDs, write params via modprobe
Can you have a look? | 09:07:01 |
| K900 | You probably want to talk to the CUDA folks for this tbh | 09:07:53 |
| K900 | They're de facto the ones in charge of the Nvidia proprietary stack | 09:08:01 |
| niklaskorz | Gaetan already reviewed it | 09:08:13 |
| niklaskorz | well, at least he reacted on the PR | 09:08:35 |
| K900 | I mean they should still be the ones to merge it probably | 09:10:11 |
| niklaskorz | agreed, I've request the team for review on the PR | 09:10:59 |
| niklaskorz | * agreed, I've requested the team for review on the PR | 09:11:15 |
| niklaskorz | I'll also smoke test the changes on my system in a moment | 09:15:31 |
| K900 | I don't have Nvidia hardware | 09:17:14 |
| K900 | So I can't help here | 09:17:19 |
