4 ms·
From the site: > This is currently in BETA. There are 8338 registered users on GamingOnLinux. These statistics are gathered using their manually entered data o
by mroche 8y ago
From the site:
>
This is currently in BETA. There are 8338 registered users on GamingOnLinux. These statistics are gathered using their manually entered data on their profiles. Please update your profile here to make this as accurate as possible.
> As with any survey, this won't be 100% accurate and should be taken with a pinch of salt.
8K users on a site about gaming. Doesn’t include RHEL/CentOS in its distribution chart. Way too myopic of a sample to even declare NVIDIA usage on Linux is dropping. For all we know it could be that new users are signing up that don’t have NVIDIA hardware, it doesn’t show a shift away from NVIDIA.
I know that your comment is about games, but over in the professional CG/VFX and AI/ML spaces, AMD is rarely touched. For both workstations and server racks.
- shmerl 8y agoI was talking about gaming. RHEL/CentOS are server distros, not gaming oriented by any means. Fedora is more like it in such cases, if you prefer that family of distros. > it doesn’t show a shift away from NVIDIA It does, as confirmed by many users who choose AMD for their next upgrades. Their choice of Nvidia was due to better performing drivers in the past, which is a non existent difference these days. So they choose to drop Nvidia and get AMD because of much better Linux integration (from kernel to the whole graphics stack and DEs), which is a consequence of AMD drivers being open. > but over in the professional CG/VFX and AI/ML spaces, AMD is rarely touched Not from what I've heard. AMD is better for GPGPU due to real asynchronous compute which Nvidia lacks. If anything, AMD hardware is more compute oriented, and Nvidia one is more gaming oriented. AMD plan to address it with their next architecture (so called "super-SIMD"). But compute hardware support is already good there. You might refer to CUDA lock-in, and some higher end libraries for AI being CUDA only. That's surely a problem, but not with hardware itself. AMD are working on addressing that as well (ROCm project).
- mroche 8y ago> RHEL/CentOS are server distros, not gaming oriented by any means. Fedora is more like it in such cases. That's why I ended by saying I know that parent comment and site was about gaming, but I wanted to add a bit of extra context. And these 'server' distros are the primary workstation hosts, both bare bones and PCoIP for pretty much the entire CG industry. > It does, as confirmed by many users who choose AMD for their next upgrades. It doesn't at all. This graph only shows a very generic view at best. If you wanted to see a shift, you would need a graph of users changing their profiles from NVIDIA hardware to AMD hardware and a separate graph of new users coming in with AMD gear. This is just a conglomerate of information in a single graph, there are way to many inferences that can be made that simultaneously can't be proven without more specific data. > Not from what I've heard. AMD is better for GPGPU due to real asynchronous compute which Nvidia lacks. If anything, AMD hardware is more compute oriented, and Nvidia one is more gaming oriented. Source? Working over in CG/VFX myself, NVIDIA is pretty much the only hardware to choose. For rendering, everything is CUDA based. Application support for AMD, not stellar. NVIDIA offers the most stable platform for our use cases so far. Release notes of software literally point out that AMD support is not as extensive as NVIDIA and subject to being unstable. > You might refer to CUDA lock-in, and some higher end libraries for AI being CUDA only. That's surely a problem, but not with hardware itself. There doesn't have to be a problem with the hardware, adoption will be zero as long as alternative OpenCL/Vulkan compute based libraries don't exist. I know there's been a long term project of getting OpenCL as an engine for TensorFlow, been a bit since I checked its progress. The OpenCL stack for AMD also doesn't have a stellar reputation for producing consistently competitive results. Phoronix released a strict OpenCL comparison adding the Radeon VII to the mix with ROCm 2.0 and as a developer, it wouldn't give me confidence that compared to CUDA I'm going to be getting the results I'm looking for. NVIDIA has a very mature stack and support with CUDA and its associated libraries. AMD is going to need to be able to supply that for people to ween themselves off of the green train. Granted for more AI based work, one might look towards the Instinct lineup. https://www.phoronix.com/scan.php?page=article&item=radeon-vii-linux&num=9 https://www.phoronix.com/scan.php?page=article&item=radeon-v...
- shmerl 8y ago> It doesn't at all. If you didn't follow this, it doesn't to you. It does, to those who pay attention and constantly see people switching to AMD and commenting about their reasons. And these reasons are quite obvious really. Nvidia did nothing to improve their integration with Linux (the meain issue is their unwillingness to upstream their kernel driver), while AMD did a lot to improve their drivers. It's only natural to expect Nvidia Linux gaming usage to continuously drop as a result of the above. > Source? https://www.techpowerup.com/215663/lack-of-async-compute-on-maxwell-makes-amd-gcn-better-prepared-for-directx-12 https://www.techpowerup.com/215663/lack-of-async-compute-on-... AMD hardware is known to be better for GPGPU for a long time already. > There doesn't have to be a problem with the hardware, adoption will be zero as long as alternative OpenCL/Vulkan compute based libraries don't exist. If developers are using some closed source libraries, they are at mercy of those vendors who might be in the pocket of Nvidia. And no one stops open source libraries from not being CUDA only and from using Vulkan and OpenCL for compute needs. Given Vulkan is still rather new, it can take time for libraries to pick it up though for compute scenarios. But it will happen either way. Overall, I don't see good future for CUDA, if it will remain Nvidia only. Same as with gaming, open solutions will catch up, and Nvidia lock-in will crumble.
- mroche 8y ago> If you didn't follow this, it doesn't to you. It does, to those who pay attention and constantly see people switching to AMD and commenting about their reasons. I'm talking about this purely from a data point of view. I'm referring to the graph, and it has too many holes to be used as a sweeping generalization about the market and Linux users as a whole. To be clear, I'm not arguing for or against NVIDIA/AMD. I'm just trying to point out the issues with using that graph as definitive evidence of anything. > Nvidia did nothing to improve their integration with Linux, while AMD did a lot to improve their drivers. And I applaud AMD for that. They've come a long way. However, (and this is personal opinion based off of experience), I don't see Wayland as being as a particularly massive reason. Wayland is what this thread is about anyways. There are still plenty of people using XOrg that are happy with that and don't run into any issues, myself included. That's not to say I don't support Wayland development and I hope NVIDIA never adds support for it in the future, but it's such a 'young' piece of tech that still requires some more maturing. > AMD hardware is known to be better for GPGPU for a long time already. Raw power is only a piece the pie. Some people take issue with that statement, but it's reality. To the point in your link, Pascal fixes the async problem present in Maxwell. https://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/9 https://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-... > And no one stops open source libraries from not being CUDA only and from using Vulkan and OpenCL for compute needs. And yet they primarily are CUDA only. It's a conscious and intentional decision by the developers of those libraries to start with CUDA and stick to it. And the community not adding OpenCL support shows that AMD hardware isn't even in the space for that application. I think that we could go back and forth with this, providing counter examples for each point the other brings up. I merely wanted to offer up an enterprise oriented view of the picture, when most people are looking at individual usage.