Vulkan 1.0 goes official

[frag.machine]

http://arstechnica.co.uk/gaming/2016/02 ... md-driver/

So... did anyone check this out already ? Any Impressions ?

The very idea of a low level API sounds a lot painful to learn (and even more painful to apply in real life conditions).

[Baker]

My understanding is that Vulcan is not for mortals.

And that the skill level required is someone who knows what is going on at the hardware level. (For instance, maybe the EDuke engine author who writes drivers @ Nvidia) or modern day Michael Abrash types in the graphics rendering industry/game industry.

So it's not really an end user thing, but will create a new class of specialists who can make the "impossible into possible" or "optimize something that is normally not quite fast enough" using newly exposed hardware methods or do things not exposed by shaders, etc.

/My interpretation. Possibly wrong.

[Spike]

the promise with vulkan is for more reliable drivers. if it delivers on that then it'll be easily worth it.
the other promise is multiple rendering threads (gl sucks at this. seriously sucks).
the other other promise is post process chaining to optimise bloom etc effects on mobile hardware.
also, requiring vulkan support means that people won't expect it to work with extensions via older versions of gl, despite it not being supported. hurrah for entirely separate APIs.
you can also obfuscate your glsl code a little more easily.

if none of the above are useful to you, then I wouldn't bother with vulkan, just stick with gl and abuse extensions properly.

[frag.machine]

A quick Google search brought .
At least the classic "draw a colored triangle" seems... harder than OpenGL, but nothing really impossible to understand.
In a nutshell, build a command buffer, make a draw call passing it as argument. Voila, colored triangle on screen.
Yeah, it's C++ (eeww), and you have a lot more of boilerplate code to write to handle memory among other stuff. So, not for beginners, at all.
I'll keep on eye on it, but I'll probably invest my learning time on OpenGL 4.+, there are talks about modules supporting at least partially its API for Vulkan.

To finish, a extreme case of Literally running circles around OpenGL/ES.

[revelator]

vulkan is partly based on amd's mantle

mantle is a low level api that allows pushing things directly to the gfx card, this gives quite a boost even on lower end cards.

The difference in BF4 with mantle is quite huge, so i expect vulkan will also show some nice numbers.

[Spike]

from memory (with much rearranging, hence why I gave up trying to number anything), to draw a triangle in vulkan:
*) create vulkan instance
*) create a surface from your window / etc using some system-specific extension.
*) enumerate devices, pick one.
*) query device features+support
*) create a device
*) obtain render+present queues.
*) create a swapchain
*) query swapchains images.
*) create an image view for each.
*) create a framebuffer for each swapchain image.
*) create renderpass object
*) create commandbuffer pool
*) create commandbuffers (at least one per swapchain image)
*) cb:start recording
*) create staging buffer. query memory requirements. allocate memory. bind memory.
*) map+fill staging buffer with both vertex+index data+unmap
*) create vertex buffer. query memory requirements. allocate memory. bind memory.
*) create index buffer. query memory requirements. allocate memory. bind memory.
*) cb: copy staging subregion buffer to vertex buffer
*) cb: copy staging subregion buffer to index buffer
*) cb: end commandbuffer+submit command buffer to queue
*) submit command buffer.
*) wait for queue to idle.
*) destroy staging buffer, reclaim memory somehow.
*) create shader object for your vertex shader (you'll need to pre-compile the glsl->spir-v too)
*) create shader object for your fragment shader
*) create pipeline layout object
*) create pipeline (omg so many structs here)
yay! initialisation complete!

begin render loop
*) acquire framebuffer image (this may be blocking
*) cb: restart command buffer (according to acquired backbuffer)
*) cb: start renderpass

*) cb: vkCmdBindIndexBuffer
*) cb: vkCmdBindVertexBuffer
*) cb: vkCmdPushConstants
*) cb: vkCmdDrawIndexed

*) cb: end renderpass
*) cb: end command buffer
*) submit command buffer to render queue
*) submit backbuffer to present queue
end render loop

so there's only a couple of steps...

this omits descriptor sets (including uniform buffers (yay pushconstants simplifying my descriptions), storage buffers, and textures).
the need to wait for the commandbuffer to complete before you can destroy/reclaim staging buffers/textures and the memory of said staging objects is annoying as heck, and gets in the way of streaming. that said, you're probably better off just allocating more per-frame staging buffers as needed. you cannot do copies between beginrenderpass and endrenerpass, but you can create a separate commandbuffer that gets submitted periodically before you submit your main commandbuffer. note that copying from staging to hardware buffers is not mandatory for (most?) buffers (although it is mandatory for textures), but without doing so you will hurt performance thanks to pci bus abuse if your vertex buffers are large. I suspect large index buffers are not so bad, if only because a) the ordering of reads is predicatble. b) the per-index data is probably smaller.

vulkan does two things on mobile. 1) it allows you to do stuff on multiple threads. 2) it allows tile renderers (read: mobile) to cope with multiple passes much more easily (like bloom).
desktops won't see such significant speedups, in part because driver optimisations have a much higher budget.

[jitspoe]

http://www.gamedev.net/topic/666419-wha ... kanmantle/ - 6th post down is pretty interesting. tl;dr - game devs make tons of mistakes with loose api's, drivers are massive to patch buggy games, new API makes it harder for game devs to screw stuff up.

As for me, since simplicity and compatibility are my focus, I probably won't touch it. Anything that would benefit from this I'm either not worried about right now (mobile) or is modern enough to run my simple games at 1000fps anyway.

[Baker]

[Spike]

http://triptohell.info/moodles/junk/onedraw.zip my crappy attempt at loading quake content with both vulkan and gl.
feel free to compare them (if you've actually got some vulkan drivers installed...).
either renderer humiliates regular quake engines. much of this is because it lacks particles, sound, and hud. for instance, bigass1.dem just averaged 5692fps on my machine - but note that this is a terrible test case as its normally the particle system that crushes engines with that demo.

it supports bsp2, and can connect to nq servers. it has some support for 666, but not much.
it has no 2d display. the framerate is calculated each second and displayed in the window title.
it understands -basedir and -game to select gamedirs.
+map loads a map in a mapviewer mode type thing, you can press 0/9 to add/remove ents to stress its mdl rendering. its fairly happy with large entity counts.
+connect foo:26000 to connect to nq servers
+connect demo:demo2.dem to play eg demo2. the average framerate for the entire demo will be displayed at the end of the demo via stdout. note that playback is real time, without a timedemo feature. timedemo is kinda silly when demos would be over in 0.2 secs.
f10 will release the mouse
f1-f5 changes how it calculates which world surfaces are visible (all 5 methods are only supported in the bindless version, the other two only support 2 methods).
the name comes from how the gl-bindless build renders the entire world in a single glDrawElements call. note that this only works on nvidia gpus, on amd gpus the bindless build only supports the multidrawindirect methods.
mdl rendering uses multidrawindirect to draw up to 512 entities in a single multidraw call, each with a different model, frame, etc.

the vulkan renderer is untested on amd, and depends on win32 code.
I tried to get vsync working, but nvidia's drivers seem to ignore it.
I probably should have added some barriers or something, so there might be some issues from that, but oh well.
my interpolation code is terrible.
the included exes(including makefile) were built with cygwin's version of mingw (for native win32). you'll need to fix stuff up if you want to use a different compiler.

I've a version of fte with a vulkan renderer too now, but fte has a lot more twiddles that make things slow-going (like rtlights, post processing, user-specified shaders, etc).
fun times... *cough*

[jitspoe]

I'm always impressed by your dedication and hard work, Spike!

[Baker]

[ericw]

Spike, this looks really cool.
"+map" doesn't seem to be working for me, I just get a big grid of monsters if I use it. Tried "+map e1m1", as well as loose bsp files in id1/maps/.
The demo plays, though.
The vulcan exe seems to crash my graphics driver, I'm on nvidia 364.51, gt 650m 1024mb. Oh well, the driver just came out a few days ago.

[revelator]

vulkan driver has also been available for AMD cards for some time, havent tested any games using it yet though.

[Spike]

http://triptohell.info/moodles/win64/fteqw64.exe
win64 build of fte with vulkan support
enable it via 'setrenderer vk' or via the menus.

rtlights+fog+etc work. some postprocessing things are missing including fisheye+panini stuff, and no antialiasing. skeletal models are unaccelerated, but still work properly. there's no support for custom glsl.

there's massive performance loss from high resolutions. this is true even with r_norefresh (unlike all the other renderers). I don't know what that's about, but when fullscreen expect a 50% loss compared to other rendering apis, and double the framerate when running at 320*200...
I guess vulkan drivers were optimised for tech demos...

(gl+d3d9+d3d11 renderers all work if you want to stage a pissing contest)

[toneddu2000]

NOW I need a new video card! Right NOW! Spike, you're the man!