From what, little, I've read about Vulkan it may only have an advantage over OpenCL in terms of performance. Maybe it could lead to a single universal GPU app across all hardware vendors?

I think our buddy Jason has been working towards that goal....
But, given the immense differences between the hardware and optimizations available, I think he has taken on a yeoman's task.
And perhaps impossible to fully achieve.

Sortof, current longer term roadmap, under construction, involves stripping back to an app chassis that does nothing (which is definitely achievable, lol), but changes little. This will have any number of points to bolt on whatever you want ( 'standard' bits included ), as long as it produces complete valid results.

For me the key there is figuring out which bits are least likely to need to change much for different kinds of devices and new hardware that isn't out yet.

General gist is maintaining a single app that supports all the unknowns is not practical (as with the standards cartoon), and neither is maintaining/developing a new target application for every situation.

In the past, app level differences have been manageable enough with a few builds. This has worked well, but lost the ease of integration as more platforms and new technologies come online. You tweak for some situation it breaks somewhere else.

So the trick is to standardise what parts 'should be', and slap a finer grained plugin architecture over the top for the bits that do the work. Fortunately there are plenty of examples of cross platform plugin architectures to learn from.

Having both Petri's dedicated Cuda Optimisations, plus use cases where generic baseline code works better, is the powerful motivator to be able to have our cake and eat it too, without wrecking anything.

Hardest part is going to be figuring out what tools/information the user, client, and app itelf needs to self configure to suit your needs as best as possible.

In the same vein, there are people that drop their cars and put obnoxious spoilers on them. That should probably be allowed as long as there are safety checks to pass.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

ehm, anythings new ? i mean almost three weeks wend by the last drivers release !?

---

ehm, anythings new ? i mean almost three weeks wend by the last drivers release !?

For me, the focus is on finding time to go through Cuda 8 early access testing, so am bound to the development driver (362.19) for the time being. [At least until the 29th when early access testing closes)

Unfortunately this driver doesn't include the vulkan ICD (confirmed by attempting to run the Vulkan SDK demos, that previously worked on whatever I was last running (probably an early vulkan development driver)

Game developers are estimating it'll be 6-12 months before Vulkan starts to gain a lot of traction there, as game engines incorporate it for cross platform.

For our, mostly compute oriented purposes, a lot will depend on some latency comparisons after Cuda8 release, i.e. standard OpenCL Vs Vulkan-OpenCL-frontend Vs Various Cuda versions under dedicated tests. Vulkan's main design strength is supposedly its capability for low latency, and promises to work in a lot of situations that Cuda and vanilla-OpenCL don't at the moment.

If it lives up to those promises (To be determined) then it'll end up useful here, otherwise OpenCL and Cuda are likely to remain better choices.

Most likely MB Cuda will eventually support all 3 and more options, though the exact mix is going to depend on how the technologies settle down, meanwhile incorporating already contributed Cuda optimisations in a widely compatible way.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.