NVIDIA's Linux Fate

Just like everyone else on the globe, I heard/read/watched Linus telling NVIDIA, in absolutely no uncertain terms, that they were bad Linux citizens. At first I thought Linus was telling them that they were "number one!!!" but sadly this turned out not to be the case.

The topic came up from someone in the audience who was trying to get NVIDIA's Optimus tech working on a Linux notebook. This is a bit of a different bird than NVIDIA's usual discrete GPU market, as this requires co-operation between onboard (or on-die) video adapters, the discrete graphics card and the northbridge to turn off the accelerated GPU when not in use. To my knowledge only Windows 7 drivers can accomplish this, and Linux doesn't quite understand the management architecture to leverage it. The open-source Bumblebee Project appears to be doing a great job of trying to set ACPI & BIOS flags to accomplish the same thing, but the entire effort could be greatly accelerated with NVIDIA's help. While NVIDIA has more-or-less sanctioned the Bumblebee project by releasing installers that work with Bumblebee, they haven't contributed to it directly.

Linux called NVIDIA's lack of Linux support the "exception rather than the rule," and extended that comment to mention that "NVIDIA been one of the worst trouble spots" in kernel support and the "single worst company we've ever dealt with." This of course was punctuated with the infamous line: "so NVIDIA, f**k you." He didn't actually speak in astrisks, I'm just experimenting with censorship.

Linus, of course, just "like[s] being outrageous at times... [because] people who get offended should be offended." It was probably meant to be a thrown gauntlet more than a haymaker, and I can definitely see why. I've been a big advocate of NVIDIA, even with their proprietary stance on GPU drivers and increasingly as the nouveau driver has increased its feature parity. These kind of ACPI hacks however are not the same as keeping tight control over intellectual property tied to their GPU hardware. Given how good drivers are the true value behind discrete graphics cards, I understand not wanting to open-source them to competitors ("Hey AMD! Here's how we did tessalation!"). Controlling power management within the OS kernel is a different matter however - and everyone benefits (including NVIDIA) with broader support. What's the barrier to entry of AMD creating something similar that idled the discrete GPU when no accelerated calls were being made? For that matter, what's to stop Microsoft from coming up with a vendor-agnostic solution that does the same thing? It seems not unlike what OS X Lion is doing right now...

NVIDIA's response basically focused on the fact that they permit Bumblebee to co-exist, their proprietary GPU drivers still offer fantastic performance and support (which they do) and they are one of the largest contributors to Linux on ARM. In short: they don't feel like Optimus Linux support is worth doing right now. However there are signs that even this isn't working well - NVIDIA just lost a quarter million dollar GPU deal due to poor MIPS support.

NVIDIA, this is a great time to step up and contribute the solution to the Linux kernel. Show your competitive edge continues to be broad platform support, otherwise people may meander elsewhere.

Post script: If you're interested in getting a sense of how crazy GPU/graphics driver development is on Linux, read Jasper St. Pierre's post on The Linux Graphics Stack. Terrific outline on the steps a polygon goes through to get to your monitor.

Make a VPU Socket Already! Get It Over With!

My lands. If the floating point unit took this long to become mainstream I'd be using a Core 2 Duo with a math co-processor still.

Not to go all Halfhill or anything, but it has appeared that a vector co-processor or VPU's on-die were an immediate need for at least the past two or three years. Both Nvidia and AMD are bringing GPU's closer to the CPU, and it at once appeared that AMD's multi-core platform has included VPU/FPU/integer math/memory controller/CISC/RISC/misc./bacon&swiss together to take many types of tasks and integrate them under one die's roof.

And now that Nvidia has wisely acquired AGEIA and their PhysX platform it seems a general purpose vector processing platform is getting closer. A standalone PhysX never took off on the consumer marketplace, and purchasing another Radeon or GeForce just for physics processing (as both AMD and Nvidia were touting at electronics expo's) never caught on either. But a generalized, open-platform physics API that takes advantage of unused GPU cycles would definitely catch on. Spin your GPU fan faster and get real-time smoke effects... sign me up.

Nvidia has been extremely forward-thinking with their Linux drivers, and I hope they continue to be trend setters with the PhysX API. The PhysX engine and SDK was made freely available for Windows and Linux systems prior to Nvidia's acquisition, but hardware acceleration currently only works within Windows. Since Nvidia is porting PhysX to their own CUDA programming interface, it seems entirely probable that the Linux API would plugin to Nvidia's binary-only driver. And why not release the PhysX API under GPL? They could port to CUDA (whose specification is already open, available and widely used) then reduce their future development efforts by letting a wide swath of interested engineers maintain the codebase as needed.

Widely available drivers, development kits and APIs will help drive hardware sales in an era where Vista w/ DirectX 10 adoption isn't exactly stellar. I won't invest in being able to run Crysis in DX10 under native resolution for a 22" LCD, but I will invest to get more particle effects or more dynamic geoms. At that point you're adding to the whole gameplay proposition instead of polishing up aesthetics, with continuously diminishing results.

Sloppy SuSE

Have you seen Novell's "improvement" on the KDE menu? Have you seen the quotes around the word "improvement"? I have no idea what they were thinking. Reading the openSUSE site they claim the menu was the brainchild of hundreds of hours of usability study and research, examining every minute detail of user interaction. And yet they came up with a menu that takes 50 clicks to launch an application. Riiiiiight.

I just spent the past three days trying to get dual monitors working with the very insipid ATI card in my Latitude D600. Bear in mind, this isn't the first time I've tried to get a Xinerama-like "bigdesktop" setup working with this machine. Nope. I've had one since I've owned this machine, which is going on two and a half years. And yet, with every OS install on this machine, I've had to wrestle with getting the ATI drivers to obey. It's absolutely ridiculous.

The crazy thing is that we're not even talking about different driver versions. From XFree86 to XOrg, things have behaved weird or wacky in different ways. The only version of the driver I can run is 8.28.8, and even that would be unavailable if it wasn't for K's cluttered loft. 8.29.6 causes the LCD on my laptop to slowly - and I'm not kidding here - burn and bleed pixels. 8.32.5 won't even detect a screen. It's a pretty sorry state of affairs, especially considering 8.28.8 won't even work with XOrg 7.2, which is what SuSE 10.2 ships with. I have to backport to XOrg 7.1, install the 8.28.8 driver, then hack the config file.

Don't even get me started about the xorg.conf file. Even though my version of the driver stays the same, with each SuSE release the file has to change. Release before last I had to tell it my "DesktopSetup" was "0x00000000". Last release I had to ForceMonitors to be "auto,auto" for some unexplained reason (actually specifying the monitors wouldn't work). And in this release I had to specify ForceMonitors to be "lvds,tdms" and explicity specify the HSync2 and VRefresh2 of the monitor in the "Device" section. If I didn't, it would either never turn the monitor on, choose an incorrect frequency or choose a lower resolution.

If the above sounds like absolute rubbish, you're absolutely correct. And SuSE isn't the cause of the problem... it's ATI. Ubuntu, Fedora... they'd have the same problem. It's just that ATI doesn't feel like they need to adhere to "standards" of configuration at all, and their driver is simply unstable and, at times, unusable. The lesson: never, in your life, buy ATI hardware.

Send SuSE Back...

I upgraded my desktop and laptop to openSUSE 10.2 this week. Wow. Bad wow.

First off, ATI's support of Linux drivers is still abysmal. Not only are their configuration files whack, but they can't be composited, don't support Xinerama (on my laptop at least) and are a pain to install. SuSE ships with a release candidate XOrg 7.2 (because they are really into Xgl and composite extensions), and ATI wasn't ready to support it yet... probably since it hasn't been released. And yet, ATI quickly updated their driver. Still, with my laptop, neither the newer driver nor XOrg 7.2 run. I had to down-port to 7.1, then find an elder driver and use that. Hacked, ugly and it wasted a day and a half of hacking.

NVidia support still isn't much better. When the computer first starts post-install, you get nothing but a blank XWindow. Nice. You actually have to install the NVidia proprietary drivers first, then you can run your window manager. WTF?

As for sound, that was also borked. My laptop did fine with the install, but with my AMD64 desktop sound didn't work at all unless I was root. For some crazy-go-nuts reason, my users weren't in the "sound" group and didn't have permission to access /dev/dsp. So that was fun chasing down.

The Gnome people love messing with my head. Now they've created a keyring manager not unlike KWallet except, just like everything else for Gnome, it's far too convoluted. Evolution uses it to obtain passwords, however OpenSUSE doesn't open the keyring properly prior to launching Evolution. So I have to resort to an ugly, dirty hack for it to work.

So let's sum up here before I rant too long. My desktop wouldn't work immediately after install. Evolution didn't work. My laptop could run on the open-source drivers, but no luck on dual-monitor configs with the proprietary driver. Sound took hacking to work on the desktop. I think we need to let the original SuSE have their distro back - they always polished things to a nice sheen.

On the upside ODE 0.7 is automagically included it seems. So at least I have a standard ODE to develop on / release with. Also Novell has admitted to ZEN sucking - and they've offered alternatives. Although their really horrid ZEN update is still the default. Encrypted partitions work exactly as they should, and NetworkManager works as well.

Hopefully even though openSUSE 10.2 was off to a really rocky start, it will be smooth sailing from here.

Nvidia's CPU

Now that ATI and AMD are one, Nvidia is working on a CPU as well. There are a lot of people saying they're working on a "GPU on a chip," but I seriously doubt it. It seems a lot of people are wagering this will go toward the embedded or low-power market, just like when VIA acquired Cyrix. But to do so would be extremely narrow-minded of ATI and Nvidia, even considering the boom of embedded devices and the increasing horsepower needed by set-top boxes.

I'm much more inclined to think that Nvidia is working with Intel (which would be a huge surprise, considering how they've been fighting with SLI on nForce vs. Intel chipsets) to compete with AMD & ATI working on bringing vector processing units to CPU's.

I incessantly bring this topic up, but I had to mention this since it seems that my predictions are actually going to happen. I don't necessarily think this will cause GPU's-on-CPU's to happen, although it might be a by-product. Instead I think this is going to allow for increased parallelization, faster MMX instructions (or 3DNow! if that's your taste) and a movement of putting the work of those physics accelerator cards back on the CPU die.

We may see a CPU with four cores, each with integer and floating point units then a handful of separate vector processors (a la IBM's cell) along side them. Given how the Cell reportedly absolutely sucks for many types of algorithms, this may give developers the best of both worlds. Rapidly branching and conditional logic can be done on the integer units with branch prediction and short instruction pipes while long, grinding algorithms can go to the vector processor. This has already worked for projects like Folding@Home, and could work for many similar algorithms.

Or AMD/ATI and Nvidia could just go for a stupid, embedded GPU's sitting on die with the CPU. But they'd be passing up something much cooler.

Exactly How Many PCI-E Slots Does One Need?

I'm pretty much hammering this subject into the ground, but then again so are component makers.

Recently we saw Ageia's physics accelerator come to market as an add-on expansion card, astride your existing video accelerator and sound card. Next we saw the Killer NIC reviewed by IGN, a "network interface accelerator" which promises to offload the assembly of TCP and UDP packets to take load off the CPU. It's actually an embedded Linux instance, assembling your TCP stack instead of Windows. Windows just sends the Killer NIC raw datagrams, then the Killer NIC does all the work to disassemble the datagrams into bare signals over the wire.

Now there's supposedly an accelerator in the works, the Intia Processor, dedicated to nonplayer character AI acceleration. It would offload AI processing from the CPU and instead have a dedicated API for pathfinding, terrain adaptation and line-of-site detection.

So let's count the possible gaming accelerators here:

Sound (i.e. Sound Blaser X-Fi)

Video (i.e. NVIDIA GeForce)

Video (additional NVIDIA GeForce for SLI)

Physics (Ageia PhysX)

Networking (Killer NIC)

AI (Intia Processor)

So that eats at least six slots, but if you have double-wide video cards, more like eight. Oh yeah, and you'll spend nearly $1,500 on just the above hardware accelerators alone.

This is a cycle that repeats itself in the computer world, tho. Popular software algorithms become API's. API's become baked into hardware. The hardware becomes to inflexible and becomes firmware. The firmware isn't flexible so it goes into software. And on and on we go.

But this hasn't necessarily happened for OpenGL or graphics acceleration. Why? Because there you're not baking an API into silicon, you're using a different type of processing unit altogether to solve a different genre of problems. Multiple vector processing pipelines can streamline linear algorithms much more effectively that complex instruction set CPU's. The same analogy can be made for floating point units when they were introduced along side elder CPU's that could only handle integer math.

Not only that, we're looking at chip makers shy away from raw clock speeds and instead looking at cramming as many CPU cores as possible on a single die. This allows for every CPU stamped out of the factory to be a multiprocessor machine. Once API's become more threadsafe, this crazy specialized hardware will instead just be an API call sent to one of the four idle CPU's on someone's desktop.

I think the eventual result of this crazy hardwareization (feel free to use that one) is that people are going to want to fit their algorithms into one of three processing units: the CPU pool (by "pool" I mean a pool of processors upon which to dump your asymmetric threads), the VPU (vector processing unit) or the FPU. The CPU & FPU have already become as one but as any C/C++ programmer can attest to, the decision to use integer based math as opposed to floating point math still rests heavily on the programmer's mind.

Given people are already compiling & running applications on a GPU that have nothing at all to do with graphics, it's only a matter of time before chipset manufacturers come up with a way to capitalize on the new general purpose processing unit.

AMDTI? ATIMD? The Vector and the CPU

I hate to say I told you so, but...

AMD and ATI are now one. It's the talk of the town: AMD has taken over ATI, to make... umm... AMDTI?

The hardware ramifications aren't well known... who knows if this will spawn a new core-logic chipset, a new southbridge, a new means of fabricating ATI/AMD procs, new GPU's and physics accelerators, or just new marketing. However... if the core reason they've joined together is for intellectual property, we may start to see some vector units in CPU's. Who knows.

From my perspective, this smells like a bad deal. ATI's Linux support, while existant, is shallowly so. One need only to try to manage a dual-screen setup or hack an xorg.conf file to realize how kaboshed ATI's Linux driver support is. Contrast it to the robustness of Nvidia's unified driver model and there is simply no comparison. Nvidia wins by not inventing their own wacky configuration schema, but instead streamlining their X11 integration with the mainline accepted standards and augmenting it only when necessary.

And yet, AMD has proven to be a big Linux supporter. So maybe their ingestion of ATI will be a driving force for them to get their collective butts in gear. Here's to hoping ATI will be the big winner of all this, and that they get in line with AMD's more competitive practices.