pouët.net

Are there any demos based on Vulkan yet?

Yeah, Kusma's and Musk's recent stuff is VK-based afaik. The fact that both coders have the same letters in their names is probably not of significance though.

Aurora uses Vulkan, and the source code is available if you're interested.

Thanks, all of ye.

Catalyst just released on at @party, it'll get posted within the next few hours when I get the @party releases up.

Everything we've released under Catalyst has been Vulkan based. :)
("Sands of Time", "Tangrams", and now "Wild")

what's the value proposition of Vulkan demowise?

I´d say multiplatform development combined with a good multithreaded rendering performance.

Demos are rarely CPU-limited though.

this. to build something based on vulkan (or d3d12 for that matter) requires tremendous extra effort that almost certainly won't pay off in the end in terms of actual rendering performance improvements in typical demo scenarios.

especially considreing the fact that most demo engines don't even bother to optimize their geometry or to implement some form of batching in the first place.

if you need to draw many many moving things look into instancing (available in dx9/gl2 and up) as an alternative.

if you can't max out DX11 or GL4 - don't bother with vulkan just yet (and there are a lot of GL extensions which help to reduce driver overhead even more).

@guardian: pretty much the same as making your own engine in the first place ;)

Yeaj, bragging rights and points for (relatively) pointless technical merit. For many people, that's what the demoscene is all about.

@kusma: I didn't mean to dismiss your efforts. It's just that if I understood correctly, demos don't max out draw calls

Vulkan is useful for more than just CPU limited workloads. It exposes low level HW features like subgroups and push constants which allow you to do some cool tricks in your shaders. It also gives you a lot more control over how your work is scheduled on the GPU. You can use that control to overlap complementary parts of your frame and improve performance.

My favorite part is the implementation consistency across platforms compared to OpenGL and the ability to pre-compile your shaders to SPIR-V so you don't have to attempt to deploy on another system only to find out your GLSL is out-of-spec/invalid. Also, I really like the tool ecosystem for Vulkan. It's got some good frame profilers and debuggers available and the validation layer is another huge plus as well.

Yes, most of the benefit is performance (arguably a lot of unnecessary micro-optimization in many cases), but I love that kind of stuff so that's why I choose to make demos with it! :)

guardian: I didn't feel the effort was dismissed, no worries. I just wanted to point out that for some of us, the way to the goal might actually be worth it on its own. I want to do things that I find interesting, not necessarily what the shortest path to the end-result is.

impakt: word.

Whenever I get into this topic, people seem really excited and somehow expecting Vulkan to change everything. I usually recommend people staying away. I'm not saying that it's bad, I did enjoy and had nice moments when things just worked.

I'll give a short summary of my experience:

For Archeoptical I payed about 3 days of work to get a triangle on screen up and running, and then I didn't have much time for anything else, ended up party coding until the last hour before the compo block started. And all this just for a vertex shader demo, something that can be set up with three.js under an hour.

I also had an incident with the compo machine not being able to run fullscreen, so party coding included a lot of back and forth between me and the compo team, trying to debug, and ended up implementing borderless/fullscreen modes so that we can choose one on the compo machine.

For good part:
- the shaders had no issue running on either Nvidia, Intel or AMD without any tweaks (though Searching Through The Voids does have issues with older drivers, and I am doing some not very traditional handling of triangles)
- I never had a moment of "black screen" or I don't know what is happening and why things are not showing on the screen moment due to some flag being set in the API. (which actually did crush my motivation and prevented me from making a release a while ago)
- I like working with the separate command line tool which compiles my shaders, I've set up some scripts that recompile on edit.
- debugging is much easier thanks to the validation layers and the very nice logging support.

As for the working with the API itself:
- you are going to fill structures and structures of data and submit it to the device.
- you are also going to spend time on synchronizing between the commands.
- the workflow is very similar to windows driver programming, the only thing missing is the BSOD whenever you have an error.
- the learning curve is very steep as you need to be familiar with most structures to get things working on the screen.

So again, unless you are comfortable with threads, asynchronous programming, low level C programming (similar to working with drivers/kernel code) then stay away from Vulkan and stick to OpenGL or

When I saw first talks about Vulkan, I was pretty much convinced that this thing is for me. Even now sort of I believe that, but I also realized that I requires a lot of time and effort to get anywhere. It's a long term investment that might not pay off in the end. I am both excited and scared of the next Vulkan demo I make.

Yeah, in theory. In praxis only some top 3 demogroups (fairlight, farbrausch) actually have a multi-threaded engine that could make use of that.

but it's great that more people are interested in this topic. would definitely be nice to see some more stuff making real use of multi-threading and vulkan.

I have some code here that manages to fully saturate the 4 cores of my oldish i5, peaking at ~65000 draw calls (frustum-culled, non-instanced) on DX11. Can your vulkan code do better?

Last I talked to Smash he said his engine was single-threaded because there was nothing running on the CPU.

gargaj: oh, then i might have remembered that wrong. from smash's "fairlight rendering secrets" preesentation i had the impression that the scenegraph traversal he uses to build the rendering jobs was threaded. Might have mixed that up. But that stresses my point even more :)

Here's a Fairlight rendering secret for you: None of their demos actually render anything, it's just all clever precalc.

Nope! In fact, my most recent demo Wild comes in at a whopping draw call count of zero! ;)

It's not always so simple as which can do the most draw calls and such. I just change my own engine to threaded, and it CPU use is near zero (it's literally 1 compute function called per frame!)

Despite that, threading it gives a performance benefit - it's complicated, but tying rendering to the display refresh means the GPU is inactive between frames, and if it's rendering at <60fps that leave performance on the table. Instead I render frames on another thread, and in the actual render loop just blit the image to screen.

I also want to set this up so it can use multiple GPUs - my box has two, many machines have e.g. an integrated intel thing and a fast discrete GPU so why not? :) I'm not using Vulkan, but Metal for this (targeting iOS + macOS). Metal is also lower level than OpenGL, perhaps not so low level.

Stuff I've learned doing this kind of stuff:

- These lower level frameworks are more flexible. That lets you do stuff you couldn't before, or do the same stuff in new, better ways. To me that's worth more than better performance - and actually doing stuff in new ways often improves perf WAY more than lower driver overhead!

- Productivity matters. I had to learn some Metal for work, but what I soon noticed is that API is really nicely designed. It's actually less code than GL for most things, and often easier. It's more fun as a result, and I get more done.

Vulkan looks pretty bad on this side from what I've seen - tons of boilerplate to get anything done.

- Tools matter massively. Once you've used decent GPU side tools (profiling, frame capture, shader debugger etc.) you don't want to go back. I'd choose a bad API with good tools over a good API with none.

Those gaps in the GPU utilisation I saw that made me realise I'd get better perf with threaded code? Just ran the profiler, zoomed in on the chart and saw them.

In the end it's worth evaluating if you're going to *need* the flexibility and performance upgrade for what you'll be rendering. If not, save yourself some time. It's an API, not something that'll get you hired at NASA.

Unless you have another motive for using a low-level rendering API of course.