| 9 Apr 2026 |
 K900 | But we also have the Valve kernel which has had these patches for a long itme | 14:19:52 |
 niklaskorz | interesting, thx! | 14:21:56 |
 anji | VRAM management is definitely something Windows does better. Its vidmm component does a pretty good job keeping the most important allocations in VRAM and evicting everything else if needed. I don't understand the Linux GPU architecture but it would be cool if it had a similar vendor-neutral component to manage system wide allocations.. | 14:46:39 |
 magic_rb | Does nvidia share this problem? Id guess not | 14:56:43 |
| K900 | It does | 15:37:57 |
| K900 | That's what dmemcg is | 15:37:57 |
| K900 | NVIDIA IIRC never evicts VRAM | 15:38:06 |
| K900 | *nvidia proprietary | 15:38:09 |
| magic_rb | Ah thats a bit, weird? | 15:44:36 |
| magic_rb | Ig on my laptop idc since i have an igpu, but on desktop that sounds rough | 15:44:55 |
| magic_rb | As the blog said, chromiums competing with cyberpunk is not great | 15:45:17 |
| K900 | I think it's an EXPORTSYMBOLGPL thing | 15:46:22 |
| K900 | (again) | 15:46:23 |
| magic_rb | With nvidia open that is no longer a concern tho | 15:47:23 |
| magic_rb | Or are you specifically talking about nvidia proprietary closed? | 15:47:38 |
| anji | Ah, so it now can change resource residency on the system level? Is that a recent development (as the blog alludes to)? I've only known it to be mostly a QOS/limiting thing. If it's using cgroups then it's still not quite as sophisticated, as vidmm can do per-allocation heuristics even inside processes. | 15:53:27 |
| K900 | The kernel can already do per-allocation heuristics | 15:53:53 |
| K900 | And does so | 15:53:55 |
| K900 | dmemcg is a way for applications to communicate priority | 15:54:06 |
| 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 |
