Vulkan is not OpenGL or a combination of OpenCL and OpenGL.
Vulkan is a new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms.
Vulkan is not a direct replacement for OpenGL, but rather an explicit API that allows for more explicit control of the GPU.
https://github.com/KhronosGroup/Vulkan- ... _vulkan.md
Targetting CUDA support but what about Vulkan API?
Moderators: Site Moderators, FAHC Science Team
-
- Posts: 107
- Joined: Sun May 10, 2020 11:50 pm
-
- Site Admin
- Posts: 7937
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Pro 2.8 quad 12 GB smp4
MacBook Pro 2.9 i7 8 GB smp2 - Location: W. MA
Re: Targetting CUDA support but what about Vulkan API?
Yes, you can repeat the marketing speak from the Kronos site, but looking into this a bit so far I and others have noticed an emphasis on development for faster video rendering, not the compute type work that F@h is doing with OpenCL. So, yes, it is not a direct replacement for OpenGL, but F@H only uses OpenGL for rendering video in FAHViewer. It is not clear how good of a replacement Vulkan will be for OpenCL given the current emphasis.
iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
-
- Posts: 107
- Joined: Sun May 10, 2020 11:50 pm
Re: Targetting CUDA support but what about Vulkan API?
Respectfully the same can be said for others posting in this thread too who may not have bothered reading everything in the topic. With the exception of John Chodera self proclaimed knowledgeable contributors to this thread have been repeating the same incorrect assumptions with clearly dismissive attitudes. THAT is what prompted me to try and explain it again in simpler terms but it clearly did not work.
Looking into something 'a bit' isn't really sufficient to form an educated opinion and shut an idea down but collectively that is what you have all managed to do here. The emphasis you and others claim to have noticed is solely derived from your collective looking into Vulkan API too briefly.
If I repeated certain facts in different ways it was only to try to educate people repeating the same incorrect assumptions and statements about Vulkan API. Clearly this has struck a nerve and if it is a problem then I now know for future reference not to engage in such discussions here.
Looking into something 'a bit' isn't really sufficient to form an educated opinion and shut an idea down but collectively that is what you have all managed to do here. The emphasis you and others claim to have noticed is solely derived from your collective looking into Vulkan API too briefly.
If I repeated certain facts in different ways it was only to try to educate people repeating the same incorrect assumptions and statements about Vulkan API. Clearly this has struck a nerve and if it is a problem then I now know for future reference not to engage in such discussions here.
-
- Site Admin
- Posts: 7937
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Pro 2.8 quad 12 GB smp4
MacBook Pro 2.9 i7 8 GB smp2 - Location: W. MA
Re: Targetting CUDA support but what about Vulkan API?
Not shutting down your idea, but you have not made any case that is more than "marketing speak". Have you any direct experience using Vulkan for computation, or can you point to actual use cases? Like I said, so far all I have seen is on the video rendering side, including a few games and other software that processes video for display or otherwise.
So Vulkan may be investigated further and possibly added to the supported APIs in the software that is used in creating GPU folding cores. If it improves things enough to justify the expenditure of time, they will use Vulkan for F@h. But even if it is added to OpenMM, that is no guarantee of it getting used.
But so far the only nerve that appears to have been struck is your own. People here on the forum have seen many "New Things That Will Greatly Enhance F@h" touted, only a few have actually worked well. Way too early to determine where Vulkan will fall on that spectrum. So there are a number of skeptics here who are going to ask for more than what you have posted.
So Vulkan may be investigated further and possibly added to the supported APIs in the software that is used in creating GPU folding cores. If it improves things enough to justify the expenditure of time, they will use Vulkan for F@h. But even if it is added to OpenMM, that is no guarantee of it getting used.
But so far the only nerve that appears to have been struck is your own. People here on the forum have seen many "New Things That Will Greatly Enhance F@h" touted, only a few have actually worked well. Way too early to determine where Vulkan will fall on that spectrum. So there are a number of skeptics here who are going to ask for more than what you have posted.
iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
Re: Targetting CUDA support but what about Vulkan API?
Yeah, Vulcan is basically an alternative of OpenGL, or Direct X.
Not OpenCL.
It would be quite difficult to make a more efficient program than OpenCL, since they're already in their 3rd iteration (7 if you count the minor upgrades).
Not OpenCL.
It would be quite difficult to make a more efficient program than OpenCL, since they're already in their 3rd iteration (7 if you count the minor upgrades).
-
- Posts: 107
- Joined: Sun May 10, 2020 11:50 pm
Re: Targetting CUDA support but what about Vulkan API?
My god people here are flipping lazy. Skeptic or not, if you really want examples, please brush up on your google/duckduckgo/whatever skills. They are literally a few clicks away. It supports Rust, C, C++, Java, Golang among other programming languages. Your forum rules say to moderate the length of information and posts, I interpret that as not overloading with information and allowing members to look subjects they are vaguely interested in up for themselves.
Anyhow a basic example of headless computation C++
https://github.com/SaschaWillems/Vulkan ... teheadless
Please honour my request in your PM Joe_H forthwith.
Anyhow a basic example of headless computation C++
https://github.com/SaschaWillems/Vulkan ... teheadless
Please honour my request in your PM Joe_H forthwith.
-
- Posts: 1996
- Joined: Sun Mar 22, 2020 5:52 pm
- Hardware configuration: 1: 2x Xeon [email protected], 512GB DDR4 LRDIMM, SSD Raid, Win10 Ent 20H2, Quadro K420 1GB, FAH 7.6.21
2: Xeon [email protected], 32GB DDR4, NVME, Win10 Pro 20H2, Quadro M1000M 2GB, FAH 7.6.21 (actually have two of these)
3: [email protected], 12GB DDR3, SSD, Win10 Pro 20H2, GTX 750Ti 2GB, GTX 1080Ti 11GB, FAH 7.6.21 - Location: UK
Re: Targetting CUDA support but what about Vulkan API?
TLDR … Really sorry you have been made to feel this way NRT_AntiKytherA …
I haven't been active for a bit but feel the need to post "something" here … I am not deeply technical - nor do I desire to be … I understand some of the concepts at a rudimentary basis but for the most part what I care about is not "how something is done" but rather that it gets done in an effective way that someone else understands
I always remind myself that this forum is a volunteer managed support board that tries to assist other folders with issues/problems and provides some form of focal point for discussion of various topics relevant to FAH … Some of these discussions, by nature of the type of issues they cover, can get passionately involved/heated and questions/suggestions and answers/responses do as usually happens in electronic media get confused/out of control sometimes - through no malice on anyone's part - it just happens … ARM, Android, Pi, Laptop iGPUs, GPU work levels, Stats granularity all spring to mind
So here we have another one of these scenarios … We have NRT_AntiKytherA who has recently joined the forums and who has spent a fair bit of time over a short period helping answer questions as/when possible and who has some knowledge of Vulkan and has raised a perfectly valid question based on that knowledge - and who has not liked the lack of enthusiasm/effort in research from those who have responded - and feels dismissed, aggrieved and appears quite angry about this … Which in my mind is never where the forums should strive to be - and that they should feel the need to publicly ask the site admin to honour a request sent in a PM shows how badly this discussion has gone wrong
So before I go any further … Sorry NRT_AntiKytherA … The nature of this bulletin board like so many others can be such that communication fails and what might to one person be a brief response of their views can seem dismissive to another … You should not have been made to feel such and for that as someone who participates in these forums I apologise (not on anyone else's behalf - simply on mine own).
In response to this situation I have spent most of today researching Vulkan - yes, at a non technical level - and against a background of only knowing the fleetest of details about how FAH currently works - but I wanted to respect your suggestion and actually dig deeper than a few skim searches as I have the liberty to do so with my time at the moment.
Up front I need to say that, as with a number of these discussions, "expectations need to be managed" in that this forum unfortunately isn't a place where decisions and the future direction of FAH is decided - the forums are foremost about helping with FAH as it stands today (but with some short term collation of wishes/needs I'll admit) - and much of the technical knowledge and pretty much all of the decision making is far removed from the forum and the volunteers … Yes, there are researchers who post and try to explain some stuff, but actually they aren't for the most part the decision makers either … The GitHub acts as some form of folder requests for enhancement portal - but even that isn't the right place for many of the "new ideas".
OK … So on to my understanding about Vulkan … and this it not a technical one, simply my speed reading of a fair bit of literature (like most of the Kronos Website, their news bulletins, various discussion on various other boards, blogs, etc. wherever I could track down mentions - and there are a few tbh) massively over distilled into just a few points which can't really do the subject justice but is the best I can do - and I fully accept that you may well not agree with them but this is how I read the current state re Vulkan and OpenCL:
1) Whilst Kronos themselves a few years back made press statements that indicated OpenCL and Vulcan were to merge https://hexus.net/tech/news/software/10 ... ingle-api/, and which if it happens will make all debate over which should be used/supported somewhat moot, it would seem that this never gained traction and their current position is that OpenCL and Vulkan compliment rather than compete and that OpenCL should remain servicing its existing "market" https://www.khronos.org/opencl/. The first chart following that link down - to me as a non technical person - does appear to show firstly that OpenMM, Gromacs and indeed Folding@Home are all firmly entwined with OpenCL even in Khronos' view of the architectural fabric and the next chart does imply that they see Vulkan as having a sympathetic partnership with OpenCL rather than replacing it.
2) As far as I can understand it there might be opportunities should the various hardware vendors support it for Vulkan to enable in some form should the resource cost to gained benefit balance allow (and I am sure as eggs not the person to even suggest if it does or does not) be a route to some of the edge cases where the OpenCL approach is not viable … but I may well have got that arse about as the papers I read blew my technical safety valve in many places !!
3) The timescales and market penetration/resilience/longevity of OpenCL and Vulkan would lead me to believe that OpenCL is likely to be around for a while yet (many years) and so the need to rearchitect how FAH currently works via OpenCL isn't critical or even particularly desperate at this time … and much of any change might be remotely handled by Gromacs, OpenMM or whatever Molecular Modelling Libraries the researchers choose to follow over the coming years.
4) and for me this is the kicker … It is actually quite "scary" how many of the graphics, media and parallel processing standards Khronos (as a non-profit - not an international standards body) has "control" of ,,, but then I look at the list of Members on the wiki (yeah like I should trust that !!) https://en.wikipedia.org/wiki/Khronos_Group and I realise that it is even scarier than I first thought
So in summary all I can say NRT_AntiKytherA is that people have different perspectives/expectations/understandings on their engagement with these forums … a quick skim search might have been all they had the time for and their experience of how FAH has changed over the years may lead them to be from their perspective "realistic" about the direct impact in the near terms of Vulkan … many of the people o the forums are simply firefighting installation issues, Linux GPU driver problems, stats server delays and as such something that may be a number of years down the line before it has a big enough impact to rock FAHs current boat and which they just cant directly influence is just not something they will spend that much time on.
Your question needed to be asked, and may well need to be asked again (repeatedly) over the coming months/years but I really regret that the responses came across as dismissive.
I haven't been active for a bit but feel the need to post "something" here … I am not deeply technical - nor do I desire to be … I understand some of the concepts at a rudimentary basis but for the most part what I care about is not "how something is done" but rather that it gets done in an effective way that someone else understands
I always remind myself that this forum is a volunteer managed support board that tries to assist other folders with issues/problems and provides some form of focal point for discussion of various topics relevant to FAH … Some of these discussions, by nature of the type of issues they cover, can get passionately involved/heated and questions/suggestions and answers/responses do as usually happens in electronic media get confused/out of control sometimes - through no malice on anyone's part - it just happens … ARM, Android, Pi, Laptop iGPUs, GPU work levels, Stats granularity all spring to mind
So here we have another one of these scenarios … We have NRT_AntiKytherA who has recently joined the forums and who has spent a fair bit of time over a short period helping answer questions as/when possible and who has some knowledge of Vulkan and has raised a perfectly valid question based on that knowledge - and who has not liked the lack of enthusiasm/effort in research from those who have responded - and feels dismissed, aggrieved and appears quite angry about this … Which in my mind is never where the forums should strive to be - and that they should feel the need to publicly ask the site admin to honour a request sent in a PM shows how badly this discussion has gone wrong
So before I go any further … Sorry NRT_AntiKytherA … The nature of this bulletin board like so many others can be such that communication fails and what might to one person be a brief response of their views can seem dismissive to another … You should not have been made to feel such and for that as someone who participates in these forums I apologise (not on anyone else's behalf - simply on mine own).
In response to this situation I have spent most of today researching Vulkan - yes, at a non technical level - and against a background of only knowing the fleetest of details about how FAH currently works - but I wanted to respect your suggestion and actually dig deeper than a few skim searches as I have the liberty to do so with my time at the moment.
Up front I need to say that, as with a number of these discussions, "expectations need to be managed" in that this forum unfortunately isn't a place where decisions and the future direction of FAH is decided - the forums are foremost about helping with FAH as it stands today (but with some short term collation of wishes/needs I'll admit) - and much of the technical knowledge and pretty much all of the decision making is far removed from the forum and the volunteers … Yes, there are researchers who post and try to explain some stuff, but actually they aren't for the most part the decision makers either … The GitHub acts as some form of folder requests for enhancement portal - but even that isn't the right place for many of the "new ideas".
OK … So on to my understanding about Vulkan … and this it not a technical one, simply my speed reading of a fair bit of literature (like most of the Kronos Website, their news bulletins, various discussion on various other boards, blogs, etc. wherever I could track down mentions - and there are a few tbh) massively over distilled into just a few points which can't really do the subject justice but is the best I can do - and I fully accept that you may well not agree with them but this is how I read the current state re Vulkan and OpenCL:
1) Whilst Kronos themselves a few years back made press statements that indicated OpenCL and Vulcan were to merge https://hexus.net/tech/news/software/10 ... ingle-api/, and which if it happens will make all debate over which should be used/supported somewhat moot, it would seem that this never gained traction and their current position is that OpenCL and Vulkan compliment rather than compete and that OpenCL should remain servicing its existing "market" https://www.khronos.org/opencl/. The first chart following that link down - to me as a non technical person - does appear to show firstly that OpenMM, Gromacs and indeed Folding@Home are all firmly entwined with OpenCL even in Khronos' view of the architectural fabric and the next chart does imply that they see Vulkan as having a sympathetic partnership with OpenCL rather than replacing it.
2) As far as I can understand it there might be opportunities should the various hardware vendors support it for Vulkan to enable in some form should the resource cost to gained benefit balance allow (and I am sure as eggs not the person to even suggest if it does or does not) be a route to some of the edge cases where the OpenCL approach is not viable … but I may well have got that arse about as the papers I read blew my technical safety valve in many places !!
3) The timescales and market penetration/resilience/longevity of OpenCL and Vulkan would lead me to believe that OpenCL is likely to be around for a while yet (many years) and so the need to rearchitect how FAH currently works via OpenCL isn't critical or even particularly desperate at this time … and much of any change might be remotely handled by Gromacs, OpenMM or whatever Molecular Modelling Libraries the researchers choose to follow over the coming years.
4) and for me this is the kicker … It is actually quite "scary" how many of the graphics, media and parallel processing standards Khronos (as a non-profit - not an international standards body) has "control" of ,,, but then I look at the list of Members on the wiki (yeah like I should trust that !!) https://en.wikipedia.org/wiki/Khronos_Group and I realise that it is even scarier than I first thought
So in summary all I can say NRT_AntiKytherA is that people have different perspectives/expectations/understandings on their engagement with these forums … a quick skim search might have been all they had the time for and their experience of how FAH has changed over the years may lead them to be from their perspective "realistic" about the direct impact in the near terms of Vulkan … many of the people o the forums are simply firefighting installation issues, Linux GPU driver problems, stats server delays and as such something that may be a number of years down the line before it has a big enough impact to rock FAHs current boat and which they just cant directly influence is just not something they will spend that much time on.
Your question needed to be asked, and may well need to be asked again (repeatedly) over the coming months/years but I really regret that the responses came across as dismissive.
2x Xeon E5-2697v3, 512GB DDR4 LRDIMM, SSD Raid, W10-Ent, Quadro K420
Xeon E3-1505Mv5, 32GB DDR4, NVME, W10-Pro, Quadro M1000M
i7-960, 12GB DDR3, SSD, W10-Pro, GTX1080Ti
i9-10850K, 64GB DDR4, NVME, W11-Pro, RTX3070
(Green/Bold = Active)
Xeon E3-1505Mv5, 32GB DDR4, NVME, W10-Pro, Quadro M1000M
i7-960, 12GB DDR3, SSD, W10-Pro, GTX1080Ti
i9-10850K, 64GB DDR4, NVME, W11-Pro, RTX3070
(Green/Bold = Active)