This is your once a month reminder to make sure your PC information is correct on your user profiles. A fresh batch of statistics is generated on the 1st of each month.
You need to be logged in to see when you last updated your PC info!
You can see the statistics any time on this page.
While we don't currently have a drop-off implemented for old/stale data, it will be implemented next year. If you want to make sure you're included at any time, clicking update without any changes will update the last time you edited them. The drop-off for old data will be done in months, since people aren't likely to change hardware that often.
Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Patreon
PayPal
I can only repeat myself: I'm not experiencing what you're talking about. And I'm not talking about some obscure future, but present and past years. I don't have tearing in Unity games (and I didn't change driver buffering optiond), neither met the other things you mentioned. What am I doing wrong...?
Good for you. I had constant tearing, and the worst in Unity games (my previous card was GTX 680). That's completely gone since I switched to AMD / Mesa.
Last edited by Shmerl on 27 December 2017 at 9:38 pm UTC
Yeah, that was before AMD bought ATI.
Yeah exist cemu in lastest versions
View video on youtube.com
Sadly amd dont have opengl 4.6 for now
^_^
That's incorrect. It has these:
GL_ARB_indirect_parametersGL_ARB_pipeline_statistics_query
GL_ARB_polygon_offset_clamp
GL_ARB_shader_atomic_counter_ops
GL_ARB_shader_draw_parameters
GL_ARB_shader_group_vote
GL_ARB_texture_filter_anisotropic
GL_ARB_transform_feedback_overflow_query
GL_KHR_no_error
What's missing are these:
GL_ARB_gl_spirvGL_ARB_spirv_extensions
Is Cemu using these two? I really doubt it does.
Last edited by Shmerl on 27 December 2017 at 10:22 pm UTC
How to get nVidia to 'just work'
1) use a good distribution that actually knows how to package things and include them in the distribution (pretty much any Debian based one)
2) install the nvidia-driver package, which pretty much installs all the needed bits, including nvidia-kernel-dkms.
3) enjoy not having to ever recompile the driver. When you upgrade it, DKMS recompiles it for you, reboot into new kernel and you're good to go.
I haven't had any crashing/freezing due to the nvidia driver that wasn't caused by a particular game in YEARS. In fact I think the last time I had my Linux box lock up was due to playing around with a beta of SteamVR that decided to go a bit funky.
Reason I stopped using AMD is because they'd deprecate support in their closed source driver way quicker on older cards than nVidia does, and the open source driver was never up to the same performance. That and there are what, like 5 different drivers now?
Plus there was a time (I haven't checked lately) when their catalyst driver wouldn't work with the newer xorg or kernels for 8 months. Maybe the open source drivers are much better performance wise now, but they have been historically pretty crap.
Edit: Also, even with the open source stuff, you have to try and get latest Mesa on your system, and that's generally a pretty major thing to do on many of the binary distributions (not so bad on something like Arch.)
Last edited by slaapliedje on 27 December 2017 at 10:25 pm UTC
It's only as major as you are not yet familiar with building Mesa from source. Once you learn that, it's noting major, just compilation time. One thing many are missing that there is no need to replace system Mesa to use the latest one for running some games. You can use system packaged one for everything else, and use your custom built one for launching games that need the newest features. That's exactly what I do, so I don't need any package repositories for that and can build Mesa any time I feel like doing it.
Sure, building stuff from source might sound intimidating, but it's just some learning curve, nothing insurmountable.
Last edited by Shmerl on 27 December 2017 at 10:30 pm UTC
I personally disagree. It's much harder to build Mesa from source on a distro like Ubuntu or openSUSE than Arch or Gentoo. Thankfully, you can get around this by using PPAs/ "1 click installers" which can provide binary versions of mesa git.
Yeah, I personally have no problems with compiling things and passing parameters to use the non-system installed stuff, but the typical Ubuntu users are used to the PPAs, which in my experience is fine if you use one or two, but once you start using a bunch of different ones you end up with an unstable mess. The same reason why pre-rpmfusion, Fedora and CentOS/RHEL became broken messes if you tried to use the various repos for decent desktop support.
Anyhow, there are definite advantages to either nvidia or AMD. AMD is on the right track though, and nVidia seems to want to be friendly toward the FOSS people, but they also have the bottom line of their Quadro vs Geforce cards. Does AMD even have the firegl drivers anymore?
How exactly is it harder? Check how official distro packages configure and build Mesa, and use that as a starting point.
And in this case, I don't need PPAs and binary click installers, because I don't want to replace system Mesa with a manually built one, especially if it's a master branch. I need to use them in parallel.
Last edited by Shmerl on 28 December 2017 at 4:31 am UTC
Those were the reasons I switched a few years back; the closed source driver was never very good. The open source driver has improved by leaps and bounds the last couple years, and I was quite happy when AMD announced they were moving to the hybrid model (crappy proprietary modules for those who really want/need them, but all will [eventually] run on top of the open source bits).
As others have mentioned, the power consumption / performance ratio is a bit behind on the hardware side; we'll see how the next generation from both vendors compares. At least AMD is much more competitive than previously, for both GPUs and CPUs!
Other than Tegra, it's been mostly lip service... don't forget they used to have a (heavily obfuscated) open source nv driver, which they completely abandoned.
fglrx is called Catalyst now (the driver package was never separate). I don't think they ever really figured out how to compete with the Quadro line; they were also trying out "FireHD" for a while, targeting "high-end" multi-display users - the same market Matrox was trying to sell into at the end of their run...
I started Linux gaming when I had a GTX 660 and now I'm using a 780. The only games where I remember heavy screen tearing were the Shadowrun games. I had to fiddle with driver settings there. All Unity games were fine I think.
I know they renamed the fglrx ones to catalyst, The FireGL drivers were their PRO drivers (though honestly I can't recall if they dropped those as far back as when AMD bought ATI or not).
Looks like they're here;
http://support.amd.com/en-us/kb-articles/Pages/Workstation-Graphics-Drivers.aspx
I used to LOVE the Matrox cards, they just couldn't compete with the 3D side of things, but still did the best dual-head and triple-head displays. I think their downfall was that they didn't patent that, because I'm fairly certain they were the first ones to come out with single cards that were capable of it. Apparently they now have a card that handle up to 9 displays at 1920x1200.
Last edited by slaapliedje on 28 December 2017 at 3:50 pm UTC
Ha, I actually bought G-Sync displays, and yes it's supported in Linux.
I don't see why people feel like there are too many radeon drivers compared to nvidia. There is mesa for opengl, radv for vulkan and their blob, of which the vulkan part has been opened lately. So that's 3 drivers.
On the other side, i see 2 variants for the vulkan driver, a couple of packages mostly matching the same parts fglrx has, and noveau. Counted the same way, it is also three drivers.
That's about the same amount for me. Also, i have a 5-6 year old APU at this point, which is/was still supported by their blob.
I think you are mixing up kernel driver (radeon / amdgpu), and API implementations (radeonsi/r600 for OpenGL, radv/amdvlk for Vulkan and etc.). Having different names is quite reasonable, if they have actually different code for different hardware, or simply different implementations.
For starters, Gentoo includes git versions of all packages in its repos so no need to git clone, ./configure, make, make install anything manually. Arch does something similar with its aur.
More importantly though, when you build a package from source using a git repository as the source on Arch that package is tracked by your package manager and can be updated along with the rest of your system (pacaur -Syu --devel). As far as I know, Debian and variants lets you build a package from source, but doesn't automatically keep it up to date. If you install Mesa git but never update it it will quickly fall behind the fixed release version.
Last edited by natis1 on 28 December 2017 at 9:55 pm UTC
I see. But all those methods install Mesa as a replacement for stable one. That's not the goal for me in this case. I like to have experimental / master Mesa alongside stable one, and only use it on demand when needed. So in such case building it and placing it in custom location works best.
Here is an example how to do it: https://www.gamingonlinux.com/wiki/Building_Mesa_from_source