Why CUDA will have no widespread addoption for Mac Bad installer experience, quality, versioning, co

Accelerated Computing CUDA CUDA Programming and Performance
1

Hello,

CUDA 2.3 for Mac probably has the worst installer I’ve seen:

  • having 2 driver installs, depending on OS and installed GPU: is is not a bit Mac like.
    Apple installs ALL kexts for all devices with every OS: the correct kext gets loaded depending on the user’s hardware
  • separatelly installing the toolkit from the driver: what’s the point here? Can the driver do anyting without the toolkit? NO - so separating them is wrong!
  • BUGS: wrongly set permissions on the toolkit folder prevents CUDA from working after reboot.
  • The installer for version 2.2 warned user’s about the need to expand DYLD_LIBRARY_PATH, on CUDA 2.3 that was taken away from the installer, though still nescessary.
  • The whole DYLD_LIBRARY_PATH ist wrong: OS X provides a very good way to package dyld’s and header files as Frameworks and if a Framework is installed where it should, it is automatically found
  • The installer will often not install over an old installation - requiring manual deletion of /usr/local/cuda and the CUDA.kext

I also dislike the handling of problems and communication from NVIDIAs part:

  • when CUDA 2.3 was released the packages had bugs. A few days later the CUDA toolkit has re-released. No version increment, no way for user’s who had downloaded the buggy version to know it unless they digg deep into the CUDA announcements forum.
  • some user’s have found a work around for the current installations wrong permissons problem - but where is the sticky post on this forum? Or fixed installer packages?
  • since the GTX 280 was released users are having problems with the throttling of the GPU. Where’s official information from NVIDIA? And a fix, or at least a timeframe for a fix? The driver comes from NVIDIA so if this is a power management issue, it is an issue from NVIDIA.
  • Snow Leopard: we have a driver for it, but it looks like noone got it to work yet. Not a word from NVIDIA on this.
  • 64 bit CUDA for Mac: not a word on this too… besides a comment it might not make it into the 2.2 release

Have any of you seen a consumer application for Mac making use of CUDA?
Guess what, you won’t!
I cannot tell my end users to choose the correct driver, fix filesystem permissions, edit .bash_config to run my app. That is a no go.

That makes CUDA a tool for engineers and researchers only.

It’s like NVIDIA is screaming: forget the CUDA API on the Mac… OpenCL is the way to go. Just ignore the things CUDA can do better - eventually OpenCL will catch up.

Best regards
Mark

2

I agree with the whole spirit of your message.

Anyway CUDA wasn’t conceived to be used on mass-market, more than a developper tool to exploit nVidia’s GPU abilities to run General Purpose code.

And yes, OpenCL may be the right way to go when Snow Leopard will be there, to fully exploit the whole potential of a Mac.
I am excited to test it ASAP when Snow Leopard will launch, porting CUDA code to OpenCL (relatively easy) and using this new unified computing platform if it’s mature enough in term of features and performances.

3
  1. two kexts is an unfortunate limitation of how the rest of our drivers are distributed on Apple platforms. there’s not much (read: zero) we can do about it in Leopard.
  2. yes, you can run CUDA apps without the toolkit.
  3. yeah, I don’t know why this hasn’t been fixed and repackaged yet. will check on it.
    4 and 5. I thought we removed the requirement for DYLD_LIBRARY_PATH in 2.3 (or at least I was told that was the case). I know very little about Mac-specific development issues, I’m just repeating what I was told some months ago.
  4. for whatever reason, we seem to have constant trouble with the Apple installer, from the 2.2 one that randomly wouldn’t install CUDA.kext by default to 2.3 where it apparently sometimes erroneously sets permissions on the kext loader, and we can never reproduce these in house. it’s pretty frustrating, but we are trying to fix it.

Silent updates of packages: we’re not going to do that again. This was just a stopgap measure so we could rerelease packages very quickly, but it turned out to be such a hassle for everybody (both us and users) that we came up with a more robust versioning scheme that will make something like this trivial in the future.
Sticky post: I thought I did that a while ago, but I guess I didn’t. Will do that in a minute…
Power management: Surprisingly enough, this isn’t our bug/issue. If it were, we would have fixed it when we fixed the problem on every other OS.
Snow Leopard: I don’t have a Snow Leopard machine, so I haven’t tested it. One thing to keep in mind is that OS X is way more complicated (for us) in terms of driver layout than any other platform. On Linux/Windows, we give you a driver and that’s that. We can update the kernel mode part and the user mode part whenever we want to. This is not true on OS X–we’re stuck with whatever kernel mode driver is there. This is why we have multiple drivers now, and it’s why Snow Leopard support is probably pretty confusing to you as a user.
64-bit: This is still a priority, but I don’t have an ETA.

part of this lack of communication is that I don’t have nearly as much time to spend on the forums as I used to (I now fix driver bugs instead of complaining about them to the driver team, but all of my time developing is spent on Linux and Windows). so yeah, 2.3 was a bungled release, we’re fixing the problems that it exposed, and we do care about Mac issues. I just don’t know enough about them to be able to comment often without getting hit in the head for saying something I shouldn’t have.

4

Hello tmurray,

A few comment’s to your responses:

#2: I now realized libcuda.dylib is deployed by the driver, so yes, app’s using the JIT can theoretically run installing the driver only. Still, I don’t think that is reason enough to separate the two - it does not hurt to deploy the driver and runtime APIs at once.

#4 and 5: I just removed the export DYLD_LIBRARY_PATH stuff and my CUDA programs don’t lauch, so it looks like the dependency is still there. I don’t really know how you can get rid of it without moving the dylib’s somewhere else since /usr/local/* is not included in the dylid search path by default.

I’m not an experienced packager, but on the Mac, Frameworks are really the most appropriate way to go. Basically it is just a folder structure with dylib’s, headers and any other supporting files. Third party frameworks (as CUDA) should be placed in /Library/Frameworks, and this path is automatically looked up by the dynamic linker.

There’s some good dokumentation on frameworks here: [url=“http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html”]http://developer.apple.com/documentation/M...Frameworks.html[/url]

That would solve the problem for headers and dylibs. PDF’s can be included in the framework too - they wouldn’t be much harder to find there than they currently are:) But I would actually strip them from the driver/toolkit installation. They should be installed with the SDK. They would be much easier to find in say /Development/GPU Computing/doc.

The tricky part is the binaries shipped with CUDA. These can certainly be included inside the Framework, but they wouldn’t be in the binary search path in there. I’m nt sure what is the best solution here, but I think it would be perfectly ok to place these inside the Framework (for consistency), and create symbolic links to these in any folder on the search path - usr/local/bin is probably the best place.

Regarding Snow Leopard, and the need for two kext’s: I understand what you wrote, but it is very easy to make one installer that contains both kext’s and installs the correct one depending on the OS version.

Yes, 2.3 was a bungled release :) (nice, just learned a new usefull word)

The beta for 2.3, which I tested did not have all these problems (it didn’t also have all the features that the release now has) so it looks like the release was rushed out. Anyway, I think it makes a lot of sense releasing a late beta so we can catch these problems and those get fixed for the final release. That’s what beta testers are for.

So, there is some room for improvement, but I am happy to see you are aware of these problems and taking steps to improve things.

I’d really like to see a more Mac friendly CUDA that could be used by application developers.

Best regards
Mark

5

If you could get someone who is authorized to pass information about package fixes, in re: point 3, I have an urgent need for a working CUDA installation under Snow Leopard. :) Plus, we’re looking down the barrel of release on 2 days, so the problem will be magnified very soon.

Re: kernel extensions – there are ways of applying updates to kernel mode items semi-automatically (with user approval). If the devs are unaware of solutions and interested, I’m sure we could hunt up a solution quickly.

And I’m personally looking forward to 64-bit with great interest.

Thanks for the help. Sure would appreciate the updated installer as soon as possible.

6

Hi,

I’m throwing in my two cents to ask for robust mac support with good end-user installation and update experience. We’re just getting started with GPU here, but are looking to use it for accelerating some pro/consumer audio apps by next year - very nice potential. The audio market is still half Mac (last I checked), so that’s a decent amount of GPU’s! :) Things like buggy installers and teapot workarounds to get maximum speed would be game stoppers for us. I imagine we might just go OpenCL eventually, so maybe this is moot?

Cheers,
Michael

7

Perhaps I am interpreting it differently, but I believe his complaint was about having two driver INSTALLS, not two drivers. It would be much more user friendly to have 1 installation package that made the call on which kext to actually install for the user.

-Brett