back
36 comments
The author's earlier project, learnopengl.com, helped me catch up to modern OpenGL after having been away from OpenGL since shortly after it became Open. (I learned iris GL first.) Looking forward to the Vulkan version.
Yeah it's a great resource. I'm eagerly awaiting this Vulkan version
I found the learnopengl.com web site to be an amazing resource, it is of similar quality to a good book! Thanks Mr. De Vries.
Oh, it's the same author? I'm definitely looking forward to this, then.
Right now Google Analytics is loaded but there is no tracking code configured! Not the biggest fan of trackers but definitely would want that configured if my post would be on the HN front page.
Somewhat disappointed that it's yet another book about Vulkan graphics.

I want Vulkan compute.

Why would you want that exactly rather than CUDA or OpenCL?

Although I haven't written a compute shader yet, compute in Vulkan looks trivial to use once you have waged your initial battles against the rendering pipeline setup. Most of the complexity with Vulkan lies in understanding descriptor sets, pipeline layouts and pipeline objects. I find that the Vulkan interface is remarkably consistent once you get over the initial - and substantial - hurdles.

Because Vulkan is cross-device, cross-platform. I dont want to tied to the Desktop or to Nvidia.

Vulkan Compute shaders work in recent Android devices and on every Windows/Linux PC that has a <5 year old dedicated GPU. And for iOS/OSX there is an interop layer in the works that will enable Vulkan over Metal.

> Vulkan Compute shaders work in recent Android devices

Actually no.

Vulkan is an optional API, so unless we are talking about Samsung and Google flagships phones, there is no guarantee of it being available.

So far Google hasn't even bothered to add it to the dashboards.

For compute, only Renderscript is required.

Apple has direct support for OpenCL. Why would you want to use a Metal wrapper instead?
iOS doesn't support OpenCL
Oh, I did not know that. Still, using Vulkan strictly for its compute shaders sounds weird to me.
OpenCL is merging into Vulkan: https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-M...
It is unclear to me whether the target of the statement is runtime interop between OpenCL and Vulkan or something else, like implementing (a subset of) OpenCL on top of Vulkan. I have not seen statements recently from Khronos that would hint at the later.
>The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute.

From the article suggests at some point OpenCL is going to run on top of Vulkan.

If you ask me, the article is trying to interpret intentionally vague marketing speak in a very specific way. But that is only my opinion.
You're looking in the wrong spot, Vulkan compute is there to support the graphics. If you want pure compute, opencl/cuda are your best options.
Vulkan compute is super simple compared to vulkan graphics. In the graphics you have to consider renderpasses, tons of GPU state, and whatnot.

In compute you just dispatch kernels and put barriers to prevent race conditions. Pretty much like OpenCL Out Of Order queues except the arguments are passed via descriptor sets rather than given individually.

Well the author did say “if you have a different vision, or opinion, about what Learn Vulkan should be, don't hesitate to contact me as nothing is set in stone yet”, and while I think that may have been primarily about the book/website combo I think now is a perfect time for you to contact the author (contact details on the page) and ask them about including Vulcan compute on the site.
I was really hoping to live long and prosper :-/
Well, I just bought OpenGL SuperBible and was eventually going to go about making a simple game engine from scratch and learn the linear algebra required for graphics engines.

Would anyone still suggest learning OpenGL/building a graphics pipeline or just proceeding on to Kronos's Vulkan?

OpenGL is still very relevant, and it works on more hardware than Vulkan. You can get very good performance out of OpenGL if you try to follow AZDO practices, and it'll be good practice, should you later decide to learn Vulkan.
opengl, possibly even something higher level. Vulkan has a lot of low level stuff thats just tedious, esp for a beginner
+1, if you really care about learning just the math OpenGL is a lot simpler from an API perspective. Once you start caring about performance then dig into Vulkan to understand the various render commands/pipelines/etc.
I would also assume that OpenGL is better supported on multiple platforms, by virtue of having been around much longer. You'll also be able to get more help if you run into issues with OpenGL.
I wonder if there's something for people who are not game engine developers, but they need some 3D visualization for e.g. science.

In my experience it is a pain point.

This site has OpenGL tutorials focused more on visualization: https://open.gl/introduction
While the final rendering code for visualizations may look very differently from game rendering code, the underlying techniques are exactly the same unless you are doing some really hard out of core stuff or something else that is really extreme. So I do not see the point for separate resources, to be honest. Visualization is much more about the pipeline that you execute before you start rendering.
Visualisation usually has much much smaller scope than game development. So frequent vs infrequent developer problems apply here, as in https://news.ycombinator.com/item?id=16561901

Any new concept or tool dependency, e.g. 3D editor or shader, is a pain point here since it increases project compexity superlinearly.

Also, many "game engines" which aim to speed up development impose a lot of constraints on client code. For example, they're not compatible with non-GL windows from same process or with external event loop. I made a mistake trying to use a few of those and impedance mismatch was really painful. Had to divest to plain OpenGL.

I mean, yeah. If you try to use a framework intended for games, it won't be a great fit for other use cases. Look into Open Scene Graph if you want a higher level API that isn't as opinionated towards games.

Vulkan isn't a higher level API though, which might be why you and the other guy are kind of talking past each other.

I do not think I understand your point at all.

Realtime rendering is independent from game engine implementations and especially from content creation pipelines. If you are looking at resources that explain how to use game engines then you're looking in the wrong place. What you want is resources that teach how to write rendering code.

They probably should not be dealing with all the pain of Vulkan at all.

I've been playing with Monogame (used to be Microsoft's XNA) lately, which is cross-platform and very easy to get up and running with.

As I have been explained, Monogame is not even a game engine, rather a framework for writing game engines.

That's a particularly poor fit for 3D visualisation. No primitives, expectations of bringing your own shaders, inability to work with Forms in the same process...

Great, that would be very helpful for those who want to learn Vulkan without delving into OpenGL first.
You can learn the basics of modern OpenGL and the related modern toolkits in very little time. That knowledge directly carries over.
Sure, I didn't mean it's not useful.