Not to dissuade you from graphics hacking in CL (it's a lot of fun!) but this isn't what Vulkan is for.
It's a graphics API that gives you more explicit control over synchronization, buffering, and resource sharing. There's still many reasons to prefer OpenGL (for which there are good bindings in CL already and could use more contributors!).
If you're just the curious sort and want to know more then by all means... it will be a tough battle if this is your first delve into graphics programming.
I would disagree. With spirv we have for the first time a proper language agnostic compilation target. Likewise we have much lower level primitives upon which we can build idiomatic high level abstractions. Existing efforts built upon OpenGL and GLSL are very hairy due to the fact that we are trying to build high level abstractions on top of already high level (and very opinionated) abstractions.
I find this to be a very exciting opportunity, not just for CL but for many other languages, to have a framework that feels like belongs in the host language, not just fugly ffi wrappers.
Isn't CL a perfectly reasonable thing to interface with Vulcan? Given its power, and things like compile macros, it could be possible to generate versions of some functions (array-oriented ones, for example) that would run on the GPU using SPIR. Other interfaces AFAIK don't support passing code like this (CUDA likes pre-compiled code (can it receive source texts?), OpenCL AFAIK accepts source code but you have to generate text and the driver has to compile it again.).
You might want to try CEPL and Varjo for an interesting take on this in the OpenGL/CL world. Programming in CL often feels like having a powerful compiler under the hood and an amazing debugger to start with.
I'm not suggesting you cannot write a Vulkan API library in CL -- work has already begun in that direction: join in on #lispgames if you're interested.
It's just not going to be the ideal API to learn if you're new to graphics programming when OpenGL is already here, is rather well understood, and has plenty of supporting libraries and extensions for most needs.
Could Vulkan be the opportunity to build a small and simple API for people to learn graphic programming?
I did learn OpenGl 10 years ago but it was already a big mess and each time I were searching for some information I could only discover mountains of hacks. I'm quit sure it's worse now.
OpenGL is much better these days and if it's your first foray into graphics programming learning WebGL is not a bad start IMO. You might need to use a browser that can support some of the OpenGL ES features (WebGL extensions) like VBO's and such but you can get really far that way.
Vulkan is not the right choice if you're just getting started unless you're already motivated and intensely curious (ie: already have some decent exposure to OpenGL, multi-threading, and are curious to know more).
Learning graphic programming through Vulkan is like learning to implement quick-sort using assembly language.
Sure, it can be done, but it's most likely to lead to tons of frustration and abandonment.
I was pretty good using classic OpenGL (before shaders), and writing a 100% shader based simple example was quite some work, mostly spent understanding how 4x4 matrices and graphics are related.
I expect for most typical programmers for that to be the hardest part, understanding how pixels emerge from a long pipeline of operations on 3 or 4-vectors and 4x4-matrices
I think porting three.js over to Vulkan (and node.js if it isn't available on desktop yet) would be a big win. You probably won't see much performance gains over plain GL given that it's a javascript library, but it will be a good learning experience.
ahh, yeah i hear you. I just never got into it and I understood the Vulkan announcement to be the latest edition to what OpenGL already brought. Cool, I think I will definitely explore CL bindings with OpenGL. Thanks!
