I think it's a combination of it's done to a degree and comfort + habit.
Let's say there are areas to improve still, but introducing anything new requires investment of time to learn it, breaking habits and giving discomfort. Even if it eventually starts paying off, it can cause a push back naturally. So it's really hard to do it right, may be only very gradually? Surely not like Gnome tried to do it.
Some direct comparison with such idea could be let's say a suboptimal keyboard layout and more optimal ones that are barely used.
I personally stick with KDE exactly because "it just works well enough" and its flexibility at the same time.
It just spins the CPU in the loop, stopping execution from progressing. Technically, whether this fully halts the system depends on what else is going on: you might need to fully disable interrupts before entering the loop to get a full halt. OTOH you can design your system so that everything happens in interrupts (with modern interrupt controllers the common wisdom of doing as little as possible in interrupts no longer applies and it can be a good way to get a predictable and low-latency system) and so you finish your setup code with an infinite loop to stop the CPU running off the end of your function when it's not executing one of the interrupts.
In a lot of cases, you might insert some 'wait-for-interrupt' type instruction in the loop that halts the CPU more 'cleanly' (and in a lower power mode), and usually this will appear as a side-effect and keep the behaviour defined. But this is not always desirable or possible.
Why? The point of a shader language is to define a function that outputs some graphics. Why should that not be portable between GPUs/CPUs of different vendors?
More generally any GPU computation, not necessarily graphics. The above argument could go that there is no point in high level languages for CPUs either and everyone should just always use assembly, which is obviously false. Same can go for GPUs.
I mean if you're worried about high performance compute on cpus, then the argument also applies. That's why there so much hand written assembler with dynamic dispatch on CPU features...
It's just that gpus have no general purpose usage .. for ai, it's basically all about perf.
Of course some cross platform stuff can be made for modest acceleration, but the state of the art is always going to be out of reach.
Nah, I don't buy it. There is room for assembly usage, yes, but the claim that it's the only way to do things is clearly false and compilers from high level languages in most cases are enough.
Because of how different the memory hierarchies and pipelines are and because if you're doing perf work, this is important enough to matter. For cpus and general purpose programs, it's not. For hpc, it is
AMD's Mesa drivers are better, but if you already have an Nvidia card then you can still use it just fine with Wayland.
The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.
I specifically bought an AMD card for my living room Steam box, and I've had way more driver issues with that computer than when it had an nVidia card (although there's also other software changes). Mostly: the audio hitches frequently when outputting via HDMI, and a many-year-old AMD driver bug where it will always prefer YUV to RGB when supported by the display with no kernel parameters or anything to override (this one is apparently finally getting fixed in 7.2 hopefully). That said, I've had some issues with the nVidia drivers too, and I much prefer open source ones, ceteris paribus.
Seconding this. I'm not happy with the fact that the drivers are proprietary, I really prefer FOSS. But, I am tired of having to deal with FUD around performance and issues with NVIDIA devices which simply don't exist at scale.
I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.
I'd say it's deserved, not FUD. Nvidia did improve in some ways, but it's still way too heavy into blob even in case you plan to use it in the future with nvk. Nouveau / nova developers explained that Nvidia pushed a lot more into their firmware than AMD, turning the kernel driver into more of a shim than an actual driver. That's already a big downside.
It's a tradeoff, and if you're not doing any fancy-pants CUDA work then it's a pretty big one. But most people are already using these blob-heavy drivers on Windows, so switching that same system to Linux is not a huge downgrade in terms of usability or stability. It isn't recommended for new Linux PCs, but it's not a dealbreaker for people switching OSes (anymore).
Yeah, this particular experiment doesn't reveal much because the Nvidia driver is a black box. We know in the past it used its "composition pipeline" in Wayland situations, and that was a particularly noticeable increase in latency. Plus, for a while the Nvidia driver also was stuck on software cursors. And even on the DRM path the big two compositors only updated input once every frame, which was the reason for it "to have much worse input lag."
edit: I should also point out the mouse acceleration curve, which if you don't fix it is different between X11 and Wayland compositors. That really messes up the "feel" of things.
Exactly. Let them sell games on GOG DRM-free. You buy it, it's yours as long as you back it up. No one stops you from storing it on any physical media you want. Just use an HDD.
When things on the other are presented as rent only, it's very bad.
Apple will never care about what users want, they only do what Apple want. If you want to free anything, don't use Apple. It's an obvious lesson that should have been learned a long time ago.
Let's say there are areas to improve still, but introducing anything new requires investment of time to learn it, breaking habits and giving discomfort. Even if it eventually starts paying off, it can cause a push back naturally. So it's really hard to do it right, may be only very gradually? Surely not like Gnome tried to do it.
Some direct comparison with such idea could be let's say a suboptimal keyboard layout and more optimal ones that are barely used.
I personally stick with KDE exactly because "it just works well enough" and its flexibility at the same time.
reply