3 ms·

>It's much more low level. And there's no strong type safety remaining. It seems from the Vulkan Language Ecosystem graphic that they expect new languages to b

by tormeh 12y ago

>It's much more low level. And there's no strong type safety remaining. It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.

datenwolf 12y ago
> It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level. Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism. Also typesafety regarding the buffer contents can be mapped into a Hindley-Miller system as well, by looking at the tuple `(memory handle, descriptor)`; in Haskell (e.g.) that'd nicely map into a type constructor.
- pjmlp 12y ago
  I think he/she meant targeting SPIR-V with your language of choice.
  - datenwolf 12y ago
    SPIR-V is on a completely different level. The Vulcan API is called by the binary running on the CPU. The binary generated from SPIR-V is executed on the compute device, which in 99% or all cases that Vulkan is concerned with will be the GPU. In the same way you don't use GLSL to program OpenGL, you don't use SPIR-V to program Vulkan. GLSL/SPIR are to OpenGL/Vulkan what browser-side JavaScript is to a webserver.
    - pjmlp 12y ago
      Sure, but like PTX/CUDA it will mean you can write shaders in other languages with a better hardware mapping, instead of compiling them to GLSL/OpenCL C source, which is currently one advantage of CUDA.
      - datenwolf 12y ago
        Oh yes, I've been waiting to do that with OpenGL for a looong time. As a matter of fact I preferred working with the ARB_vertex_program and ARB_fragment_program extensions; I even designed (but never fully implemented) a custom, Lisp inspired language that compiles into the ARB_???_program assembly.

by tormeh 12y ago

datenwolf 12y ago

> It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level. Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism. Also typesafety regarding the buffer contents can be mapped into a Hindley-Miller system as well, by looking at the tuple `(memory handle, descriptor)`; in Haskell (e.g.) that'd nicely map into a type constructor.

pjmlp 12y ago
I think he/she meant targeting SPIR-V with your language of choice.
- datenwolf 12y ago
  SPIR-V is on a completely different level. The Vulcan API is called by the binary running on the CPU. The binary generated from SPIR-V is executed on the compute device, which in 99% or all cases that Vulkan is concerned with will be the GPU. In the same way you don't use GLSL to program OpenGL, you don't use SPIR-V to program Vulkan. GLSL/SPIR are to OpenGL/Vulkan what browser-side JavaScript is to a webserver.
  - pjmlp 12y ago
    Sure, but like PTX/CUDA it will mean you can write shaders in other languages with a better hardware mapping, instead of compiling them to GLSL/OpenCL C source, which is currently one advantage of CUDA.
    - datenwolf 12y ago
      Oh yes, I've been waiting to do that with OpenGL for a looong time. As a matter of fact I preferred working with the ARB_vertex_program and ARB_fragment_program extensions; I even designed (but never fully implemented) a custom, Lisp inspired language that compiles into the ARB_???_program assembly.