Targetting CUDA support but what about Vulkan API?

[NRT_AntiKytherA]

I understand there's core development work underway to support CUDA better but I have searched the forum and cannot find any reference to Vulkan API which can also be used for compute tasks, therefore possibly leveraged for expanding the list of F@H supported devices.

Specifically please look into this: "For example, the open source clspv compiler and clvk API translator enable OpenCL applications to be run over a Vulkan run-time. This gives OpenCL developers significant flexibility on where and how they can deploy their OpenCL applications." - https://www.khronos.org/opencl/

Initial specifications stated that Vulkan will work on hardware that currently supports OpenGL ES 3.1 or OpenGL 4.x and up.[175] As Vulkan support requires new graphics drivers, this does not necessarily imply that every existing device that supports OpenGL ES 3.1 or OpenGL 4.x will have Vulkan drivers available.

Vulkan 1.1 with higher efforts is supported by the newer lines in Hardware like Intel Skylake and higher, AMD GCN 3rd and higher, Nvidia Kepler and higher. AMD, Arm, Imagination Technologies, Intel, Nvidia and Qualcomm supports actual hardware since second half of 2018 Vulkan 1.1 with own drivers. Mesa 18.1 supports with RADV and ANVIL driver AMD and Intel hardware. Actual state in Mesa 3D of RADV and ANVIL see Mesamatrix.[176]

Android 7.0 Nougat supports Vulkan 1.0.[177] The software was released in August 2016.[178] Vulkan 1.1 is supported in Android 9.0 Pie.[179] Vulkan 1.1 support is mandatory for 64-bit devices running Android 10.[180]

Vulkan support for iOS and macOS has not been announced by Apple, but an open-source library exists which provides a Vulkan implementation that runs on top of Metal on iOS and macOS devices.[25]

Source: https://en.wikipedia.org/wiki/Vulkan_(A ... patibility

Current release is Vulkan 1.2:
Full information and SDK - https://www.khronos.org/vulkan/

[PantherX]

A quick search indicates that while Vulkan can run OpenCL code, the primary purpose of Vulkan would be for OpenGL and rendering, not pure compute:
https://community.khronos.org/t/opencl- ... mpute/7132
https://www.phoronix.com/scan.php?page= ... terop-2019

Also, if the performance is the same between Vulkan and OpenCL, why maintain two FahCores for GPU making it twice the work? Historically, it was a challenge and then it moved to a single FahCore for all GPUs and now there's a possibility for CUDA based FahCore since might be able to provide a measurable boost in performance.

[NRT_AntiKytherA]

A third core would not be necessary, unless I read it incorrectly it is a case of include a couple of extra lines of code into the existing compiler for the opencl core, then It will work with both native opencl and Vulkan API. Vulkan API is not just a replacement for OpenGL aimed at gamers and 3D modelling it is meant to be used for compute acceleration too. In the case of F@H it would provide WU computation for currently unsupported hardware mentioned in my first post. I'll leave it up to the devs if they want to look into this further or not but I feel it would be churlish not to.

Additionally, I'm not saying targetting CUDA is wrong since I have CUDA capable hardware and my machine will benefit from that too. I just wanted to know if Vulkan was being considered and if the devs weren't aware point out the opportunity.

[bruce]

When (I guess I should say IF since nothing has been released) CUDA is supported, I have no doubt that NVIdia GPUs will perform better. That will change nothing for AMD GPus.

I do not know the details regarding Vulkan. I'll refer it to development to investigate. If Vulcan improves the graphics that OpenGL previously supported, that won't matter to FAH ... except perhaps for FAHViewer. If Vulcan provides the needed support equivalent or better than OpenCL 1.2, that might simplify or even improve things for AMD GPUs.

[NRT_AntiKytherA]

Vulkan provides compute acceleration support to more than just AMD and NVIDIA hardware which is kind of the point here. It's not so much about improving the performance of existing hardware, rather expanding on what can be used.

[foldy]

The only thing were Vulkan could help is for android mobile GPUs. All other GPUs by AMD/Nvidia/Intel run fine with OpenCL or CUDA.

[NRT_AntiKytherA]

There are also an increasing number of ARM powered computers coming to the market which will benefit from this and also folding with Intel GPU and OpenCL is sketchy to say the least from the threads on this forum. Enabling support for Vulkan libraries which are shipped as standard now with most of the linux distributions with newer ISO images I've tried in the last 6 months will save end users a lot of faffing about trying to get the client to work regardless of which vendor's GPU is installed on their machine.

[MeeLee]

I thought vulcan was specifically used to optimize 3d graphics performance (GPU computations), not compute?

[foldy]

Intel GPUs are not supported because of extra validation work needed for a new architecture and Intel iGPU are too slow. They maybe can be used as coprocessor for CPU folding in latest gromacs core - maybe that is an option for FAH.

[JimboPalmer]

I have no facts on this, but I have both opinion and snark.

F@H is pulled two directions, there are proprietary packages that maximize performance in an OS or on a vendor's hardware. These will increase PPD but also mean multiple client so update and keep in sync. A given vendor is incentivized to maximize performance as that locks users into their brand.
CUDA for Nvidia and Metal for Apple are examples.

An industry standard allows write once, run everywhere code at a reduced PPD. Nvidia has no incentive to make OpenCL as efficient as CUDA. Apple has no incentive to make OpenCL as supported as Metal. (The same iwould be true of Vulkan)

F@H has spent years going the open standards way. It both speed up development and reduces programming costs, but yields less PPD

If Nvidia and Apple could pony up programming resources, I feel sure F@H could be swayed back to proprietary interfaces.

In the past, ARM and Intel offered a technical problem, Points is an Integer, how do you award a fractional point? Sony solved that by ignoring points in the Android client.

[bruce]

Intel GPUs are not supported because of extra validation work needed for a new architecture and Intel iGPU are too slow. They maybe can be used as coprocessor for CPU folding in latest gromacs core - maybe that is an option for FAH.

You (and others) make some really good points. Updating the GROMACS core to support the iGPU as a co-processor would work better as measured by PPD than trying to support it as a stand-alone OpenCL GPU. I wonder if either of those approaches would meet the validation standards imposed by the Mac.

[JohnChodera]

@NRT_AntiKytherA: Interesting suggestion---I wasn't aware of Vulkan!

The first step would be to get Vulkan support into OpenMM itself---would you mind opening an issue in the OpenMM issue tracker to suggest this?

https://github.com/openmm/openmm

Thanks!

We have more exciting news about core22 coming soon...

~ John Chodera // MSKCC

[NRT_AntiKytherA]

Thanks for the interest John, I have opened an issue

https://github.com/openmm/openmm/issues/2710

[bruce]

Khronos is combining the features of OpenCL and OpenGL into a single product. The addition of OpenGL functionality does not interest me because I don't depend on FAHViewer (though others do). From what I read, Vulcan 1.1 supports Kepler which (presumably) means that it does not support Fermi. Does anybody still have a Fermi GPU? (yes) Are you ready for FAH to tell you we no longer support your GPU? (We're pretty close to making that decision unless CUDA provides that support which is unclear to me.)

[MeeLee]

Fermi is a 10 year old architecture, all the way up to GTX 600 series; ready to be retired.
Nvidia is thinking of stopping support for these older GPUs anyway, as they barely support 1080p video, don't support modern (youtube) codecs.
A GT(X) 700 series, at almost 7 years, is old enough, and performs pale compared to modern GPUs.