http://gpuopen.com/gcn-shader-extensions-for-direct3d-and-vulkan/
Just in case someone else missed this.
No need to wait for SM 6.0 :D
http://gpuopen.com/gcn-shader-extensions-for-direct3d-and-vulkan/
Just in case someone else missed this.
No need to wait for SM 6.0 :D
Thanks for the heads up :)
For those who haven't seen this stuff before, Intel have also had D3D shader extensions for a while, e.g. see IGFXExtensionsHelper.h/cpp and IntelExtensions.hlsl in this:
https://software.intel.com/en-us/articles/programmable-blend-with-pixel-shader-ordering
As a side note, I feel OpenCL is going to be legacy very soon.
Really? Doesn't OpenCL 1.2 and beyond support SPIR-V, like Vulkan?
Maybe on Windows, with SM 6.0 and DXIL if someone will put more attention on DirectCompute (what about a new and improved version of C++AMP?)..
I think OpenCL will stay - it has most of its applications outside games / graphics. Or are there any games using it?
Personally i liked OpenCL a lot more than GLSL for compute. Easier to use, more solid programming - less 'just a shader', and it was always faster on any hardware i've tested.
SPIR-V already draws a line between OpenCL and Vulkan-Compute:
"Execution models include Vertex, GLCompute, etc. (one for each graphical stage), as well as Kernel for OpenCL kernels."
I don't know if there are technical or business reasons behind that.
Because there are no plans for OpenCL <-> Vulkan data sharing, we have no choice anyways.
But those extensions are exactly what i want and there should be no big reason to look back to OpenCL.
Really? Doesn't OpenCL 1.2 and beyond support SPIR-V, like Vulkan?
Maybe on Windows, with SM 6.0 and DXIL if someone will put more attention on DirectCompute (what about a new and improved version of C++AMP?)..
It is my understanding that extension is a bit sporadic in support. OpenCL already has some quirks in the API and the main implementations (AMD) are... I don't trust them. API aside, even the compiler varies considerably from version to version (oddly, the compiled blobs are surprisingly portable); nonetheless the article doesn't mention OpenCL, or Spir-V for the mattter. In the OpenCL forum multiple people have expressed interest in a 'low level no fat added API'. Honestly CL looked more like a prototyping thing than a production API to me. Maybe I'm just reading a bit too much between the lines.