| >We rely on proprietary technology because the open desktop and libraries and GPU drivers disregarded backwards compatibility Interesting angle to take it. Maybe the desktop and libraries have some core compatibility issues to resolve, but GPU drivers are ultimately working off what GPU manufacturers give to them. And it's unfortunate because 1. the GPU is a very important aspect, but also one closed down by nature. 2. Unlike the CPU (which is also closed down, and can have its own issues), GPU software especially sucks, even on Windows. You ever see updates like "fix issue with Overwatch"? Yeah, it is easier for Blizzard to call up Nvidia and fix their drivers specifically for their game than to fix whatever core issue made Blizzard struggle And as such it's no coincidence that many of the portability issues that come up with Linux happen to be related to shader issues. I'm being a bit unfair here given that I just established that the GPU is more important for games (so of course you'll uncover more and nastier bugs), but it's some food for thought on a major chip that may spread into software not choosing to support Linux. ---- Getting of my tangent: > I would say this is a completely self-inflicted issue in Linux world. To some extent, yes. But it is mostly an issue of support, and Windows has better support when similar issues arise. Ideally, a developer shouldn't need to rely on an outdated dependency that requires 15yo hardware and should be able to deploy to most major pacmans (a whole other rant, but I've talked enough). I'd say those challenges are hard to resolve, but not as hard as the effort of ensuring an entire proprietary runtime works on a different OS. > Win32 is the only truly backwards compatible API on Linux. for now, sure. |