CUDA 10.2 Released With VMM APIs, libcu++ As Parallel Standard C++ Library For GPUs

[schmidtbag]

Metal shipped two years before Vulkan on iOS. I guess Apple wanted to have its own api and not be bound to anyone else.

Hmm, so it was. I guess that makes a lot more sense why Apple pushes for it as hard as they do.

Apple has got a few big open source projects: webkit, swift, clang (primarily supported by Apple when it was created), foundation-db, cups.

Ah right, I forgot about clang. I wasn't aware webkit or swift were open source.

[CochainComplex]

On what distro? and how exactly a graphic driver could have screwed your system? (unless by screwed you mean no GUI)

Well...If this is not an ironical question. I have a Dell Precision 7540 with T1000 (OEM Ubuntu 18.04) and I was using the cudatoolkit 10.1.2 with nvidia 418 and nvidia-prime. there i have this issue https://github.com/ValveSoftware/ste...ux/issues/5778
But i worked it around with steam pulled from flatpak there it uses a i386 and x86_64 libs ..fine..more or less.
Now recently apt-get promted that I could update to 440 since this CUDA 10.2 release...which I did. Flatpak tried to update as well...but it only installed the 440 x86_64 in flatpak..so steam broken.

I have tried to downgrade/rollback ...no GUI...purging everything and build the module by myself (440) ...well steam on ubuntu and steam in flatpak works but tearing and no prime what ever i do. In between secureboot option to audit otherwise the kernel module doesnt want to be integrated ...what so ever.

Multiple approaches with multiple fresh ubuntu installations ....but it is a clusterf*** now I have everything else running 430 ...i tried to install 418 but some how 430 got partial selected (ubuntu repo and nvidia local deb) tearing ...nvidia_drm.modset=1 breaks boot.... I tried to replicate the status of 418 + cuda 10.1.2 which i had before and which was also a pain.

This costs me already 2 days...other systems Im using Intel haswell, intel brasswell intel iGPU no damn issue at all even works out of the box without any issue. The " troublesome" Raven Ridge AMD ...debian stretch will not boot with kernel backported 4.18 ..well diy kernel compilation and it works flawless.

So I wouldn't consider my self not as bloody Linux rookie ...but this is just arbitrary settings permutation and hoping that one configuration will work.

p.s.: building the driver: just one bar no errorpromt...you have to dig through the logs instead of ...well libXXX.so is missing or something went wrong there. x11 configs and blacklists are here and there and sometimes not existing even if it says copied.

Something is totally screwed up with this drivers. But well nobody knows its closed source.

[CochainComplex]

After day 3 still no working solution...i give up prime. At least tearing is solved. ....even compiling openmpi with intel compiler and making it runable on a 9000 core hpc (without admin rights) was less difficult.

[coder]

How exactly does the first point you bring up favor Metal over Vulkan? Vulkan would reduce development costs, because pretty much the rest of the entire industry has done all the work for them.

I don't think so. I don't really know how the work of implementing/supporting Metal is split between them and AMD/Intel, but obviously much of this is implemented by them. The same should be true of their Vulkan implementation, since they won't want apps to link against vendor-specific Vulkan implementations. Moreover, their iOS solution will be entirely on their shoulders.

Not knowing much about either API, I'd say that they'd probably involve the same order of magnitude of work for Apple to support. However, I think Metal is a bit higher level, which should make it more approachable for developers. I think that's no small point - if they don't support OpenGL, then they really need a 3D API that's more developer-friendly than Vulkan.

Anyway, I'm not arguing that Apple shouldn't support Vulkan, but it's in their genes to be proprietary and given that they have Metal, they're certainly not going to want to support both.

I could've sworn they didn't support MoltenVK? For example, I thought apps on Apple's App Store had issues of being removed because of MoltenVK. Or maybe I'm confusing it with whatever the OpenGL->Metal converter is called.

Your recollection is not faulty - just incomplete. That story was quickly followed-on by an update where the underlying issue was sorted out and I think Apple even (indirectly) voiced tacit approval of MoltenVK.

To my understanding, a large chunk of it isn't open source.

Yes, I would assume so. I just learned of the existence of their open source kernel, myself.

[Ipkh]

The Mach kernel used by Apple is not open source in any meaningful way. They have a commercial license for it and do not contribute changes back.

They certainly do control and contribute to some open source projects. But the kernel is not one of those.

[schmidtbag]

I don't think so. I don't really know how the work of implementing/supporting Metal is split between them and AMD/Intel, but obviously much of this is implemented by them. The same should be true of their Vulkan implementation, since they won't want apps to link against vendor-specific Vulkan implementations. Moreover, their iOS solution will be entirely on their shoulders.

Yes, AMD and Intel implement them, but, Apple and all of their affiliates are the ones that have to determine the spec and actually use them. I wouldn't be surprised if AMD and Intel just copy+pasted a large chunk of their Vulkan or DX12 code, so on their end, it's actually quite simple. The difficulty comes down to the developers who have to actually use it in their software (well, difficult if they intend it to be multi-platform, or if most of their career used other APIs). It can be a real chore porting to different graphics APIs, which is probably why so many console ports to PC come out so crappy.

Not knowing much about either API, I'd say that they'd probably involve the same order of magnitude of work for Apple to support. However, I think Metal is a bit higher level, which should make it more approachable for developers. I think that's no small point - if they don't support OpenGL, then they really need a 3D API that's more developer-friendly than Vulkan.

Anyway, I'm not arguing that Apple shouldn't support Vulkan, but it's in their genes to be proprietary and given that they have Metal, they're certainly not going to want to support both.

All of that sounds reasonable to me.

[Ipkh]

All this Apple talk is really off topic. Apple has shown that it prefers closed source software. They frequently switch to closed implementations as soon as they feel their solution is better.

We'll see once the new Mac Pro and X Server enter the market as real professionals need hardware acceleration for their renders. Real professionals will happily do the real work on PC servers and if Apple truly wants back in the renderfarm market they will have to reverse course.

Nvidia continues to improve their own custom implementation while making it easier for developers to code to it. Many of the Cuda features do get into the Vulkan api at done point. Getting changes into the Vulkan stack takes time and serves little purpose if Nvidia is the only interested party.

[coder]

The Mach kernel used by Apple is not open source in any meaningful way. They have a commercial license for it and do not contribute changes back.

They certainly do control and contribute to some open source projects. But the kernel is not one of those.

Here's the XNU kernel from OS X 10.13:

https://opensource.apple.com/source/xnu/xnu-4570.1.46/

For more info: https://en.wikipedia.org/wiki/XNU

And that's pretty much all I know about the subject.

Edit: this appears to be instructions on how to build & extend the MacOS kernel: https://developer.apple.com/library/...ild/build.html

[coder]

Many of the Cuda features do get into the Vulkan api at done point. Getting changes into the Vulkan stack takes time and serves little purpose if Nvidia is the only interested party.

Vulkan doesn't have a device-side programming language, and CUDA is mostly about what runs on the device.