in development Vulkan API Discussion

I was reading in some ED interview that DCS has a lot of "legacy code" aka spaghetti code, means that it probably goes all the way up to Lock On. In that interview it was said that sometimes its better not to touch it.

I'm not a programmer but im playing a bit with Unreal5 and there you have blueprints which is coding but made easier by using visual aspect rather than lines of code. And even that it is much more intuitive you can get lost in there, so i can only imagine that playing around in such complicated code might be even task impossible to make.

The problem is that there are a lot of 3rd party modules and they need to work after changes, some of 3rd party do this as part job will they be able to keep up after those changes?

So its might be better to start everything from scratch, but if making new engine will take years what if by the time it is done it is already obsolete. Even the big companes like CD project and others are leaving their own engines and move to U5 because of Lumen and Nanite, much more people know them, and because they just work.

7 hours ago, Peter5on said:

I was reading in some ED interview that DCS has a lot of "legacy code" aka spaghetti code, means that it probably goes all the way up to Lock On. In that interview it was said that sometimes its better not to touch it.

DCS is new enough to be somewhat modular, though, which means you don't have to touch legacy code - you can chuck it outright, but only if you have a replacement handy. This is what ED is doing now, there's absolutely zero DX12 code that can be transferred to Vulkan, it's a whole other paradigm. This is also why you see systems replaced the way they are, it's not worth trying to fix the old AI, old ATC and so on. Rather, they're replacing those systems with completely new ones.

Making a new engine from scratch would be more or less the same thing, TBH, only it couldn't be done in stages. 

14 hours ago, Dragon1-1 said:

Multicore will almost certainly deliver a massive performance boost on complex missions, particularly for people with modern CPUs, since it'll actually use the resources modern ones have. Vulkan should change less except for VR users, where it'll be a gamechanger as well, since its way of rendering VR is more optimized than what we have now (we basically render the same thing twice, Vulkan is smarter about it).

It will depend on hardware and the mission being flown, but I would fully expect a very noticeable increase.

Check out Fast Jet Performance on the tube with an interview with Simon Pearson and Ben Whiteley and you can listen there take on the performance coming. 

19 hours ago, freehand said:

Check out Fast Jet Performance on the tube with an interview with Simon Pearson and Ben Whiteley and you can listen there take on the performance coming. 

 

 

On 10/9/2022 at 7:35 PM, Dragon1-1 said:

DCS is new enough to be somewhat modular, though, which means you don't have to touch legacy code - you can chuck it outright, but only if you have a replacement handy. This is what ED is doing now, there's absolutely zero DX12 code that can be transferred to Vulkan, it's a whole other paradigm. This is also why you see systems replaced the way they are, it's not worth trying to fix the old AI, old ATC and so on. Rather, they're replacing those systems with completely new ones.

Making a new engine from scratch would be more or less the same thing, TBH, only it couldn't be done in stages. 

The graphics and physics rendering is monolithic and has been since the days of LockOn.

Yeah, that's why it's taking so long. Graphics+physics rendering is monolithic, and has to be replaced in one go, not that you could do DX12 to Vulkan transition in any other way, anyway. By "modular" I meant  that you can touch, say, AI without touching graphics+physics, mission scripting or main menu code. This is not a given, I saw some really screwy things with ArmA's RV, particularly the AI breaking when a change was made to a completely unrelated area of the engine. Not to mention the unholy mess that was FreeSpace Open when I played around with it as a kid (some coding wizards have cleaned that one up since).

A truly new engine, if it was to be a step like Enfusion was over RV, would require everything to be done from scratch. A rendering engine is no good for anything but, well, rendering, and rewriting AI is a monumental task. Despite the technical debt, I'm pretty sure many parts of DCS are worth keeping and work fine as-is. Making a new engine peacemeal, on top of the old one, even if it's not quite as streamlined, should work out OK, IMO.

15 hours ago, Dragon1-1 said:

Yeah, that's why it's taking so long. Graphics+physics rendering is monolithic, and has to be replaced in one go, not that you could do DX12 to Vulkan transition in any other way, anyway. By "modular" I meant  that you can touch, say, AI without touching graphics+physics, mission scripting or main menu code. This is not a given, I saw some really screwy things with ArmA's RV, particularly the AI breaking when a change was made to a completely unrelated area of the engine. Not to mention the unholy mess that was FreeSpace Open when I played around with it as a kid (some coding wizards have cleaned that one up since).

A truly new engine, if it was to be a step like Enfusion was over RV, would require everything to be done from scratch. A rendering engine is no good for anything but, well, rendering, and rewriting AI is a monumental task. Despite the technical debt, I'm pretty sure many parts of DCS are worth keeping and work fine as-is. Making a new engine peacemeal, on top of the old one, even if it's not quite as streamlined, should work out OK, IMO.

The Core and the GFX Engine dont have to be replaced at the same time.

They will however benefit each other.

Just leaving this here:

Quote

The Supercarrier has been receiving a lot of work behind the scenes. This can be divided into the following features:

Ready Room and PRIFLY (airboss deck). Both views will provide new functionality never seen before in a DCS product. To complete this, we will first need to release the Vulkan API into DCS.

https://www.digitalcombatsimulator.com/en/news/newsletters/710da5ca8e2b65946661b86f07269410/

On 10/18/2022 at 2:42 AM, sobek said:

The graphics and physics rendering is monolithic and has been since the days of LockOn.

On 2/6/2023 at 12:27 AM, Burnerski said:

[...]

Well, yes, but LockOn probably was a rewrite, don't you think? After LockOn, I don't think a complete rewrite happened.

Bye
Phant

Interesting read from an X-Plane dev:

https://developer.x-plane.com/2023/02/addressing-plugin-flickering/

Short version:

XP12 runs Vulkan for the main app, but plugins continue to use OpenGL, so they're bridging that. There are however issues with this on the driver side, it's not perfectly supported. So what they are doing now is to use Zink to translate the OpenGL calls into Vulkan and then execute these by the same Vulkan device that the main app is using. At least on Windows an Linux. They can't yet do it on Mac OS, because there is no Vulkan support there. (They are thinking about using moltenVK, which translates to Metal.) In my opinion, this is a really clever way to handle such a situation.

Zink is an implementation of an OpenGL driver on top of Vulkan and is part of the open source Mesa driver stack that is the main OpenGL and Vulkan driver implementation on Linux. So you could run your average OpenGL game or application using Zink and a Vulkan driver.

Now, so far this is not really relevant to DCS, however, there is also DXVK, which is a DX9-11 implementation on top of Vulkan. In contrast to Zink, it's not part of Mesa, it's a separate project, but it is open source as well. Even today you can use DXVK to just run DCS on a Vulkan driver on Linux. In the future, DXVK might be helpful to still let some parts run DX11, despite the main app being Vulkan; when performance is not limiting. Or e.g. for modding support, to avoid having modders write (more complex) Vulkan rendering paths.

This might be interesting for modders, but I find that this is a sort of half-measure that tends to get misused and leads to technical debt piling up. It's easier to use an older technology, particularly one with a paradigm that also needs much less manual optimization (Vulkan is a notoriously low level API), but if an initially non-critical system gets built upon too much, it might very well end up bogging things down.

53 minutes ago, Dragon1-1 said:

This might be interesting for modders, but I find that this is a sort of half-measure that tends to get misused and leads to technical debt piling up. It's easier to use an older technology, particularly one with a paradigm that also needs much less manual optimization (Vulkan is a notoriously low level API), but if an initially non-critical system gets built upon too much, it might very well end up bogging things down.

Actually, I see it the other way around. This kind of approach will get used more and more both on the software side as well as on the driver side.

e.g. Intel already uses DXVK on Windows to get a working DX9 (10/11?) driver without having to implement one, because that's very complicated as well. (Actually, we don't know what they do exactly, we just know that DXVK is a part of it.)

Look at it this way: DX drivers are very complicated and overloaded, hence the many driver-specific and also app-specific workarounds that you have flying around. VK drivers (and also DX12 drivers, since that's basically the same thing) on the other hand are pretty slim, there are way less driver-specific bugs to be expected. If you can now take one implementation of DX9-11 (i.e. DXVK) or OpenGL (i.e. Zink) on top of that, which is also better debuggable due to being open source, you could potentially avoid a whole lot of problems. The question "Who has the better graphics driver? AMD, Nvidia or Intel?" will become less relevant in the future.

For backwards compatibility, maybe, but I really wouldn't want to see such Rube Goldberg contraptions in new software. There's no reason to use DX11 now, it's an outdated API. It needs to be phased out, and when that's not possible, then we can consider running DX11 through Vulkan. Native Vulkan support is always going to be better, sure, it'll be more effort to implement, but it'll be a lot less prone to bugs.

In fact, if modders are forced to learn Vulkan, IMO that could have positive effects down the road. Vulkan is a vastly superior API to DX, and I'd love to see the latter phased out completely.

1 hour ago, Dragon1-1 said:

For backwards compatibility, maybe, but I really wouldn't want to see such Rube Goldberg contraptions in new software. There's no reason to use DX11 now, it's an outdated API. It needs to be phased out, and when that's not possible, then we can consider running DX11 through Vulkan. Native Vulkan support is always going to be better, sure, it'll be more effort to implement, but it'll be a lot less prone to bugs.

In fact, if modders are forced to learn Vulkan, IMO that could have positive effects down the road. Vulkan is a vastly superior API to DX, and I'd love to see the latter phased out completely.

I'm a Linux user since a long time, but gaming on Linux really wasn't an option a couple of years ago, because the translation from DX to OpenGL was a hit and miss. Actually, more a miss than hit, tbh. So trust me, I really want to get rid of DX and was very annoyed by the fact that it is by far the most popular API for rendering in games.

However, with the appearance of DXVK, this changed, quite a lot. These days, you can try basically any random game that uses DX9-11, run it with DXVK on a Vulkan-capable GPU and it'll work in more than 90% of the cases just fine. Of course, there are problems remaining, but in most cases rendering isn't one of them anymore. That's how well this works. (Interestingly, DCS was actually one of the few cases where there were problems, since some textures on some maps seem to fail loading, i.e. remained black.)

But ideally, everything is run via Vulkan, there is no debate there. I'm skeptical, when it comes to mods, because since these are usually done by people in their free time, you might drive people away by requiring them to learn Vulkan, meaning that maybe some neat ideas just don't get implemented, because the development overhead is too big. So, keep that in mind.

Otherwise, I'm team Vulkan, all the way.

1 hour ago, DigitalEngine said:

Anything on the Word of DCS being Vulkanized?
A news letter hint would be nice.

I remember they said Vulkan would come after multithreading. 

This is lifted directly from the Jan 6 newsletter:
"Implementation of the Vulkan API continues in parallel with the multithreading effort. Our Vulkan renderer is integrated with the new render graph, and it benefits from multithreading by using render graph mechanics of background loading of textures and geometry, rendering objects in parallel, terrain streaming, etc. As a result, many rendering tasks submitted to the graphics card will no longer need to wait for each other and hence be processed simultaneously.

In our endeavor to unify DirectX and Vulkan renderers, we have developed a mod state where both backends produce identical results. We now have two fully compatible implementations that run under the same API. This means that all our applied graphics modules (the code that renders our skies, clouds, models, effects, etc.) will work the same way on both renderers. To achieve this, we ensured that all our shaders could be converted into Vulkan format in addition to implementing a shader converter available from within DCS permitting to compile any shader on the fly. It is interesting to note that the shader conversion has taken an inordinately large amount of time.

The main achievement in 2022 is that DCS now works under Vulkan producing the same visuals as under DirectX. This result is fully ‘transparent’ for our graphics programmers, allowing them to write the same code for both platforms without the need to have separate code paths for Vulkan and DirectX11 and beyond.

The next step is to provide our graphics programmers with the new Vulkan features compared to DirectX 11. These include new types of shaders (as per Shader Model 6 and further), ray tracing, some advanced rendering techniques, such as GPU driven rendering, and similar."

I'd say, with the MT branch still a bit iffy in some hardware configurations (for me the current patch performs no better, if not worse, than ST), I'd say that we should wait for that to be ironed out before Vulkan introduces another batch of bugs. Let them polish up MT, add DLSS and all that, then put Vulkan in. One massive breaking change at a time, please.

1 hour ago, Dragon1-1 said:

I'd say, with the MT branch still a bit iffy in some hardware configurations (for me the current patch performs no better, if not worse, than ST), I'd say that we should wait for that to be ironed out before Vulkan introduces another batch of bugs. Let them polish up MT, add DLSS and all that, then put Vulkan in. One massive breaking change at a time, please.

Having bugs on the experimental option is not such a big deal if there is still the standard option with DX11 and ST. Personally, I'd rate Vulkan support at much higher priority than DLSS (or FSR) since it provides the basis for the next-gen engine, but of course that's only my point of view. Don't know how they set the priorities internally.

DLSS was already running in 2023 and beyond video. So, it'll likely be finished first. It's best to finish things that are already started before moving onto the others.

Maybe next patch.....? 

vor 14 Stunden schrieb linside:

Maybe next patch.....? 

I also had a nice dream today

16 hours ago, Dragon1-1 said:

DLSS was already running in 2023 and beyond video. So, it'll likely be finished first. It's best to finish things that are already started before moving onto the others.

Yeah, maybe. But if it was already finished back then? Why not release it immediately? Or in one of the last patches? So there seems to be a bit more to it.

I still think that Vulkan is the more important topic, though. After all, this thread is already 34 pages long.

MT was running at that point, too. Presumably, there are still bugs to iron out, just like in MT. Some of them might be quite game-breaking, MT had its share of issues at launch, and it still does.