Yep... Damn Nvidia, at least their drivers work* at launch unlike other companies... (looking at you AMD)
well, they also take days to weeks to properly work when nvidia releases a completely new architecture. And the only way they reach that is by shi******* on everything that linux is and doing proprietary only where they are the only ones that can release things and you depend on nvidia to do that at all.
That is also the reason why they don't play well with newer kernel versions from time to time and every DE needs nvidia-specific workarounds.
AMD is doing it completely the linux way, but that means they are also bound to kernel- and mesa release schedules, which are really slow. (Kernels take 3 months from commit begin to release, mesa takes about 4-5 months between commit start and release) - seeing that amount of time, AMD does an amazing job.
And: The necessary commits by AMD are available in the git repo's at release all the time for self-builders, so theoretically, you CAN use every AMD card on launch day. You just need to wait for kernel- and mesa releases to have it working without further ado.
Don't wanna get too off topic here, but it took 4 months from release for me to be able to use my 5700 XT at all, I did try their repo for kernels and mesa git but it was a terrible experience. The reason it was such a bad experience was not because of release schedules, but because their drivers were crap at launch. Don't get me wrong I didn't refund my 5700 XT because I love what AMD is doing, but their drivers are crap at launch, even on Windows.
I wonder why michael over at phoronix was able to benchmark it competitively from day one on then. Seems like you used the wrong git repo's or the wrong commits.
And those problems are also part of the release cycle's of core linux components. You simply don't know how the product will look like with 100% certainty until 2-3 months before the release, and you also don't know what third-party resellers will change (yes, they change stuff) - that is stuff that you need to take care of in the next release cycle, meaning at least 4 months later than you originally intended.
The Windows driver was working flawless here when I tested the 5700XT. It had physical (size) issues with my case, that was the only reason why I returned it.
You clearly have not been paying attention to the Navi community in the past months, this has been an issue with almost everyone with a 5700 XT, just because he was able to benchmark it does not mean it was a stable experience. Sure I was able to run the 5700 XT but it was very unstable. Constant hangs, corruption in games etc.
Windows also had issues (not nearly as bad though) with dual monitors and freesync.
the amount of stupidity on the internet is endless. And in my experience, it even multiplies in communities. I followed some of those, the solutions were posted sometimes in them, but they were almost always completely ignored.
you CAN'T benchmark unstable cards. he simply used the correct commits. The one's that the "community" was not able to find.
What magical commits did he use? I tried the branches the AMD driver developers recommended and I still had the same issues.
Ignored is the wrong word here, a lot of solutions did not work for a lot of people, and probably already tried them.
We're way off topic here... the mods are gonna get mad... If you wanna discuss this then maybe the chat
Those updates today were a matter of no pain, only gain.
I don't know because he did not share
Because they didn't understand how those git versions work.
The packagers and daily rebuilders, for example in the mesa-git arch repo always use "head of tree" in their build scripts. Because they are in-development versions, on busy day's what you get with that approach can change almost every minute. And that means that also new bugs can appear every minute.
The key is finding a version (represented by a specific commit) that works on your hardware without triggering unfixed bugs and when you found that, stick with that version until you find a version that works better. You can rebuild that specific version against your other packages but you should not resync with the git repo unless you need a newer version because you encountered another bug that is fixed there.
What the people in those communities did, was either rely on precompiled packages in repositorys that are updated daily or use head-of-tree buildscripts on their own.
That means that the solution that someone posted as working 3 hours ago was really working, but the guy using head of tree 3 hours or a day later already got another version that did not work anymore.
In the case of the Navi card's the problem was that you needed the right firmware package (which was the easiest one because that does not change often) and to find the right kernel-, mesa- and llvm commit. Idealy, everyone should have build their own packages with fixed-version buildscripts instead of head-of-tree scripts or at least post their hardware- and software-details together with the commit-version that worked for them.
No real issues for me, but I did need to
systemctl reboot, as the Application Launcher > Leave > Restart sequence seemed to do nothing for me.
state of nouveau in december 2019
This off-topic discussion should probably be moved.
Do you want ants? Because this is how you get ants...er...flamewars...
Nvidia and Intel have historically had better launch-day support for their hardware on Linux than AMD, but they've also had more resources to throw at ensuring that support is there.
Michael on Phoronix as of Nov 20th:
He had benchmarks of the 5700 XT from before that (while it was still freezing). Doesn't seem like he used special commits, just the latest code from source:
Personally, I cannot in good faith recommend current gen AMD hardware to people looking to build a new main system. I normally recommend at least 1 generation behind the newest so that most of the bugs have been worked out. At this time, performance is a higher priority for AMD than stability (so they can beat competition in benchmarks). Hopefully AMD will be able to spend more time on launch-day stability as they gain marketshare.
in virtual box no desktop. running host on 18.1.4 must be host versus guest modules
The only issue that remains on my KDE system is the one with akonadi / apparmor. It can be circumvented as described in this post.
Besides some hate you have against AMD, I had to wait 8 months to be able to fully use the embedded GPU of my Ryzen3 2200G, last year. But it worked flawlessly for all 2019.
Don't blame AMD developers when xorg and kernel ones are guilty too.
if i were still on windows i'd be using ati after seeing their last few drivers and software suite for windows. ati one drive for it's cards nividia 2 drivers for their cards instead of putting them in the same package and letting you select from there.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.