Actually, I'd say Fedora is now about as straight forward as can be for Gaming + you get SeLinux which for new/ non tech users might prove useful sooner than later.
The one grief I have is they don't enable flathub by default, and most guides out there to get simple stuff running (spotify) sucks as they are clearly written by non fedora users. In many cases they recommend installing snap on Fedora which is completely dumb... Where you really just need to enable flathub/3rd party repos (Installer will ask you if you want to enable at first launch) and you are done. Steam is in the repos, latest nvidia drivers too.

Also, out of what I install for non tech users, pop os is better than ubuntu seems: I had colleagues complain about ubuntu snap taking ages to start, switched them to Pop OS, now they are fully happy. Thx to Pop OS for not being morons and use flatpak instead of outdated canonical only stuff... So I would really recommend dropping / phasing out Ubuntu now in recommendations, as Pop OS offers same simplicity, full compat for .deb packages (PPA) but much cleaner experience overall. Because you don't want new users waiting 2 minutes for their first app launch, it really gives them a bad impression in my experience. Especially to non tech users. And that's not what you want, you want first impression to be real good. Flatpak/ pure deb gives you that. You also get the automatic Tiler for gnome for more tech savvy users.

View this comment - View article - View full comments

Quoting: omer666

Quoting: 3zekiel

Quoting: omer666Quite disappointed to see all the Linux vendors still shipping Intel-powered laptops. :sad:

First, right now, there is no real supply for AMD see CPUs (see Tuxedo AMD laptops stocks). So it's Intel or nothing for now.
Second, Tiger lake is very cool, its graphics perf are real great (way better than AMD at least, and according to new AMD APUs spec, this will continue), and single core performance is good too. So why not sell both AMD and Intel ? If you need more parallel CPU power, AMD is better of course. But that is not the general case. Graphics is usually much more limiting for most "standard" workload like browsing or gaming. And Xe does allow you to game on an APU, which is insanely cool. On the opposite, if you need to do a lot of code compilation, hw simulation etc, then AMD is better. So, best is really to have the choice.
Third, Intel continues to be a massive contributor to Linux/Open Source so not biting the hand that feeds you might be a good idea.

I agree with you, what I meant is that almost all Linux laptops I see are on Intel CPUs, so there is almost no choice at the moment. Of course I'm still eyeing what Intel is doing, but at the moment I'd rather buy AMD.

Ah I misunderstood sorry, well the issue seems to be AMD not delivering to smaller manufacturer, those who ordered the Pulse (Tuxedo's AMD laptops) received a mail not long ago saying that AMD did not deliver anywhere near as much CPUs as what was promised to them ... Guess everyone has big stock issues, but is not a very correct behaviour from AMD. So I expect that's why you see mostly Intel still. Even in non Linux laptop, high end ones are still mostly Intel, probably for similar reasons. 7nm is crowded right now, so with their own fabs Intel does have an advantage here in term of supply, 10 nm "superfin" does perform well too.
But I agree, as far as work goes, AMD CPUs would also be better for me. Guess we have to wait. On personal, I will take Intel for light gaming, but I would prefer a magnesium chassis with a more prenium feel than this one... We're almost there Tuxedo, now, make an Infity book version of this laptop, without the graphics card, but with the same battery as 14" infinity book and Xe 25w TGP, and I'll pull the trigger.

View this comment - View article - View full comments

Quoting: omer666Quite disappointed to see all the Linux vendors still shipping Intel-powered laptops. :sad:

First, right now, there is no real supply for AMD see CPUs (see Tuxedo AMD laptops stocks). So it's Intel or nothing for now.
Second, Tiger lake is very cool, its graphics perf are real great (way better than AMD at least, and according to new AMD APUs spec, this will continue), and single core performance is good too. So why not sell both AMD and Intel ? If you need more parallel CPU power, AMD is better of course. But that is not the general case. Graphics is usually much more limiting for most "standard" workload like browsing or gaming. And Xe does allow you to game on an APU, which is insanely cool. On the opposite, if you need to do a lot of code compilation, hw simulation etc, then AMD is better. So, best is really to have the choice.
Third, Intel continues to be a massive contributor to Linux/Open Source so not biting the hand that feeds you might be a good idea.

View this comment - View article - View full comments

Quoting: Perkeleen_Vittupää

Quoting: rea98714" and Nvidia GPU, nope... IF only it has AMD GPU and 15"...

That's right! AMD or nothing nowadays! Nvidia driver updates seldom break the system. Why can't they just open these bloody drivers up and let the community make em gold for Linux?
Nevertheless: Nouveau is now getting somewhere :heart:

Ah I wish they would open them. They opened for their embedded ones, maybe with a bit of pressure from Intel/AMD (they will be the only closed source option at the end of 2021) they will finally open their kernel/vk drivers. It's sad too, tech wise, I'm all Nvidia, many of what they do on that aspect is awesome.
But, just opening kernel + vulkan driver would not kill them. You can still hide all the secret sauce in fw + cuda framework, vulkan driver itself is really not a big secret I think. Power management and co either. As for DLSS, AMD pose no threat since they don't have the basics to exploit it, but it's true I would be afraid of Intel probably more versatile graphic cores, so I understand they want to keep it closed. But still, I wish they would open up a bit more on that too, a bit of doc, all headers etc. And at least contribute to Proton for it.

Quoting: Alm8881,45 kg

Not quite "light". :(

Is not bad when you factor the graphics card.

Only thing I still don't quite get, why not use magnesium chassis, which is their signature I'd say, more ? Instead of using plastic ... I'm more disapointed by that.
Still waiting on 15" infinity book to pull the trigger, if you want to make me happy Tuxedo Santa: 25w TGP for XE and full dual channel (non soldered) would make me very happy. Magnesium and less than 1,4 would be golden.

View this comment - View article - View full comments

Quoting: x_wingHow many games I can play with DLSS or RT on Linux? Truth is that we are on Linux and those are pointless features for now. IMO, right now this technologies have the same weight as Physx had in the past.

For RT, it is most likely coming soon, see the movements from Khronos on vulkan RT API (which is literally tailored for dxvk/vkd3d use). So RT definitely matters, unless you are completely against proton of course.

For DLSS, who knows ... Hope it comes, maybe yes, maybe no. Nvidia did release the headers for some of that but not all, the sdk itself is under NDA. Guess it's in Valve's hands to unlock the situation now, I don't see what anyone else can do. Unless Stadia goes Nvidia for next round, that would help a lot.

View this comment - View article - View full comments

Quoting: slaapliedjeYeah, I think what it really comes down to is there isn't a stable driver model for graphics cards in general. Not even Linux specific, as graphics drivers are for sure the one thing across platforms (except the Mac, which meh) which are constantly having updates. Whether they are new features being added, new support for the next graphics cards, or even just fixing performance in games / applications.

This really is the cause of most of the problems with Linux, as the update mechanisms for drivers aren't really a 'thing' when they are all in the kernel. This is why dkms was created, so it could dynamically rebuild new drivers when kernel updates happened. It shouldn't be the other way where you need a whole new kernel version just to support the new hardware. Should be able to dynamically build a kernel module for your existing kernel. Needing extra libraries to be pulled from git, or compiling your own kernel off of kernel.org is so... 1999.

The random code drops by AMD completely explains why we're in this situation. But for now, the AMD vs nvidia decision may end up being simply accessibility to the cards. Seems both are sold out everywhere, but for AMD it's because they're selling so many chips to Sony and Microsoft for consoles, where nvidia is selling theirs to crypto-miners. So kind of a moot point!

Ah yes, driver update issue is a bit of a mess. That being said, kernel code has no real reason to change dramatically once stabilized for this kind of devices. It really is just a bridge to talk with dma stuff and firmware, you might have some bugs to solve at first, but then... Also, for bug/security, point releases should be enough. DKMS/akmods may still help if needed.
I expect issues will mostly happen at mesa level, which is still an open issue. And for this well, I guess no silver bullets, having a separate vulkan package should be much much easier than opengl, so it might be the solution with time, just a separate lib to update. But for opengl, no idea... Since it has so many deps, and is depended upon by so many things.
I think many distro need to change a bit how they work too. I have to deal with Centos for proprietary stuff in particular, and it is a freaking pain in the ass. At some point, compiler is so old (on centos 7) that you can't get anything modern to work (even autoconf and co are too old, I'm not sure how the hell this can happen). Supporting OSes for 10 years encourage very bad behaviour for devs. At least, there should be *some* level of updates (jumping from lts kernel to lts kernel after few point release each times would be a good middle point as an example).
It also causes security issues, since using some sw such as gnome/firefox in old version, even pseudo extended support releases can go bad easily (less coverage because not many users, so researchers do not test, so basically only hackers test ...).

But well, some level of issues will remain with current model. Vulkan is a good occasion to solve it, by making something more minimal, with less dependencies that could actually be updated regularly. Also, with its virtual lib system, it would be easy to have multiple version live together, like our Python friend.

As for chip availability, yeah ... I think waiting for Intel will not be hard, since we will not have any chips from Nvidia/AMD either before either :) Scalpers, miners (on both side from rumours I heard) and Sony/Microsoft, and most probably selling pro cards for Nvidia which is crazy margin and probably comes first.

View this comment - View article - View full comments

Quoting: slaapliedjeNow maybe if Intel does something amazing with their dedicated GPUs, and makes the drivers compatible, then there'll be a better experience. But even then you'd still be tied to newer Mesa drivers, which is usually the sore point to the AMD ones.

For the latest Mesa part, this is also an issue of AMD working in "code drops" mode. Which is the typical Silicon's company vision of open source. Every now and then, you drop code. Result is, most often you end up with not well tested code in releases that themselves often come late.
Since Intel works upstream and enable hw much earlier, and usually long before hw availability, you end up with smthg much more robust. Well, not to say you will never have to go to next major version, but it should be much much less frequent, and git should be an absolute rarity thx to that. Next major version is a lesser evil at least, and you can often find semi official ways to get it. It's also included in HWE for ubuntu, and base for Fedora. For centos, well, that will still be a pain for sure. But at least, launch drivers support should be better if you fall on the right release time (that's centos for you ;p ).

View this comment - View article - View full comments

Quoting: x_wing

Quoting: CybolicBased purely on anecdotal observation, I suspect it's because there's been many HOWTO guides for NVIDIA drivers written by "mainstream" news sites and its often mentioned in Youtube videos, whereas I have yet to see anyone mention how to set things up with AMD.

It's probable, but that doesn't justify the common idea that Nvidia gives better support for driver installation. IMO, there is a big bias going on regarding AMD drivers.

It's true I really wasn't clear, sorry for that.
Yes, my statement is really on the end user usability, what Nvidia themselves provides also suck. I said in message before, but for me Nvidia is not a wonderland either, and company wise I'm not a very huge fan. For AMD, I am not more of a fan, as I don't consider them open (they just code drop ...), although they at least give doc. They also lock firmwares who have full dma access, so advanages are not a lot ... The rest is really observation from end user usability. I have view on centos/Fedora and ubuntu where overall Nvidia gave less problems (did not say "no problem") on my experience, either personal or when supporting colleagues. It might be thanks to distro, but I don't really care, I just care for end result.

There is always the wayland arguments, but having no special use for wayland, that does not really concern me. I mean, I did make it work too, just did not have much point. I run wayland mostly for xrun setup with Nvidia, so that Intel card does not clash with Nvidia's xorg + openbox env. It does require multi cable, so it is not ideal either ... Once again, never said is perfect. But it does work, and setup is easy to find / use.
For AMD, can't say the same. I had issues on issues, work & home. And from what I read here and there, can't say I'm alone.

And it is easier to get latest Nvidia than AMD on my distros. It's most likely not thx to Nvidia, but it's what happens. As for failures after new kernel, well, since it's tested by distro maintainers I guess (is their own packages), that's why it never breaks for me.

As for dkms on debian, it is indeed a special case of where it should tend to work, since you have a fully stabilized kernel, albeit I doubt you'd run anything where you need latest driver (there's no official support for autodesk/tensorflow and co there, and using a distro with very old packages is sub obtimal for gaming). I did use on centos before for a ML guy, was a case where it did not break also, stable kernel and all that. On Ubuntu, using website dkms was painful, very painful (with hw enablement stack).

Once again, I agree, neither are actually a walk in the parc in all occasions. AMD requires to go and pull git stuff, Nvidia you have to go back to old gcc for their nvcc stuff, but you have scl to help you. Which is really the point on usability, whether Nvidia does smthg themselves or not, since they are the main vendor, people adapt ... And there are a lot of stuff to workaround their stuff, often out of the box or easily ... That's just the way it is.

On pure Gaming, as long as you don't want the very latest proton, it should be fine. But my fear is you still get hangs, APUs that do not even let you boot ... all this kind of fun stuff. Stuff, that basically never happened to me with Nvidia. Worst you have there is nvcc yelling on you to give him an older compiler, which since you can still boot in normal env is not so hard. Overall, this has been the issues I faced and my work experience, and not just on my machines. I also agree my use is not casual, and I might push into more issues than standard gamer obviously, but the APU not booting as an example ...

Maybe things are changing, but for now, I still would not recommend to someone who ask me to go AMD for GPUs on Linux. Once AMD start to work upstream correctly, enabling hw support much earlier in the flow, and stop doing code drops maybe things will change. Until then, I put them in same category as Nvidia, and only judge on factual present usability.
I would also precise, if using older AMD card, then it is probably a different story, after one year it's true my wife's issues reduced dramatically. But, that's a long time to stabilize stuff. And I have no doubt it's not just their fault once again, but results are what matters - albeit, once again they should enable hw much earlier...

I'm really betting on Intel more than them. Most likely, even if Intel card are not quite as powerful / a bit costlier, and unless they really crap out, this is what I will hopefully soon recommend. I think they have the weight to use OneAPI with fpga and co too to shake up CUDA monopoly too, which would be a blessing. And since they enable hw support long before, you're in for a much smoother ride. Once again, full featured consumer hw, stability, and very upstream flow is the right way to go, and it deserves my money. Is the same reason I still buy Intel CPU, even tho AMD ones are objectively getting better, Intel is a large contributor.

View this comment - View article - View full comments

Quoting: x_wing

Quoting: PJHonestly - I don't even know what you're talking about. I know just one thing - with Nvidia regular desktop user has OpenGL / Vulkan / CUDA / OpenCL working well out of the box (and sadly no Wayland). With Amd I don't - I need to install AMDGPUPRO.

What I mentioned is the steps you have to do in order to get "good OpenCL" running in your system. Depending on your distro, you may or may not get the packages from the repo. But still, is quite simple to install using AMD packages.

Quoting: PJWhen I'm talking about mesa opengl is not good for creatives I mean it regularly fails in professional creative apps (Maya, Modo, Substance, Resolve etc). Often those apps don't work at all (with Modo I've been able to report mesa related issues and Modo was tweaked to work with it). Also when I've used amd mesa drivers it was the only time I've encountered hard lockups on Linux.

As I don't use those type applications, I cannot give an answer regarding of which could be the problem there. But, once again, for OpenCL the AMDGPU-PRO drivers work perfectly fine.

Quoting: PJI agree it shouldn't. But if you're creative it is. If you read my post you'll notice that I've specifically pointed out if you're a regular desktop user and a gamer mesa can be enough.
But if you're getting our of that comfort zone more than often it isn't.
I've managed a workstation with AMDGPU-PRO and I'm just reporting my findings. More than often after a kernel update I had to fix my box by reinstalling the driver. I get it that there may be a way to set it up better, so those won't break that easily / will get rebuilt. But that requires knowledge and setup that a creative / regular user shouldn't have to have. It's really not a way to expand linux user base.

It requires the same knowledge as with Nvidia. Both proprietary drivers ships their kernel modules using DKMS (with AMD not requiring a blob binary) so the risk to getting a broken system after a kernel update is exactly the same on both, with the difference that even if your DKMS build/installation process fails on a kernel update on your AMD system you will probably still be getting a working system if the builtin kernel drivers are new good enough for your GPU.

Either way, in both cases the best thing to do is to use a LTS kernel version as long as you can.

Quoting: PJI mean repos for distros like Ubuntu , OpenSUSE etc... And I don't care whether they're maintained by Nvidia or other organization. I'm just saying that from an average Joe perspective those are easier to handle. You enable the repo and you stop worrying about the driver - and again that it my experience, haven't had any major Nvidia driver related isssues for years.

AFAIK, those repos are maintained by the community, just like the community also have special repositories for the latest stable or bleeding edge versions of Mesa. If the average Joe knows how to install the latest Nvidia driver on a distro, he should also be able to keep to date the AMD counter part as it will require exactly the same steps.

I really fail to understand why so many Nvidia users says that AMD driver support is inferior when they are actually providing the type of solution as Nvidia and more.

I think what you fail to see is that Nvidia drivers are integrated, as latest version, in most distros. Most of the time with akmods or equivalent, which means you never have to deal with DKMS and reboot issues you talk about.
For AMD, when the kernel is okay (so, not when new card, new/latest Vulkan support etc), same for Mesa, which is locked to 3 month release cycle. As such, for nvidia, when a new release come out I just have to time "sudo dnf update"/ or "update"tickbox in sw and I am done. It's official repo, not third party. It requires literally 0 knowledge.
With AMD, you need to go the road of git kernel/ git Mesa with third party or self tinker. And upgrading kernel outside of distro cycle can/will cause issues at one point or another... As such, Nvidia way is usually more safe.
As you said, AMD provides also a dkms, but dkms is just bad, it fails at each new kernel release and is an absolute horror. Whereas, while it's true that Nvidia provides dkms on their website, it is thankfully not what is provided by distros - and surprise, never had issues with akmods, defo had with dkms. Also, for AMD is rarely just kernel/dkms, is also mesa git etc, which exposes you to even more issues.
For nvidia, at most, you just pull the rpm for Nvidia driver, and change the wget url if you need absolutely immediately, or you just wait tomorrow when it will be released in distro.

Now, once again, Nvidia is not perfect either, esp on compute side. But on gaming, it is click and play. New card support is day one/two, without tinker, without forceful updates etc.
As for the creatives/ML guys, Nvidia is defo the simplest road, by far and large. Support is once again basically out of the box, and you get CUDA which is often a hard requirements + the tensor cores of course. With AMD, you once again go the tinker road, and forget CUDA.

View this comment - View article - View full comments

Quoting: furaxhornyx

Quoting: 3zekielTo be perfectly fair, neither nvidia(mostly with cuda stuff, never for gaming to be fair) nor amd give the hassle free/clean road so far, both have their catch.

I am thinking the same, from what I have read here and there (I am curious about Intel stuff though...)

For Intel, for me is both experience at home/work + features. The one that is really a killer feature for me is GVT-g (Intel's hw accelerated GPU virtualisation). Now, new Ampere cards support SRV-IO, Nvidia's equivalent, but it is not enabled by default ..... so that's the bad part about proprietary drivers .... And AMD kills the feature at hw level (if the company has bad behaviour, making open source code drop from time to time will not help either...).

Main difference with Intel also, is that they are really open source, in the sense that they dev everything upstream (with Qemu/Xem devs for virtualisation, in mesa for vulkan), while AMD mainly makes code drops (AMDLVK stuff) and then let the comunity make smthg usable out of it (RADV). So the result is overall better code quality.

Now they just need a powerful dgpu ... But the architecture of this dpgu seems actually pretty cool, so hopefully they make it good, wait and see now.

View this comment - View article - View full comments