Vulkan Renderer

[Xottab-DUTY]

Note that it should not be a replacement for existing OpenGL renderer, but another renderer.

xrRender_VK:

• [ ] HW
• [ ] Backend
• [ ] Resources management (textures, SH_RT, SH_Atomic etc)
• [ ] State management
• [ ] and more...
• [ ] Shaders (two ways, should be supported both)
  • [ ] Use cross-compiler (see #258) to compile shaders from existing HLSL code.
  • [ ] Support own GLSL shaders in case if they are exist. (We should decide on folder name)

[vTurbine]

Hope this will help you for quick start with the task. For me it was a bad idea to abstract from vanilla renderer as much as possible, so I simply tired re-implementing all not GAPI-related stuff again. AFAIR, beside some polishing there were two major things left to be resolved:

• proper render passes abstraction (requires refactoring of existing DX renderer)
• proper synchronization

This days I see the task challenging again, so if there are no free hands to do it here I can try to rework the code and integrate it into the Engine.

[vocasle]

I would like to work on Vulkan renderer if no one else is working on it currently. @Xottab-DUTY and @vTurbine it would be nice if we could arrange a discussion regarding implementation if possible.

[johncurley]

I've recommended this before, but dpjudas from the Unreal/ZDoom community has a nice renderer that could be used as a reference for how to set Vulkan up as it's more involved than other backends.

https://github.com/dpjudas/UT99VulkanDrv

[Xottab-DUTY]

@vocasle, hi! Glad to see you here :)

We have a Discord-server: https://discord.gg/sjRMQwv

Though, @vTurbine is usually online in Telegram, rather than Discord. We can do a voice call in Telegram or Discord, if you would like.

Currently, no one is working on a Vulkan implementation. Though, @vTurbine says that he has some patch for our current backend class that can make it easier to implement Vulkan. But this patch is not committed or implemented yet :)

[vocasle]

@Xottab-DUTY hi, thanks. I have joined the Discord server (vocasle is the name in Discord). It would be nice if we could schedule the call in Discord/Telegram. Please let me know in Discord when you and @vTurbine will have a time to discuss Vulkan implementation.

In the meantime I will explore DX11 layer and xrRNG.

[kotleni]

Pending 🦝

[Mortecha]

In my research in looking into creating a Vulkan rendered for this, I've found RedProjects/XRayEngine which already has a Vulkan implementation. https://git.s2ue.org/RedProjects/XRayEngine. I'd suggest looking at what they have and just credit them and use that instead of starting from scratch. They have a good DX12 implementation as well. Everything is in Cyrillic so I can't understand a thing as I only speak English. Let me know your thoughts.

[Mortecha]

Scratch my last recommendation to use RedProjects renderer and crediting them, I've found a better solution. This project's issues with rendering in general can be solved by using bgfx https://github.com/bkaradzic/bgfx. OpenXRay still retains its identity as an engine by going this route, and bgfx is constantly updated so saves the hassle of manually updating renderers as time goes on with limited resources and knowledge with our roll your own renderers.

[vocasle]

It will take proportional if not a bigger effort to integrate bgfx or any other solution. I think we should stick with Vulkan.

[vocasle]

Also this is a big architectural decision that I think @Xottab-DUTY and core maintainers could take.

[Mortecha]

It will take proportional if not a bigger effort to integrate bgfx or any other solution. I think we should stick with Vulkan.

I respectfully disagree. bgfx if you understand encapsulates all graphics APIs including Vulkan with a very thin close to metal translation layer. In essence you would write one renderer that can use all graphics APIs it supports instead of writing a renderer for each graphics API that you would intern have to manually update and maintain.

Feel free to write a Vulkan renderer from scratch if you like:)

[Mortecha]

Also this is a big architectural decision that I think @Xottab-DUTY and core maintainers could take.

That would be correct, that is why this discussion is beginning here before any time is wasted on an implementation that would be rejected.

[Mortecha]

Also this is a big architectural decision that I think @Xottab-DUTY and core maintainers could take.

That would be correct, that is why this discussion is beginning here before any time is wasted on an implementation that would be rejected.

The more I think about your statement, the more inaccurate it becomes. It wouldn't be a "BIG" architectural change at all. In fact it would just be a renderer that allows the user to choose the API they wish to use from the APIs that are supported on their system, then handle the rendering using that method. The engine, game and the "architecture" itself would remain untouched.

I'm happy either way this goes but this is my recommendation to consider.

[Xottab-DUTY]

bgfx is just not suitable for us at is introduces it's own shader language and requires to use it, and we have a requirement to be compatible with vanilla pure HLSL shaders. Moreover, it doesn't support geometry and tesselation shaders, so it would a regression in features since S.T.A.L.K.E.R. uses these types of shaders.

Also this is a big architectural decision that I think @Xottab-DUTY and core maintainers could take.

That would be correct, that is why this discussion is beginning here before any time is wasted on an implementation that would be rejected.

The more I think about your statement, the more inaccurate it becomes. It wouldn't be a "BIG" architectural change at all. In fact it would just be a renderer that allows the user to choose the API they wish to use from the APIs that are supported on their system, then handle the rendering using that method. The engine, game and the "architecture" itself would remain untouched.

I'm happy either way this goes but this is my recommendation to consider.

Sorry, but this message is actually inaccurate. There are many ways to build renderer architecture, and X-Ray's one could be so different to how bgfx is meant to be used, that we would need to change the renderer architecture... and since X-Ray is a tangled ball of wool, that could lead to changes in everything, including game module. In fact, all our major renderer changes already always require changes in the game code. Everything is tightly coupled to everything.

So, speaking about 3rd party libraries, LLGL or NVRHI would be better choice if we would decide to use a ready-made library :)

Nevertheless, this is a really good discussion, it makes me consider the requirements we have for these types of libraries – actually knowing and having the complete requirements list we can find a library that fits best, or at least know what we do want to develop.

[Mortecha]

I consulted https://dev.to/funatsufumiya/comparison-of-c-low-level-graphics-cross-platform-frameworks-and-libraries-58e5 before recommending bgfx and noticed LLGL as well, but looked at each repo and chose bgfx because it seems more active and has alot more contributors. Saying that I overlooked supported shader types. You raise a good point with that so LLGL or even The Forge may just be the best way to go for rendering.

Regarding concerns of changes to architecture and the game module, in my mind I envision a translation layer between OpenXRay rendering and "chosen 3rd party graphics framework" which would prevent the need to have to change everything to fit said "chosen 3rd party graphics framework" directly.

Regardless of what if anything is chosen. It would be beneficial to offload rendering entirely to a 3rd party rendering framework to reduce the need for rare, competent and interested graphics programmers to keep the renderers up to date and optimised. Why reinvent the wheel I say when theres perfectly capable open source solutions already out there to be used.

[tudor07]

Why not use DXVK?