NVIDIA Driver Developer Discusses Linux Graphics
An anonymous reader writes "Andy Ritger, who leads the NVIDIA UNIX Graphics Team responsible for creating drivers on Linux, FreeBSD and Solaris, has answered many questions at Phoronix about the state of Linux graphics, gaming, and drivers. Ritger shares some interesting facts, such as: the Linux graphics driver download rate is 0.5% that of their Windows driver downloads at NVIDIA.com; how the Nouveau developers are doing an incredible job; creating an AMD-like open-source strategy at NVIDIA would be time intensive and unlikely; and development problems for the Linux platform. Also commented on are new features that may come to their Linux driver within the next twelve months." Like all stories at Phoronix, in common with most other hardware review sites, this one is arbitrarily and maddeningly spread across 8 pages.
This was mentioned in the article. They do find it troublesome to measure their Linux user-base due to this.
Q: Overall, what percentage of NVIDIA's customers do you believe use Linux?
I don't know many concrete percentages. Highend workstation visualization is roughly half Linux, and Digital Content Creation (DCC) is largely Linux. NVIDIA Linux graphics powers a respectable portion of the 3D workstations. Our CUDA user base also has a large Linux contingent.
However, the number of Linux driver downloads from nvidia.com is only 0.5% the number of nvidia.com Windows driver downloads. Of course, many Linux users get our driver through distro packages and other means that wouldn't be measured in that download figure.
Measuring the size of the NVIDIA Linux user base has always been a challenge for us.
Italics mine.
I used to go off to the Nvidia site to download the Nvidia drivers for my card, then manually installing the driver.
Then I read about DKMS packages in the repositories that I could install, so every time the Kernel got updated, the package for the graphics driver got automatically recompiled with that Kernel. I was unsure about trying it, but when I did I never looked back, it's been great. Never had to manually edit the xorg.conf file ever again (although I have a backup just in case it goes wrong).
Take Nobody's Word For It.
From what I understand, NVIDIA's driver architecture is significantly different. The NVIDIA driver replaces most of the X graphics stack, whereas fglrx and ATI's open-source projects have always tried to work mostly with the X11 system. Personally, I prefer ATI's approach, and spend all my GPU and CPU money with them any more.
My blog. Good stuff (when I remember to update it). Read it.
As someone who's worked for NVIDIA driver development, I can tell you that NVIDIA has no "beliefs" regarding open source at all, and most of the developers have no problem with it. I've had plenty of chats with folks there who were trying out Ubuntu, etc. A guy down the hall had a poster on his door of the linux kernel 0.1 source (I think from a Red Hat conference of some kind). The real reason they don't want to open-source the driver is because the driver is /massive/, and setting up the documentation and outlets for it would take time and effort away from their primary goal, which is staying on top of the market and satisfying as many customers as they can while doing so. And trust me, I don't care how good a dev team you've put together, if they simply dumped the driver code out on the net I guarantee no one would be able to reverse engineer the damn thing.
So yeah. If you can make a good case why it's in their interests to open source it, I bet they'd consider it more seriously. Don't make the mistake of anthropomorphizing a large company.
I think you have it wrong and I'm writing this at Sony Pictures Imageworks on a CentOS box.
The film industry is mainly Windows and Linux, the larger the facility the higher the chance of it being a Linux house, but not always.
You hear "Macs make movies" so often and if anyone who doesn't work in the industry could see the state of things they would find the quote funny.
The main users of Apple products are producers and other pencil pushers running around with iPhones and Mac Pros, video files passed around during production are usually QuickTime files. Other than that a very limited amount of the business is anything Apple related. Final Cut is popular however its only one tool in the whole production chain and a facility doesn't need to equip everyone with a Mac just because its used. It is not uncommon to see a few Macs around facilities however you do not seem them in numbers.
I have only visited one all Mac based facility and even then they had RHEL dual booting macs. I can probably count on both hands how many visual effects studios I've seen or heard of that are all Mac based. Linux and Windows are no doubt the prominent players in the visual effects field. Linux isn't just on the backend either, plenty of facilities run Linux on the desktop and any one day there are thousands of artists typing grep and ls in a terminal somewhere. Its not just the bigger facilities either, plenty of smaller shops run Linux all around. If a facility isn't running Linux it most likely is running Windows.
Avids are used in editorial nothing more, so you do not see them in numbers. The Autodesk offerings have moved off Irix and are now HP/IBM Linux workstations.
Nvidia has the DCC market cornered with the Quadro line, I'm not going to get into the debate of whether they are wroth the price or not though. Even if a facility doesn't use Quadros in mass you can almost be certain the workstations have some sort of Nvidia card installed. Most applications in DCC are OpenGL based, since Nvidia has a track record of having a better OpenGL product, its not hard to understand why they might have a strong hold on the DCC industry.
Saying that NVIDIA think the unstable kernel API being "very little trouble" is a little understated. What they actually say in the article:
1) The lack of a stable API in the Linux kernel. This is not a large obstacle for us, though: the kernel interface layer of the NVIDIA kernel module is distributed as source code, and compiled at install time for the version and configuration of the kernel in use. This requires occasional maintenance to update for new kernel interface changes, but generally is not too much work.
That said, the kernel API churn sometimes seems unfortunate: in some cases, working interfaces are broken or replaced with broken ones for no seemingly good reason. In some other cases, APIs that were previously available to us are rendered unusable.
For anybody that cares,this covers some of the complexity in a simple way.
IranAir Flight 655 never forget!
"Most" users use intel integrated graphics (probably especially the ones that don't actually care about graphics)....
Most people I know (I'm not going to talk about "Most people") end up downloading the drivers directly from the nVidia site when they are using windows.
When I'm on linux I never download the drivers from the nvidia site, I use rpm fusion (for fedora).
I would say that most linux users probably do this for one important reason: A part of the nvidia driver has to be compiled to the specific kernel version that you are running (uname -r), if you update your system, and you don't compile a new copy of the driver, you will lose all accelerated graphics support....It's a pain.
If you use a package repository, your kernel will be held at the supported version for the nvidia driver, until the nvidia driver gets recompiled against your kernel. The people over at rpmfusion are pretty fast about doing this, so, you end up getting your kenel updates delayed by a few hours, in the same day.
I fear the Y2038 bug
You keep telling yourself that it's just because we're dogmatic. I'll add an anecdote in the meantime.
I was in a similar selection dilemma as the original AC and ended up selecting Intel graphics (Thinkpad X61s) because I knew it would just work and I could use the kernels from the distro I've chosen.
I later found out that the whole linux development team had individually made the same decision (not picked the same machine, but all went for Intel graphics).
I'd also like to point out that "Everything you've mentioned can also be addressed ... without requiring the release of the source code" is a totally laughable idea when you present it without details. As an example how do you expect the community to be able to fix bugs and keep old drivers up-to-date (two of GPs points) when the source is not available?