Yeah it is~ ^^
+Installs Linux, this time determined to make it daily driver. Why is this so slow though?
- You need to install Nvidia drivers
+ Oh, OK makes sense.
-- INSTALLS NVIDIA DRIVERS --
-- LINUX NO LONGER BOOTS, OBSCURE ERROR MESSAGE, FURIOUSLY GOOGLING ON A TINY PHONE SCREEN TRYING TO RESOLVE THE ISSUE --
Later made myself a Hackintosh, eventually bought an actual Mac. The Hackintosh stuff was much, much more stable than anything Nvidia ever released when I was trying to use Linux. Installing patched kext files, trying make MacOS run at full resolution and with smooth animations on unsupported hardware was much less pain than dealing with official Nvidia drives on Linux.
It's sad to hear that graphics drivers are still not a solved problem on Linux.
They are, Intel and AMD have shown that it can be done and it can be done excellently. NVIDIA just decided they do not want to be part of the solution.
Ever since, I have only bought CPU-integrated graphics (an Intel desktop and an AMD laptop for my cousin). Proud to say I have never sponsored the mandatory signed firmware devices.
The difference is that free drivers don't have access to changing the GPU frequency in newer cards. Newer means anything above NV110, that is, 900-series.
I don't know about Minecraft, but Minetest runs well for me on Nouveau, on a 7-year old i7 with a GTX 850M.
I tried RimWorld and Factorio, but they were unplayable due to I believe missing OpenGL features.
I have not tried Cities: Skylines.
It's still not as egregious as Nvidia's though, which is specifically designed as a defeat device to frustrate the use of third-party drivers. You at least don't need ME/PSP access to boot into a Free OS.
[0] ME/PSP are technically separate processors, but they have full control over the x86 cores. Their firmware can be minimized but they are integral to the boot process and enforce code signing on the BIOS. Speaking of, the BIOS gets to load into SMM, which has been around since the 386 and runs above both ring 0 and hypervisors.
It’s really interesting to see the difference between Linux and FreeBSD (which doesn’t break kernel APIs for shit and giggles). The damn Nvidia kernel module is still a bloated closed source blob, but not once in >10 years did it break. The largest problems I had with this driver under FreeBSD was after the adoption of KMS because Linux locked away the new memory management API required for efficient tearing free frame swapping behind GPL only macros resulting in massive tearing (there were workarounds like using a vsync enabled compositor adding latency and wasting enough power to cost me 30-60 min battery runtime).
This is not a Linux (or BSD) problem but purely a Nvidia Issue. After my last issue with an embedded Nvidia GPU in my motherboard (~10 years ago), I stay far away from Nvidia, I will never but anything remotely associated with Nvidia until they Open Source their drivers. I knew someone who worked there as an engineer and told him that, he just smiled with me knowing I knew it is really beyond his control.
This is 2022, we should be well beyond the point of worrying about Video Hardware in Linux/BSD.
When I used it, ironically, NVidia was the way to go on Linux and ATI/AMD was a shit show. Is AMD ok nowadays ? My needs are mostly confortable casual gaming where I don’t care having more than 60fps and I don’t play online (so this anti cheats situation doesn’t really bother me other than ideological issues).
The only complaint I had with NVidia was that a long time ago I had one of the first consumer-grade 4k displays, and it exposed itself as 2 1920x2160 displays. That all worked ... "great". X thought the monitor was two displays, and so anything that cares about the calculation of display boundaries (say, full screen video), didn't work correctly; it would just show on half the monitor. One day I found that a config parsing bug could cause the xrandr extension to be disabled while keeping everything else working, and then full screen worked. (The options to just lie to xrandr or disable it were of course broken, which is why bugs interacting with bugs was the fix. They never fixed the bugs or the bugged bugs, so shrug I guess.) It took me months of pulling out my hair to find that workaround, and having used X since before xrandr was invented it drove me crazy. In a past life, I also pulled out all my hair to get xrandr to work. It never fucking worked. And then the one time you don't want it to work, it works and can't be made not to work. Argh!!! Just send me back to 2000 please!
(Since then I've switched to Windows, and I still have that monitor. It works perfectly under Windows. You wouldn't even know that it uses the hacky Displayport MST stuff. Probably have a nice hack hard-coded right into the driver, and if it doesn't activate for some reason, you're completely screwed.)
I've heard AMD's drivers are OK these days but haven't tried them myself because I care about ML.
They are OK but with some caveats like VP9 HW decode not being available in Linux AMD iGPU drivers for reasons, which won't be a problem if you're running an AMD desktop tower PC, but if you're gonna watch Youtube on your AMD laptop, your battery will take a hit along with possible extra fan noise, which is unacceptable for a great media content consumption experience in Linux when even no-name Android phones and tablets have VP9 HW decode in Youtube out of the box. No bueno.
This is such a mess, as VP9 & AV1 HW video decode is not an issue under linux for Intel iGPUs, but AMD seems to not give a shit to expose VP9 decode on linux for their iGPUs. Also, unlike with Intel iGPUs, under linux, radeon-top does not show GPU decode usage for easy diagnostic purposes. I assume it's because AMD bought the video codec engine IP from some third party fabless IP vendor and they don't have the permission to open source the drivers for the video engine block as part of the licensing agreement, like they do for their in house developed GPU block. But still, regardless of the reason, it sucks for the linux end-users.
And another important issue nobody seems to talk about but one should be aware of, AMD APUs (at least to 5000 series) don't have unified memory between CPU and iGPU like Intel and Apple do, so you have to configure in your laptop BIOS how much of your system RAM you want allocated to your iGPU (512MB/1GB/2GB/4GB), with the rest remaining for the CPU. This sucks big time if you're switching between productivity where you need more memory for applications, and playing video games where you need as much memory as possible for the GPU, so you need to keep rebooting and changing in the BIOS the amount of memory you allocate to your iGPU, vs on Intel chips where the whole system memory is unified and shared dynamically between the CPU and iGPU, and it boils my blood as the whole marketing gimmick of AMD's APUs was the seamless merger between CPU and GPU resources together, while in practice their (5000 series) APUs are just a Ryzen CPU with a Vega GPU glued on the same die without them actually sharing any of the resources properly. Maybe the new 6000 series with RDNA2 changed that but I couldn't find any detailed info.
Honestly, as a laptop owner with AMD APU, if you're planning to go Linux, just get one with an Intel chip instead. Much less head aches as Intel Linux drivers and apps are second to none and have a unified memory model.
The performance and efficiency of AMD APUs is still great though, especially under Windows, but the overall implementation as a whole package seems poorly thought out and rushed out the door, especially under Linux compared to Intel.
VP9 should be available since Mesa 18.1 (or so) for VCN-based GPUs (i.e. Raven Ridge and newer). VP9 is not supported in hardware on UVD-based GPUs (i.e. discrete Vega).
VCN 3.0-based GPUs (i.e. RDNA2, the 6000-series APUs) also support AV1 decoding.
Yeah, in theory it's available, but good luck actually getting your browser to use it to HW decode YouTube videos under linux out of the box.
It usually works fine with video players like mplayer but not in browsers.
There are endless threads online about this not working. I for one, never managed to get it to work in any browser. What a mess.
Chrome doesn't support VA-API, so do not bother trying.
Some distributions do have Chromium builds with VA-API support enabled, but YMMV. Chromium uses X11 only and libva requires dri2, so it doesn't work under XWayland, which supports only dri3. (=> Chromium with VA-API works only in native X11 session)
Firefox does support VA-API. There was a period of time, when it did only under Wayland, but nowadays both X11 and Wayland should work. When running under Wayland, use the native version and /not/ via XWayland, because the same thing as with Chromium applies.
On the Firefox side, Redhat and Suse people did the work to support video acceleration.
Seamlessly sharing memory between the two chips works fine with the compute toolchain (rocm), I don't know how transparent it is for games.
Maybe in ROCM, but not in generic Windows and Linux apps and video games that I've tried. They all cap out at whatever you set in BIOS for the iGPU VRAM reservation and don't go beyond that into system RAM. If ROCM has this ability how come AMD's driver, at least in Windows, doesn't do this memory overflow thing for VRAM hungry apps like video games, as that would certainly alleviate this issue.
IMHO, still a worse implementation than the unified model of Intel. Having a large chunk of memory constantly blocked for a HW component, regardless if it's currently needed or not is just horribly inefficient, especially when you're on a mobile device and have 16GB of RAM or less to play with.
Disappointing.
Linux has no issue with drivers and/or video cards in particular, people just need to pay some attention when buying components, saying that linux has issues with graphics because of nvidia it's a bit unfair, nouveau is not able to use acceleration because the videocard doesn't activate it if it isn't loaded by the official nvidia blob, so if linux is supposed to have issues with graphic card while vendors actively create obstacles, we will never figure the real issue and hold the right people accountable: It's nvidia that has still issues with linux
The AMD drivers runs fine. They're functionally inferior to the Nvidia ones (in several aspects), but I had no big problems. I don't play on Linux, though.
I think open source makes a significant the difference - with Nvidia, issues often can't be solved by software devs (e.g. Libreoffice Calc running updating the screen very slowly). I suppose that with open source drivers, devs can at least get an idea of what's going on.
However, there's one dealbreaker with Nvidia - they have such "blob of a cards", that Linux, on a default configuration (which means, ISO with Nouveau) can't run at all with many Nvidia card series. I couldn't even boot with a GT 1030 (among the others).
I actually have no idea how people can install Linux on Nvidia systems, since I had to create an adhoc iso with the binary drivers preinstalled.
To this day I cannot think of a good reason to ship nouveau outside of "lets make users with nvidia cards suffer". I get the idea behind the nouveau project, but pushing an experimental driver that cannot work with 99% of the hardware it latches onto and forces users to disable it if they want a basic working system is actively malicious.
is it feature complete ? no, but to go ahead and say it's not working for 99% is just lying here is the list: https://nouveau.freedesktop.org/FeatureMatrix.html
what you can say though is that it is a bad idea for GPU that are relatively recent. wont block you from booting or displaying to screen but would probably be slow.
also this is distro dependent, I remember being given the choice with no default one (mean chosen automatically) when installing Manjaro (a derivative of arch linux).
I chose the proprietary driver since they are feature complete but later switched to nouveau driver since they are not prone to breaking on every other update. that was 2 years ago, zero problems since.
since it doesn't do CUDA either, nouveau is useless to me. next Linux build I'll either use Intel or AMD, but can't economically do ML on AMD still.
It isn't that hard to write a manual. It isn't that hard to respect user freedom to use tge device they purchased. It isn't that hard to just leave well enough alone.
But no.... Nvidia just couldn't.
Meanwhile the company responsible for the biggest security issues in the last decade still provides its CPU microcode as signed binary blob and the FLOS community is fine with that because someone at the FSF drew a random line to stand on. I will accept the FLOS communities hatred of NVIDIA the moment it stops bending over backward for the company that brought us Meltdown, Spectre, RowHammer (who needs consumer grade ECC anyway), etc. .
Indeed and still nothing has changed. Last time I checked, installing a Nvidia driver crashed the whole desktop and every-time you boot you Linux distro, it gives you a black screen with X11 or Wayland pop ups.
A magnificent waste of time that was fixing things in order to do basic work. I ended up using Windows with WSL2 and waiting for the new Macbook Air. I never saw the point of dealing with anything Nvidia on Linux these days.
However, during my time at Uni I maintained over the course of a couple of month a patchset against a kernelmodule for my research, and I remember what a mess it was. Slightest kernel updates broke it, and even supporting just 1-2 distros we used in our lab was very time consuming. Even after I left I got a couple of mails from researchers whether I could assist getting it to build on newer versions of the kernel. And even though I had a fraction of funcitonality compared to what NVidia provides, I absolutely understand how difficult it is to maintain a non-upstreams patchset over time - so I definetely believe all bad I hear about nvidia on various distros/setup is 100% true. It is just NVidias fault not to go the AMD route and at least try to get as much as possible upstreamed and open source.
On a sidenote, the only reason I went with NVidia was that at the time due to crypto-hype, a competetive AMD card was 50-70% more expensive (in retail, not the manufacturer suggested price). I'd definitely would go AMD next time.
Every other driver update breaks the system in unexpected ways, Wayland wasn't supported for the longest time, switching GPUs had no support at all for quite a while and still is a bad joke compared to Windows (e.g. you have to log out and log in again to switch the graphics processor unless you use 3rd party tools).
That's almost surely your distro's fault. I used to ran Nvidia for well over a decade on Arch with zero issues, and it's far from the only distro that properly handles Nvidia drivers.
If your distro doesn't distribute an Nvidia driver on their repos and maintains it accordingly with the kernel it ships, it is not an option you can consider if you are using Nvidia.
Since then linux has been great for me - on the servers.
We each make that mistake once ;)
Windows is out of the question in how they treat their customers. Example: Dialogue when rejecting upgrading to Win10, click the X button at the dialog upper right corner and be greeted by an immediate reboot and upgrade.
Linux, life is to short for me to handle the hassle on the desktop. Server is a no brainer.
I see you haven't used printers much :)
I swear to god if I ever become wealthy the printer industry is what I intended to completely destroy. Not in it for profit. Not positive sum whatever startup thinking. It will be Zero Sum.
Edit: Lasers are fine. That will be left alone.
Not he hero we deserve, but the hero we need!
It's just everywhere else that they are a problem.
So long as the driver doesn’t change, you can even run multiple versions simultaneously and nothing will break.
"Here, run this piece of code. No don't bother trying to read, build or understand it yourself, we know you won't be able to do it, so we put it in a little mystery box over here that you can run on top of your existing operating system. Now please don't ask any questions and go away."
But even if you compile it yourself, what exactly are you gaining? Extra work for something you won't look into anyway? You'd think open source stuff would be more peer reviewed, but as a maintainer of a few open company repos it's surprising how much nobody actually cares and will just run whatever.
Most of the time it works fine because the average person isn't a malicious actor, but every so often something gets compromised and it's always discovered by pure chance.
I can read and understand tf just fine and I’ve had to work around bugs (like the broken image resampling) by doing just that.
Treating tf as a blank box has nothing to do with it. The problem is that nothing none of the ABIs involved here (tf, cudnn, distro libc, nvidia driver, etc) are stable. The best you can hope for is to use the same driver for several containers with matched (tf, libc, cudnn) and that’s worked out well for me in the last couple of years.
This was back in AMD's Bulldozer days (2011), when the company struggled both financially and technologically.
Meanwhile NVIDIA sponsored universities with graphics cards and had already developed their CUDA ecosystem (in 2007) when AMD was still busy with the ATI acquisition. In 2011 NVIDIA had an annual net income of about $500 million, while AMD had a net loss of $600 million at the same time and kept struggling for the following 5 years.
In other words, NVIDIA already had an existing ecosystem of professional grade H/W accelerators and S/W infrastructure, when AMD was still a CPU manufacturer without a dedicated GPU division. When AMD acquired ATI, NVIDIA was already in the process of transitioning their GPGPU stack from data centre-only products to consumer hardware.
AMD has powerful ML hardware today, but that's data centre and supercomputer only. They didn't miss the boat on ML - they were busy not drowning while NVIDIA was handing out goodies to academia.
(And nor was it "all Intel's fault" either, AMD fucked up a lot in this time period, both technically and in their business decisions)
At one point AMD was set to merge with NVIDIA but the board couldn't get over the sticking point of Jensen wanting to be CEO of the resulting company. Had the board swallowed their pride and let that happen, I doubt he would have led the company down the Bulldozer garden path.
Instead AMD said no, and then way overpaid for ATI, which depleted their cash reserves and forced them to sell their foundries (which was ultimately probably the correct long-term move, but that isn't the proximate reason why they sold them - they were just out of cash at the time). Then they had no money and had to underfund their architectures, and move to "cost reduction" mechanisms in the design and implementation, and had a series of implementation problems and poor designs.
Phenom was late (so much so that AMD had to put out a stopgap dual-socket "Quad FX" system just to try and compete against Core2 Quad) and Phenom had a major bug where part of the cache system had to be turned off, tanking performance by like >25%. And by the time Phenom II came out, AMD was putting non-SMT quadcores against Nehalem. By the time Bulldozer came out, the 8150 was going against Sandy Bridge, and by the time AMD fixed the worst of Bulldozer's performance problems, the 8350 was going against Ivy Bridge, and it still sucked anyway. AMD just executed extremely poorly in this period and a large part of that is the cash shortages resulting from buying ATI.
The next decade of AMD's financial woes largely spring from that moment when the AMD board said "no" to the merger, and the chain of decisions and failures that resulted. And while consoles might have saved the company - they likely would not have been in that position in the first place had they said yes to the merger instead of emptying the bank account to buy ATI, instead of doing a merger-of-equals with NVIDIA.
Also, AMD still isn't taking the steps that they can to increase their ML marketshare. They are actively reducing the support levels of their ROCm package - amateurs can easily get into the basics with a consumer NVIDIA gaming GPU while AMD forces you to buy a $5000 enterprise card.
CUDA is successful because the same software works on low-powered laptop GPUs and expensive datacenter GPUs.
The problem is that NVIDIA has 100% of the mindshare and owns 97% of the dGPU market so it's a self-fullfilling prophecy that proprietary tech like CUDA will stay dominant in the foreseeable future.
Hopefully Intel re-entering the dGPU market will put a dent in that and move the needle a little.
Currently on driver 510.54 and playing Elden Ring on maximum settings with a 2080 super without issue.
Though you do have to add a kernel parameter to use nvidia's DRM mode for best performance which is non-obvious. And hybrid GPU laptops are a whole other thing, I guess.
There should not be much of an issue for Nvidia to open source it otherwise.
Open source doesn't mean free anyway
We as consumers should not be held back from using hardware the way that we intend to use it. Nvidia does not have any right to hinder us from using what we purchased how we see fit. (Provided that we are not infringing upon copyrights and/or I.P.)
The community would likely gladly help them with anything we can help with; and licenses would be less of an issue. It wouldn't be the first time closed source stuff has been made alternatives to it in open source specifically for reasons like licensing. MP3 for instance... not a terribly hard thing to deal with anymore, but once upon a time ago..
Anyways. Nvidia's true reason for doing anything is ultimately in their namesake. They want people to be envious. Part of making people envious is to keep things they want away from them.
So, yeah... that's the real reason. If they actually gave a flying fuck about the rest of us, they wouldn't be that way.
GTX 1080
I don't condone cybercrime but man would I just be ecstatic if Nvidia would finally follow AMD and Intel in developing an open source driver.