in development Vulkan API Discussion

It is very unlikely

It's much easier and cheaper to get a Linux server hosted than a Windows machine.

Why? The OS cost is a drop in the bucket to the overall cost of hosting.

so sad.

thanks for the answer though!

I wouldn’t expect miracles regarding Vulkan,both in terms of release date or performance increase. We can hope for the best, but based on other games ported to this API, the performance increase is minimal. It’s only when the entire graphics engine is designed from the ground up that substantial performance gains can be made. From what I can tell, the DCS Edge engine will just be a port, not a complete rewrite. I’d love to be wrong, but am pinning my hopes on better VR performance on the upcoming 3080 Ti.

I wouldn’t expect miracles regarding Vulkan,both in terms of release date or performance increase. We can hope for the best, but based on other games ported to this API, the performance increase is minimal. It’s only when the entire graphics engine is designed from the ground up that substantial performance gains can be made. From what I can tell, the DCS Edge engine will just be a port, not a complete rewrite. I’d love to be wrong, but am pinning my hopes on better VR performance on the upcoming 3080 Ti.

It will help in many areas.

The big ones are separate simulation engine / graphic engine and AI logic and or pathing etc.

Just that alone could allow many more AI units / smarter AI units with it's own cpu core for a large dynamic campaign @60 fps+. Any half decent 4+GHZ cpu should be good, you will still need a good GPU for eye candy.

It will help in many areas.

 

The big ones are separate simulation engine / graphic engine and AI logic and or pathing etc.

 

Just that alone could allow many more AI units / smarter AI units with it's own cpu core for a large dynamic campaign @60 fps+. Any half decent 4+GHZ cpu should be good, you will still need a good GPU for eye candy.

IIRC in reading about it... a lot depends on how well it is implemented. So, we really have no idea until it happens.

Why? The OS cost is a drop in the bucket to the overall cost of hosting.

Where did i say it was the cost of the OS?

... Windows machines are the go-to universal standard for gaming. ...

I don't think that's the case. The most commonly used devices to run games on are smartphones. :P

Still doesn't make sense to port DCS to any other platform atm.

I wouldn’t expect miracles regarding Vulkan,both in terms of release date or performance increase. We can hope for the best, but based on other games ported to this API, the performance increase is minimal. It’s only when the entire graphics engine is designed from the ground up that substantial performance gains can be made. From what I can tell, the DCS Edge engine will just be a port, not a complete rewrite. I’d love to be wrong, but am pinning my hopes on better VR performance on the upcoming 3080 Ti.

I'm not expecting that much for 2D either. In fact DCS runs very well in 2D as it is and only seems to struggle with very big missions.

I do however hope for a miracle regarding VR performance. Right now DCS seems to prepare both viewports seperately (consecutively) on the same main thread that is shared with basically everything else.

If ED can manage to at least multithread the frame preparation for stereoscopic rendering, i can see that CPU requirements significally drop and GPU usage gets maximized even on quadcore midrange CPUs.

I don't think they would bother with vulkan, if they would not see the benefits.

As much as I don't expect any very significant performance gains in dcs (2d), my biggest hope is that vulkan can make performance more consistent and with less random stutters, as this is one of dcs's most recurring problems.

Where did i say it was the cost of the OS?

When you said it's much "cheaper" That implies it costs less. OS costs money. HW costs money. What am I missing?

Vulkan won't work magic for DCS anymore than 64-bit did for Arma. Less stutter, better consistency is what you should expect. If you have a potato, it still won't run worth a crap. If you have mid-range you will still have to give up some eye candy. If you have high end you will probably be unaffected.

Actually it did work wonders in Arma, you suddenly could crank up the viewranges super high versus previously without really dropping frames, this was not something small. It almost did and does put as much weight on CPU as DCS does. Even a performance increase of 20% with Vulkan is acceptable. Of course the more, the better.

Vulkan won't work magic for DCS anymore than 64-bit did for Arma. Less stutter, better consistency is what you should expect. If you have a potato, it still won't run worth a crap. If you have mid-range you will still have to give up some eye candy. If you have high end you will probably be unaffected.

Vulkan Shines w/ Engines that have HIGH Object Counts and Large View Distances, as those are the items that have the highest CPU Overhead, and Cause the Bottleneck with the DX8,DX9, DX10, DX11 And OpenGL Engines.

The More Objects, the more draw calls, the more draw calls, the more work the CPU has to process before sending commands to the GPU, the longer the GPU Idles while waiting for said commands, the lower the overall CPU Usage Drops, the Lower the FPS.

You Remove the CPU from the Equation and have the GPU Process Everything Graphics related, then you no longer have that problem.

Engines that have short draw distances and lower object counts, dont have this bottleneck, and do not show large gains from switching to Vulkan or DX12 from DX11, For Example:

First/Third Person Shooters/RPGs (Especially Arcade Quick Shooters and Indoor Shooters), Cameras/viewpoints are Low to the ground, viewdistances are often very short due to scenery and map layout, objects are loaded as they enter a set distance from viewpoint or loaded in sections as you move from one to another.

Racing Games, (Camera/Viewpoints are low to the terrain, and viewdistances are no where near that of a flight simulator..)

Space Sims, Empty Space is Easy to render, especially when it's only a couple dozen ships and some debris w/ often medium viewdistances before objects are removed from the scene.

The Amount of Draw Calls pushed through DX11 by DCS just sitting in an airtcraft by itself is at least 10000x that (and many times alot more) of any other "Game" I launch when watching Memory and DirectX Debug Readout data.

Vulkan is able to fully utilize as many cores as your system has to process any CPU related commands, DirectX11, even with the "Mutli-Thread" Patch they (Microsoft) tried to add to it doesnt multi-thread very well if at all in most cases.

Vulkan also allows for multiple levels of parallel tasking, DirectX 11 does not. So while the DX11 would Normally process one command at a time to the GPU and make others wait, Vulkan would have commands and functions work in parallel, so for every GPU Cycle, Vulkan would allow the GPU to do more work.

But As I said, in a Sim Liek DCS, that Came from DirectX 9 to 11 Recently and has Scene Object Counts and Draw Calls Exceeding over 100,000 Per Frame in the buffer at times.

Removing the CPU Overhead from those draw calls and the delay / Performance hit they cause, would be astronomical.

Then there's:

DirectX 12, is Limited to Windows 10, where as Vulkan Supports Windows 7,8,8.1, 10

DirectX 12, like everything Microsoft, has a License Fee to use, Vulkan does not

Vulkan will allow Better Frame Rates on Low-Mid Level hardware, and Scale Greatly through the Mid-High and High-End Hardware, and Of Course VR where everything is rendered TWICE from 2 different viewports, so the draw calls are essentially doubled.

I think this thread should be closed after that post. :) Skate made valid points without promising definite performance gains. We ALL have hope and we ALL have to wait and see the results. I don't think ED would go through the trouble of implementing Vulkan for nothing.

Actually it did work wonders in Arma, you suddenly could crank up the viewranges super high versus previously without really dropping frames, this was not something small. It almost did and does put as much weight on CPU as DCS does. Even a performance increase of 20% with Vulkan is acceptable. Of course the more, the better.

I had everything maxed out anyway, and didn't play on poorly run servers (90% of them), when they switched to 64-bit instead of bouncing from 20-80fps nearly incessantly it stabilised. 60fps on crappier servers 80-100fps on better ones. 64-bit allowed you to use more than 4gb of RAM. That was the largest advantage it offered and where all gains came from.

Most folks think unit count + script spam = automatically better. I disagree and as a result usually don't have the crippling fps issues some others do.

Last big performance gain I had in DCS was from putting it on a SSD. Vulkan may well help some, as I acknowledged, but I'll believe it when I see it as to how much.

//Threads merged

snip

 

 

Then there's:

 

DirectX 12, is Limited to Windows 10, where as Vulkan Supports Windows 7,8,8.1, 10

DirectX 12, like everything Microsoft, has a License Fee to use, Vulkan does not

 

<snip>

Normally I wouldn't wade in on this but I have to because some of this last section if actually factually incorrect. Direct X 12 does NOT require a license fee to use the Direct X API and the ability to reference it by SDK ship as part of Windows 10 Skate, you have to pay to use Visual Studio Professional but Direct X has been free for developers to use and develop for ever since Microsoft opened it up back around direct x 7.0

Direct X 12 was also opened up to Windows 7 you can get the items right here for free

https://devblogs.microsoft.com/directx/porting-directx-12-games-to-windows-7/

Not to mention that Windows 7 as of .. About this week is a no longer supported operating system.

Vulkan isn't the 'magic stick' every one thinks it is even the people whom used it so far to the best of it's ability and continue to use it (game begins with D's and W's ) have pointed that out, as they have been asked a number of times to help with other games etc and had to inform the dev's that short of a full rewrite it wasn't going to 'fix' an issue because the render pipeline they used was the core of the issue not the render'er itself.

The rest I'll agree with though, Vulkan is designed to handle multithreading better the OpenGL 1/2, Direct X 9,10,11 or the like all of which were designed really before the shift to more 'cores' became the true norm.

Direct X 12 and Vulkan on the other hand were designed specifically to take advantage of modern hardware, and with DX12 Microsoft specifically sat down with developers and went 'what can we do to help make things more efficient' the result is basically in many ways similar to what happened with the OpenGL version of DirectX aka 'Vulkan' (and in other ways Metal and Mantal) which is Developers having more access to the low level API of the Video cards allowing for better memory and render handling, which in turn allows them to decide what and were the rendering is taking place rather then having to rely on the CPU to do it.

But again DX12 itself doesn't cost to use in your games if it did half the Indy community who don't use Unity or unreal etc would be screwed if you didn't use the two big engines. Microsoft even happily lets you have access to the API documentation etc. They make their money with the Visual Studio Licensing fee you have to pay. (wich i should point out is NOT a fee for Direct X 12, I can program for DirectX 12 with out ever using VS.... i might just not like the lack of support, having to adjust every sample etc to use a different applications compile settings etc etc etc )

@robograham

That's basically where I stand, too. A ground up build would possibly help SOME, if a game is DESIGNED for it. A PORT that retains all its baggage, it may benefit from some aspects, but you're not going to get 10,000% better FPS. People should expect single digit increases and more stable framerates.

I foresee a lot of disappointed people raging ''ED U SO STUPED Y MY 2009 POTATO NO GET 120FPS @ 4K HOW U LIV WTH URSELFVS?''

@robograham

That's basically where I stand, too. A ground up build would possibly help SOME, if a game is DESIGNED for it. A PORT that retains all its baggage, it may benefit from some aspects, but you're not going to get 10,000% better FPS. People should expect single digit increases and more stable framerates.

 

I foresee a lot of disappointed people raging ''ED U SO STUPED Y MY 2009 POTATO NO GET 120FPS @ 4K HOW U LIV WTH URSELFVS?''

Part of the reason it might be taking so long is that if ED are doing it correctly they'll not only be doing a 'port' but also a 'rewrite' at the same time, which would be ideal actually as it would let them solve a lot of outstanding issues with DCS as a whole, DCS has a threading issue, ED and even Nick over on Reddit etc have all openly said it does, it's not designed to handle true multi threading at the moment the way a modern title is, moving to Vulkan gives them the chance to really take a deep look into that and the bottlenecks for it as well.

Eg currently if a script gets bogged down we see everything suffer.. especially graphics, they can in theory if they are smart STOP that in doing the update to Vulkan etc by decoupling the Graphics processes from a lot of the CPU processes, that would give a substantual increase in FPS on MODERN hardware, but 10 year old hardware not so much.. given most of the new stuff requires cards made in the past 5-6 years.

edit to add:

I should also note this, Mutlithreading = a pain in the rear, it is.. I've had to code for it and all it takes is literally 1 thread deciding not to send the right information into it's memory buffer or another not reading correctly and everything bogs down or in worse cases 'hangs', that's why even today so many applications are single threaded, because a lot of people don't realise that when you multithread in code you CAN NOT access each threads variables directly, eg thread 1 can't just go change thread 2's items. it has to PASS them to it, and thread 2 has to pass them back using very specific coding (normally a lot of protected GET/SET methods) if you try and by pass that you end up with a god awful mess.. and yes I'm speaking from Experience there.

Normally I wouldn't wade in on this but I have to because some of this last section if actually factually incorrect. Direct X 12 does NOT require a license fee to use the Direct X API and the ability to reference it by SDK ship as part of Windows 10 Skate, you have to pay to use Visual Studio Professional but Direct X has been free for developers to use and develop for ever since Microsoft opened it up back around direct x 7.0

 

Direct X 12 was also opened up to Windows 7 you can get the items right here for free

https://devblogs.microsoft.com/directx/porting-directx-12-games-to-windows-7/

 

Not to mention that Windows 7 as of .. About this week is a no longer supported operating system.

 

Vulkan isn't the 'magic stick' every one thinks it is even the people whom used it so far to the best of it's ability and continue to use it (game begins with D's and W's ) have pointed that out, as they have been asked a number of times to help with other games etc and had to inform the dev's that short of a full rewrite it wasn't going to 'fix' an issue because the render pipeline they used was the core of the issue not the render'er itself.

 

The rest I'll agree with though, Vulkan is designed to handle multithreading better the OpenGL 1/2, Direct X 9,10,11 or the like all of which were designed really before the shift to more 'cores' became the true norm.

 

Direct X 12 and Vulkan on the other hand were designed specifically to take advantage of modern hardware, and with DX12 Microsoft specifically sat down with developers and went 'what can we do to help make things more efficient' the result is basically in many ways similar to what happened with the OpenGL version of DirectX aka 'Vulkan' (and in other ways Metal and Mantal) which is Developers having more access to the low level API of the Video cards allowing for better memory and render handling, which in turn allows them to decide what and were the rendering is taking place rather then having to rely on the CPU to do it.

 

But again DX12 itself doesn't cost to use in your games if it did half the Indy community who don't use Unity or unreal etc would be screwed if you didn't use the two big engines. Microsoft even happily lets you have access to the API documentation etc. They make their money with the Visual Studio Licensing fee you have to pay. (wich i should point out is NOT a fee for Direct X 12, I can program for DirectX 12 with out ever using VS.... i might just not like the lack of support, having to adjust every sample etc to use a different applications compile settings etc etc etc )

Sorry, I was mistaken about the License Fee (that was in regards to windows as you said).

That's the Issue, which also affects games quickly being Ported from DX11 to DX12/Vulkan/ And Even Mantle before it was sold/Discontinued, they use the same Rendering Pipeline, and do no re-write the Engine to use the DX12 or Vulkan Features, so essentially it's the same engine using different API/Libraries with the same restrictions. Basically 1st Party "Wrappers" as we called them back in the day to make a DX Game use OpenGL, or Glide, vise versa and etc.

Obviously, E.D. is Re-Writing the engine, hence the Long time between Vulkan Announcement, and the Statement the core was done, and then the statement about re-writing all the shaders etc.

DX12, while part of the Reduced Overhead API's still used Core Elements from DX11, it was not a total re-write, and it was essentially Part II of a Rush Job (Part I being the shotty Multi-Thread Expansion of DX11) because they were facing competition from iOS Metal, and AMD Mantle, which was Sold/Licensed/Given to Kronos by AMD (depending on who you ask).

AS for Windows 7 Being End of Support from Microsoft, that doesn't mean anything other than no more Security Updates and Features, Anyone with Decent Security Suite, Firewall and Good Web Browsing Habits will not have a problem continuing to run Windows 7. and any Libraries DCS Uses are contained within either the DCS Folder and Updated w/ DCS, or within the Display Driver and Updated w/ Vendor Driver updates, which will continue to support windows 7 for a while longer.

Part of the reason it might be taking so long is that if ED are doing it correctly they'll not only be doing a 'port' but also a 'rewrite' at the same time, which would be ideal actually as it would let them solve a lot of outstanding issues with DCS as a whole, DCS has a threading issue, ED and even Nick over on Reddit etc have all openly said it does, it's not designed to handle true multi threading at the moment the way a modern title is, moving to Vulkan gives them the chance to really take a deep look into that and the bottlenecks for it as well.

 

Eg currently if a script gets bogged down we see everything suffer.. especially graphics, they can in theory if they are smart STOP that in doing the update to Vulkan etc by decoupling the Graphics processes from a lot of the CPU processes, that would give a substantual increase in FPS on MODERN hardware, but 10 year old hardware not so much.. given most of the new stuff requires cards made in the past 5-6 years.

 

edit to add:

 

I should also note this, Mutlithreading = a pain in the rear, it is.. I've had to code for it and all it takes is literally 1 thread deciding not to send the right information into it's memory buffer or another not reading correctly and everything bogs down or in worse cases 'hangs', that's why even today so many applications are single threaded, because a lot of people don't realise that when you multithread in code you CAN NOT access each threads variables directly, eg thread 1 can't just go change thread 2's items. it has to PASS them to it, and thread 2 has to pass them back using very specific coding (normally a lot of protected GET/SET methods) if you try and by pass that you end up with a god awful mess.. and yes I'm speaking from Experience there.

Multi-threaded Graphics Engine is not the Same as Multi-Threaded Core Engine.

Moving to Vulkan and Opening up the Graphics Engine to More threads removes Graphics Related Overhead, which may or maynot give more CPU overhead to AI/Scripting etc, assuming you only had 3 threads to begin with (1 for Sim, 1 for Sound and 1 for DirectX API).

However; Physics, AI, and other items processed that arent part of the Rendering Engine, wouldn't benefit from a Graphics Engine Re-Write, the Core of DCS would have to be re-written from the ground up, which would likely be a far greater task than re-writing the graphics engine.

with the amount of data that's processed in even simple missions, and at the speed that it needs to be processed, trying to code the sync between each thread would be a huge re-write and debug task on it's own.

Multi-threaded Graphics Engine is not the Same as Multi-Threaded Core Engine.

 

Moving to Vulkan and Opening up the Graphics Engine to More threads removes Graphics Related Overhead, which may or maynot give more CPU overhead to AI/Scripting etc, assuming you only had 3 threads to begin with (1 for Sim, 1 for Sound and 1 for DirectX API).

 

However; Physics, AI, and other items processed that arent part of the Rendering Engine, wouldn't benefit from a Graphics Engine Re-Write, the Core of DCS would have to be re-written from the ground up, which would likely be a far greater task than re-writing the graphics engine.

 

with the amount of data that's processed in even simple missions, and at the speed that it needs to be processed, trying to code the sync between each thread would be a huge re-write and debug task on it's own.

I know the two are seperate and yet there not at the same time Skate I could get into low level API coding but I think we are both basically saying the same thing in terms of reading the previous one and this one's comments together.

Which is let ED do their work, and we'll see how it comes out when it comes out.. Until then we can't really comment much because things are changing.

On threading, the GPU threads are reliant on the CPU threads, no matter what.. you can never decouple the two completely and currently in DCS world we can see this coupling majorly and again its been openly admitted DCS doesn't leverage Threads as well as it could on CPU or GPU level, GPU wise the current rewrite is to fix that GPU issue, and every one seems to forget that 2.0/2.5 was primarily a terrain engine rewrite and the first pass at as you said the shader rewrite to make it from a forward render engine into a differed render. (which also seems to be were the start of the graphic engine rewrite started), but i'm getting side tracked.. The link for CPU/GPU, we can SEE the link currently on a MP server, run the EXACT same mission one locally and one across a network and watch your frame rate suffer.

That shouldn't happen if there was not a CPU bound issue, the Frame Rate should not change for the exact same parameters if the GPU threads were all running sep and not reliant on the CPU threads for their display data, the render threads should just continue to render based on the last set of information they got if there running on their own set, instead we see the draw calls reduction instead. But in a Flight Sim that's NOT possible especailly one that uses element theory in any form.

*shrugs* but it's apples and oranges, again.. We will either see an improvement or we won't, how much/how little we won't know until it ships (well ok you might given your a tester :P ) the other one is that as ppl forget every Hardware system is different and no one ever seems to have the same drivers etc.. heck any one who runs a server or the like knows that simply because we can crash DCS doens't mean you guys testing or the like can replicate it.. because (this entire last paragraph) heh.

I think this is the point moving forward. ;)

I think his point is that we shouldn't expect a dramatic performance increase. The DCS Edge engine is being ported to Vulkan, not a full rewrite (as far as I've seen anyway), which means that it won't fully take advantage of multi-core CPUs.