The Vulkan API

[Mel]

Well, i guess i lack of perspective here, I am comparing it to the 2 or something megabytes irrlicht takes ^^U Or to the fact that it doesn't provide almost anything save the most elemental GPU communication, and support for multiple GPU, the question about multiadapters memory sharing is still very green, or at least, it looks that way, it is a complete DIY API. But at the same time, if it provided more, it would "get in the way" of what you can really achieve with it.

[christianclavet]

Cool work Mel!

[Mel]

My own vulkan based engine (I must admit i've stuck to many of Irrlicht's gimmicks when it came to building it, but at least, it runs as smooth as my hard is capable of, 3000 FPS, with a sort of vertical synchronization Vulkan implements, that is not a VSync strictly but allows the screen to go without flickers much faster than VSync. I know rendering a tetrahedron isn't very interesting, but at least the set of features already available is not small:

• a fully extensible pipeline creation system via function pointers and an internal pipeline cache.
• a flexible mesh system allowing to build meshes in runtime, mapable both in device and system memory (i want to implement a stream system)
• 4 vertex formats so far (it is complex to add more vertex types... but nobody says it is impossible to build a flexible vertex system on this)
• 16/32 bit indices meshes.
• Custom mipmap generation (Vulkan doesn't do this for you ^^U).
• points lists, line lists, line strips, triangle lists, strips and fans primitives.
• Cube map support (not tested yet)
• texture arrays support, for both 2D and Cube maps (not tested yet)
• 3D textures support (not tested yet)

And i plan on adding some more features such as:

• Dynamic scene culling
• Compute shaders (actually it is possible to create a compute shader and use it, but i haven't tested it yet...)
• Hardware skinning
• Instancing
• Mouse/keyboard/controller support
• Networking (But just not yet...)
• Sound (i never said this was gonna be a graphics only engine XD)
• Some GUI support (but i will surely end blending in an already built gui system...)
• Some built in physics... nothing too fancy, just to be able to do some basic collision detection and that's it...
• ... more features I sure forget...

Almost any feature you want to program, you either need to program a shader for it or is fairly complex to get otherwise, for instance, if you plan on implementing instancing, you have to prepare a shader for it, as shaders become very "sticky" to the whole setup for them, They won't allow much flexibility in that matter. The gains, though, are that shaders aren't constrained neither to a minimum nor a maximum of resources, i.e. if a shader only needs 1 texture, it won't set any more texture stages, if it needs 5 or 6 or a texture array, that is what you will suply them. and that is what the shader will expect, (and if you fail to provide them, the debugging layers will complain..)

[Mel]

Let's add skyboxes...

[Mel]

32 bit meshbuffers working properly: The polycount in this scene is over 2.000.000 (1024*1024*2) in that single sphere


And still renders smooth...

[robmar]

How's your Vulkan driver coming along Mel? Is it running as fast as with DX9, or even faster?

[Mel]

I've been away from the computer all this time, so i couldn't advance it QQ... But after seeing so many articles about how to pick the fastest paths with Vulkan, i think my own is very green, without multithreading nor other advances, seems that GL/DX11 is the choice (i can't speak out of experience, but i'd say DX12 is having similar issues... save if you want to program XBOX One you have to use DX12 almost forcefully XD)

I am having doubts about how to approach the memory management in Vulkan, as it seems to be one of the major responsibilities a programmer has now (i.e. before, things like video memory fragmentation were problems one would never have because those issues would lay on the system driver on DX11-/GL) as well as how to efficiently approach a fully multithreaded engine. (not only the command generation, but also the scene processing and such...) Depending on my decisions, i would have one thing or other.

So far, i got to push 18.000.000 triangles on a single meshbuffer, have 16/32 bit meshbuffers, diferent textures, mipmap generation, node/hierarchies/camera movements, generate commands per frame, all in a single thread and still run 30+fps...
https://www.instagram.com/p/BT_7o--F85e/

[robmar]

18 millions at 30 FPS is pretty good especially if on mid-range hardware. What CPU/GPU did you use?

I manage to run just 6 million on Irrlicht 1.7.3 at 30 FPS in and AMD A10 APU.

[Mel]

I'm on the lowest range that can run Vulkan. The CPU is a core i7@ 3.4 GHz and the GPU is a NVidia GTX660.

[robmar]

Have you look at or tested the Irrlicht bGFX addition, seems like the way to go to support all drivers, as long as its efficient.

I guess your Vulkan driver will be fast and easy to expand though, without all the other stuff needed for something like bGFX:

[Mel]

No, I havent. but i think that it isn't really a good idea to use another layer of abstraction to use Irrlicht, because, simply, Irrlicht on its own is already an abstraction over OpenGL and Direct3D11-. Instead of relying on another graphics API abstraction, Irrlicht should complete its own support on the existing ones, which are direct communication with the hardware.

Irrlicht has that it maps very well to OpenGL and DirectX so writting a Vulkan video driver is not a very good idea. Vulkan is as stateless as it gets and has no renderstates to change as the SMaterial does with Irrlicht, or they are a minimal set, so every combination of material types, renderstates and vertex types should be made explicit to use it with Vulkan, not to speak about rendertargets, which would increase the combinatory explosion even more, and creating a pipeline isn't trivial, to the point that Vulkan supports saving and loading pipelines to disk cache. Vulkan, for instance, doesn't allow you to use a pipeline (A material) on a diferent vertex type than the one you provided when you created it (on creation, the pipelines need to know what kind of vertex are they going to use), It is not that simple. Also, multithreading isn't very recomendable with Irrlicht because of its nature, synchronizing with the state machine would stall more the rendering operations than anything else. The irrlicht video driver is meant to use an immediate rendering API, something that vulkan is not.

The good thing, although, is that Irrlicht scene tree can be (and i think it should be) adapted into a multithreaded processing, reducing a lot the time needed to start the rendering process, So, if instead of rendering immediately during the scene processing, perhaps the scene tree was processed in parallel, and later, the rendering done straight, it would ease its transition to the command recording APIs such as METAL, VULKAN or Direct3D12

[robmar]

Okay, so create n threads to process node animation (pos change), and rendering preparation up to the actual rendering point, then render the lot in the main thread, doesn't sound too difficult, is that what you mean?

I don't know how much overhead bGFX would have, but I guess to get the most out of the hardware what you say must be true.

How developed is the DX11 driver at the moment? I'm using a modified version of 1.7.3, will I be able to add it to that without too many changes???

[Mel]

Yeah. If, perhaps, you don't issue any rendering command, process the scene tree and instead of rendering, you record all the nodes and materials and constants/uniforms you want to use, the rendering could take place in one go from the main thread.

As for the overhead... depends. Vulkan is developed to have the least overhead possible, but then, part of that overhead is somewhat moved to the user, mainly the memory management. For instance, how does bGFX handle the device memory? how does it behave when multithreaded?... it should be tested

I don't have much idea of how developed is the DX11 driver, i saw it and the rendering had issues with transparent materials and the depth buffer

[devsh]

With the right extensions on Nvidia you can follow the same methodology in OpenGL and then port your rendering to Vulkan as soon as your userbase is comprised of hardware supporting Vulkan decently

[Mel]

Vulkan has a limit with regard the amount of memory allocations it may perform, but doesn't have this limit in the amount of images or buffers it can create... This simply says "handle your memory on your own that i will handle mine as I see fit, we provide"... Thus a memory manager is a must. Also, this helps to place similar objects together, texures with textures, buffers with buffers, and so on, which may help to improve cache locality, and speed up things. Something really interesting!