Xenko Game Engine Sees Huge Performance Boost With Vulkan

[phoronix]

Phoronix: Xenko Game Engine Sees Huge Performance Boost With Vulkan

Via multi-threading improvements to the game engine, Xenko is seeing a huge performance win with the Vulkan API...

http://www.phoronix.com/scan.php?page=news_item&px=Xenko-Vulkan-Results

[bvbfan]

For who doesn't know, OpenGL can use multithreads, so only and the weakest technology that cannot is M$ DirectX (before 12) So you must know why all game engines till now are shits. *Gamers* continue to use M$ shits and you never see what is good game.

[Tomin]

This seems to be very similar situation to the PowerVR's gnome demo. No wonder it performs so much better with Vulkan.

[Luke_Wolf]

I guess they want to eventually sell licenses to this engine otherwise this dichotomy doesn't make any sense

Xenko can be used free of charge in two different ways:

• Using the official releases, you can distribute your game without disclosing the source code, but you're not allowed to modify the engine code.
• By compiling Xenko yourself, you're allowed to modify and compile the engine but you must distribute all the source code with your game.

If you want specific license terms (i.e. use a modified and/or self-compiled version of Xenko for your project without disclosing the source), feel free to contact us

I get there's that bit about "Contact Us" which may end up with profit sharing license agreements, and that they make their money selling videogames https://en.wikipedia.org/wiki/Silicon_Studio but ...

[Azpegath]

The reason they're seeing this improvement is that they're comparing a naive OpenGL implementation (doing a different draw call for each house in the scene) with the same sort of Vulkan implementation. Since Vulkan lacks the draw call-overhead that OpenGL has, it is a lot faster, just like the Gnome demo mentioned above.
I love Vulkan in this sense, and it would probably greatly benefit our code (at the company I'm at), since we're unable to batch things up any more than we do, since all our objects are procedurally generated and never two of the same. But for a game engine, this usually isn't the case, and that's why we're not seeing these amazing improvements in general for games.

Improved multi-threading and "modern" Vulkan/DX12-designed game engines will probably have a huge gain by using Vulkan/DX12 (since they couldn't exist without it), for instance: See the GDC presentation by Dan Baker, presenting Ashes of the Singularity. An amazing engine where everything is carried out using asynchronous render queues.

Here is one of his talks. Awesome guy!

https://youtu.be/EX1RKhlOYmY?t=42m24s

[cj.wijtmans]

There is literally 0 need for so many draw calls. A well optimized game only has a few. Procedurally generated or not.

[Azpegath]

There is literally 0 need for so many draw calls. A well optimized game only has a few. Procedurally generated or not.

Thank you for your wisdom, I'm glad you know nothing about our software stack or use cases. Only a true internet warrior can express oneself in such a fashion!

[cj.wijtmans]

Looks like i hit a nerve or something.