I think most people are excited about Steam on Linux because of gaming, but I've actually been excited because of better driver support. If this makes Nvidia put more effort into their Linux drivers and tools, it will make life a lot better for CUDA programming too. (I haven't tried OpenCL or AMD GPGPU stuff yet.)
> it will make life a lot better for CUDA programming too
Well having done quite a bit of CUDA programming under Windows and Linux, i'm interested in knowing what you find lacking on Linux ?
Performance wise i can report CUDA is just as fast on Linux as it is on windows.
Regarding tool support, i actually prefer to work under Linux, not because tools are better per se, but because your usual Unix tool chain does wonders with C++/CUDA. Under windows you have to struggle with Visual Studio just to get syntax highlighting.
There seems to be the profiler that is windows only. I never used it so i can't report on that.
EDIT : More generally, i've always found NVIDIA driver support for Linux to be very solid. Of course, it's closed source, but then so it is on Windows. I've never had a problem with an NVIDIA card on Linux, and i can't say that much about AMD/ATI.
> More generally, i've always found NVIDIA driver support for Linux to be very solid.
I guess you haven't had any laptop with the Optimus technology (NVIDIA dedicated card + Intel integrated GPU). There no official NVIDIA Optimus support for Linux whatsoever :(
> (though obviously it's their fault for using a proprietary blob)
I couldn't agree more. The problem with these news sites [1] is that they make the kernel developers look like stubborn zealots that refuse to do something that would ultimately benefit the users, when in fact they aren't really doing anything wrong. The news sites fail to mention the root of this problem: nVidia, a hardware manufacturer, refuses to open source their drivers. This may sound like no big deal; after all, lots of IT companies do that, right?. But it is a big deal. Refusing to open source the drivers is in fact refusing to let the users have control over the their hardware. It's not an end-user application that you can choose not to use; it's the thing that controls the hardware you own. "You can use it, but only through this restricted interface we give you, you can't look inside!". Not a nice move in my books.
My main problem with the Optimus configuration on Linux was overheating: as the discrete card (nVidia) was always on, even if the system wasn't using it, the computer was hotter. Without workload, the normal temperature on Linux was around 53ºC, while on Windows was 42ºC. It felt warmer on the keyboard too.
I had some problems trying to get Bumblebee to work on Fedora (at least the bbswitch worked, so the discrete nVidia card could be turned off, and then the computer wouldn't overheat on Linux). On Ubuntu though, the setup was really smooth [1]: just adding a PPA and then installing a package and everything was working :D
However, while Bumblebee is really cool, it still can't do what the official nVidia and Intel drivers do on Windows. You can run programs in the discrete card with Bumblebee, but you have to use a special command for that (optirun), the cards won't be switched on-the-fly depending on how much processing power is needed, which is the case with the official drivers on Windows. There supposedly is some progress in that regard though [2], in a project called Prime (awesome pun indeed)
I've had some problems with the drivers, which is what I was referring to. Sometimes the computer will get into an unusable state and I don't know why.
There are also some odd issues with the tools. Did you know that CUDA-GDB will give an internal driver error if it can't write to /tmp? No description of what's wrong, just "internal driver error". That one took a while to figure out (and I wasn't the one who figured it out in the end).
I've never really programmed under Windows, so I don't know about the tool support, but I'm very happy with Linux development tools. I have actually used the Nvidia profiler under Linux, but I haven't figured out how to make it give me useful information.
I wonder how representative my rather underwhelming experience with graphics drivers in Linux is.
The last time I was able to use ATI/AMD's proprietary driver without any problems was strangely enough with an ATI Radeon 9600 Pro in an old version of SuSE Linux. Since then AMD's proprietary driver has caused me semi-regular GPU lockups on R520 (X1650), Evergreen (HD 5670) and Southern Islands (HD 7770) series cards. Nvidia's proprietary drivers seem to have fared better with three generations of their cards (7300 GT, the notorious 8600M GS, GT 240, GTS 250...), with an occasional X server crash when running a video game in Wine but few lockups. On the other hand, in the FOSS world I have experienced the opposite (AMD being better than Nvidia). The worst individual case was setting up GeForce GT 240 to work in Linux Mint 13 last year. The OS wouldn't boot with kernel mode setting on and starting X once it has booted without kernel mode setting gave me a screenful of RGB noise; my solution was to install the proprietary driver in text mode and then write a custom xorg.conf. The drivers for Intel's graphics seem the best so far if you use relatively modern chips (I have tried GMA X3100, GMA 3150, Intel HD Graphics 2000), however, I had no luck trying to get the legacy Intel Extreme Graphics 2 to work. It doesn't really work with Linux 2.6+, resulting in an image that flashes and rolls up and down the screen like a the picture on an analogue TV that's lost the vertical synchronization signal.
If my case is in any way typical then I'd say the drivers are in dire need of fixing.
Good god when was the last time you tried this and had to write an X.org conf file?
I have to write one when I switch from novareau to nvidia-proprietary but it's for a very specific reason - my monitor outputs invalid EDID information. Otherwise, you should never have to write a config file in almost all cases.
> Good god when was the last time you tried this and had to write an X.org conf file?
It was early last year. The GT 240 is a really finicky card in Linux, apparently.
>I have to write one when I switch from novareau to nvidia-proprietary but it's for a very specific reason - my monitor outputs invalid EDID information. Otherwise, you should never have to write a config file in almost all cases.
I can't remember the exact options I had to put in xorg.conf for the GT 240 but them being there did matter.
I confronted a similar problem with EDID setting up an extra 1366x768 monitor connected to a legacy Radeon 9200 PC at work. This resolution is always a pain (since the value of 1366 is not divisible 8 and hence can't be specified in the EDID block), but it much more so when you have a legacy graphics card.
>The GT 240 is a really finicky card in Linux, apparently.
Weird, Novareau played fine with my GT 240 in my old desktop, but I was using it with 12.10 and novareau has come a long way recently. And installing the prop driver took nothing more than installing it (and maybe running nvidia-xconfig and letting it ensure 'nvidia' is loaded instead of 'novareau'.
Legacy monitors can be weird. I had someone in Ubuntu IRC with some very ancient super high res 13" monitor. I don't think we ever got them helped out.
Agreed, but it's doubtful that nVidia will support the Quadro (which is pretty much the best workstation chip around, and also what I use) just because of Steam. If anybody wants to render very complex gradients and shading using a regular GeForce, it's not going to be nearly as good as with a workstation-optimized chip. Many CAD apps are much slower on an nVidia gaming chip than they are on a workstation card.
So, at least for me, I'm still probably going to get left in the dark if I buy a new chip because support for the Quadros are egregious.
Did you try using official Nvidia drivers [1] (as opposed to notebook creator supplied ones)?
I have been using Quadros for long time (multiple generations, currently on Thinkpad with Quadro 2000M) and I never had any issue with games. Both compatibility and performance wise for me Quadros have been more or less equivalent to corresponding GeForce cards.
I do however always try to use the latest drivers from Nvidia and I turned off Optimus in BIOS.
Unfortunately, since it's not my own personal hardware and I really don't need any graphics past an X terminal and Visual Studio to do my job, I'm not really willing to muck with the drivers.
Interesting. Do you know why CAD programs are slower on gaming chips? I know the gaming cards sometimes have much worse double-precision performance than the GPGPU cards, but I must admit that I don't know what the difference is on any particular chip. It could also be a memory issue or something like that.
From what I recall when I previously looked into this, it's almost exclusively driver optimizations that are present/enabled for workstation cards and not the gaming equivalents.
During the GeForce 2/3 era, the BIOS on the card would lock out Quadro/professional features using software. The hardware was identical. I am not sure if this is still the case.
Regarding CUDA programming: If you want to do this seriously do yourself a favor and get a test machine with a Fermi and/or Kepler card running a CLI-only linux and ssh in for testing. CUDA drivers run just fine on linux, it's one of the most common environments for HPC programming right now.
What I mean is you usually don't want to do this on your laptop. First, a high end laptop like a macbook can hold up for 4 years while GPUs need to be replaced regularly in order to develop for the latest newest capabilities. At some point you will also want to try Intel MIC, AMD cards and so on. Secondly, it's just much nicer if the system you're working on doesn't get hot.
Note: If it's for graphical tools with user frontend I can understand if you don't want to do this. Even then it could be interesting to have offsite computing capabilities baked in however, since this is also preferred in many graphics/video designer houses.
