in development Vulkan API Discussion

..

After I watched the two videos Skates posted earlier on the thread, I ran the tests myself.

 

I don't see any benefit. The draw calls were higher, but the overall FPS didn't improve, in fact it was slightly worse with vulkan. Given the spec of the system I would of expected to see some better FPS. I haven't OC'd anything, but with this level of system I shouldn't have to to see some increase, even small.

 

There was also some anecdotal info that as Vulkan is the OpenGL replacement, its a pure graphics API and doesn't natively support sound or peripherals like DX does.

 

If that's correct, will that complicate the support of those types of devices for DCS?

 

Maybe evolution to DX12 instead of revolution to Vulkan would be the least path of resistance.

 

I love what ED has done and DCS is unreal, but am not sure that this will be an easy path, nor bring any great improvement.

 

Hopefully this will turn out OK.

 

Cheers HarpO74

DX 12 = ONLY Windows 10 .....$#% Windows :mad: can poff

Not going to happen, the biggest improvement will be handing off the graphics and then utilizing CPU for scale, think "large missions" or "Large DC" and better AI with less impact and still holding 60+ frames. This is going to take a little time for ED to optimize to get this all going right "Balance", it is the right direction to go I believe.

You have a very good system, guy's with lesser PC's I think will see more benefit here as they will not be limited by single core performance as much as we are now.

Yeah

$#% Windows :mad: can poff

There's a sound reason to do a major change like this.

The real thing that DCS needs is more performance, period. Everything else it already has in spades.

There was no great hand off to the CPU on those results, if there was, the TR would of smashed past the DX numbers.

I'll search for some other tests that compare the API's.

I'd rather base my thoughts on real results.

So far I don't see the benefit. Maybe that will change.

Cheers HarpO74

I remember having an issue with Warcraft III back in the day where parts of the orc's armor were missing... never had an issue in any other game. Turns out one of my sticks of ram had like a bad sector or something.

it’s interesting that WC was able to get the same physical memory location each time.

that almost never happens on a virtual memory system.

Aerofly FS2 just recently switched to Vulkan API. to be fair, the VR performance of FS2 was incredible even before Vulkan, but with the new engine the FPS has almost doubled. Sure, DCS is a whole different beast but from the few available examples of Vulkan (Doom, FS2...) one can be fairly optimistic for a huge change in performance

Aerofly FS2 just recently switched to Vulkan API. to be fair, the VR performance of FS2 was incredible even before Vulkan, but with the new engine the FPS has almost doubled. Sure, DCS is a whole different beast but from the few available examples of Vulkan (Doom, FS2...) one can be fairly optimistic for a huge change in performance

One can hope. With VR, I need every FPS I can get! :)

Yep, I remember having an issue with Warcraft III back in the day where parts of the orc's armor were missing... never had an issue in any other game. Turns out one of my sticks of ram had like a bad sector or something.

 

 

Computers are just weird sometimes.

I had played on family PC way back and some games worked others would just make the PC to shut down, they probably stressed different HW and overloaded the PSU.

You have a very good system, guy's with lesser PC's I think will see more benefit here as they will not be limited by single core performance as much as we are now.

The new GPU API probably won't make DCS a truly "multi-threaded", as in that all the cores would be equally stressed.

There's again so many (wrong) contexts and meanings of multi-threading ... first of all, again, it's already multi-threaded technically, pretty much any program at this point is multi-threaded even if it's a tiny bit, the general talk term multi-threaded means that if has portion of the workload of practical human significance on another or more threads, DCS has audio on another thread that's of significant amount AFAIK (things may have changed since my last test last year)

The GPU API would relieve the stress of various things such as draw calls, and driver overhead, while providing more

So you could get significant improvements if all of that was crammed on a single core, now moved off to another core or multiple cores even, or almost extinguished.

However physics and simulation would probably still remain largely, this is a task which "can't" (that's another story) be parallelized it self and nothing a GPU API can do.

Which means, most probably DCS will continue to be single-core limited, you'll just get more FPS because you'll get to the limit later.

So far I don't see the benefit. Maybe that will change.

I've followed the new API stuff even before Mantle started, and it's not that hard to figure things out if you follow tech news regularly, you are simply wrong, there are more benefits than just performance, DX is heavy abstraction but Vulkan is not that down-to-metal as it was percieved and/or expected, it does abstraction differently and better, but because it opens up more HW access to the GPU from developer point of view, also called as "transfers responsibility to application", developers can finally write proper code instead of being reliant so much on driver hacks, yes, what GPU manufacturers are doing in all of their DX drivers are dirty hacks, scripts of what GPU should do when it encounters such a circumstance in this game, that's why the .DLL is so huge, cause there's so many different scripts for so many different cases/scenarios for so many games, 2 companies have to babysit the whole PC gaming industry, it's about time this madness ends.

Vulkan driver is much smaller in size, which means various bugs and issues can finally be properly targeted to the developer, they have to fix it, not the GPU manufacturer, but with this HW access capability, developers can actually fix it themselfs properly with source code, which means faster response as they don't need to negotiate with GPU vendor and no need to wait for the GPU driver release cycle, more HW access also adds proper coding from the beginning, games could be more stable as it can be properly tested and those things fixed at moment notice.

GPU Driver developers aren't game developers, it's a huge out-of-phase communication and understanding thing as they have very different mindset/background, so that's one big part that everyone's tired of, having to deal with driver hacks with people who don't even understand what game engines really need/want and it's a pain.

For what DX seemed like a good idea in late 90ies, has proven it has these major drawbacks in lot of things out of public view.

Just wait and you will see, but unfortunately you need to be familiar with the technicals in order to even detect various other benefits, but the amount of that benefit remains how much time ED puts into polishing, and that is an arbitrary number, they may take 2 months of polish before first release, or 6 months, or 12 months of polish after development, polish means when you have something in v1.0 working stable you decide to sit on it and keep making it better, however the initial release will have a big first impression effect, if it gets released early and the performance increases come gradually in as months pass, many people would jump to conclusions and blame things on the API it self.

Worrazen,

DX11 to DX12 is an evolution... taking what ED has already developed with the EDGE engine and extending that further to take advantage of the new features in DX12.

DX11 to Vulkan is largley a re-write of the EDGE engine.

When you take into account that the Vulkan engine is much more diffcult to code for becuse it operates at a lower level and that Vulkan does not include native support for Sound or other peripherals, ED has to do a mountain of work to make all of that run correctly.

The mirad of different hardware combinations that ED have to account/code for, and test with to ensure stability, increases almost expenentially.

Even if the advantages are that ED now has much more control over the engine and how it uses the hardware, they still have to code for it. And that alot of work, it's huge. ED is a small company and they have made an unbelievable product. There isn't anyone here that hasn't just gone flying around in the jets just to marvel at the scenery and how awesome it looks. But EDGE needs an overhaul and performance is main thing everyone wants to see.

In terms of bang for effort... it seems Vulkan is on the wrong side of the ledger.

I just hope ED have done their homework and chosen this path for the right reasons.

Maybe ED have the Yoda of Vulkan coding working for them. :thumbup:

Time will tell, hopefully not too much time though.

So I cranked the TR to 4Ghz and then 4.2Ghz. Results below.

Two things seem apparent:

1 - Despite the insane peaks at the start, by 1/3 of the way through they basically equalized.

2 - The higher you go with CPU, the less Vulkan is able to push the GPU. At 4.2 it only pushed the GPU to 88% load.

Make of that what you will.

Cheers HarpO74

Recap:

DCS Uses DirectX11_0

 

DirectX9c is a High Overhead API

DirectX11 is a Mid Overhead API

OpenGL is a Mid Overhead API

DirectX12 is a Low Overhead API, DirectX 12 was developed from Scratch by MS to Combat Low Overhead APIs (Vulkan, Mantle)

Vulkan is a Low Overhead API, Vulkan was developed from AMD Mantle.

 

 

What's Overhead?

Overhead is the Amount of CPU Processing Required to Process Graphics Commands by the API before being sent to GPU.

 

What's an API?

Programming Interface, which translates Instructions into a universal format recognized by all GPU Vendors.

 

Back in the 90s, for example, we had SEVERAL GPU Specific APIs and Architectures..

ATi (CiF),

nVidia (NV1),

SiS (S3D),

3DFx (Glide),

Matrox (MSi), and about half a dozen generic Brands (Trident (3Di/Blade), etc etc etc.

 

For Game Company Developers, it was very costly to develop separate engines to run on all these different Architectures.

 

Enter UniVBE/VESA for High resolution DoS Games, and DirectX and OpenGL for Windows.

 

OpenGL was Cross Platform (Windows, Mac, Linux etc)

DirectX was Windows Only.

 

What these APIs allow is for the developer to develop an Engine to Run on the API, by sending API Specific Commands from the Game's Engine to the API, the API Then Processes the Command and sends the GPU Specific Command to the GPU, which requires a CPU Thread to Process the Commands.

 

As DirectX Developed, and included more features/functions, a Single DirectX Thread was easily capable of causing CPU Overhead, meaning the DirectX Process had so much data to process, that it would start to fall behind, and cause delay / lag in sending commands to the GPU, which causes Stuttering, FPS Drops and even screen freezes, up to driver crashing.

 

 

Early On, Game Developers retained 3DFX / Glide Rendering side by side w/ either DirectX or OpenGL, Glide Offered Significant performance increase for 3DFX Graphics Card Owners, since it was a Low Level Direct-To-Metal API, Instructions from the graphics engine were sent directly to the GPU, leaving the CPU 100% Available for processing other threads. (Physics, AI, Sound, etc), and The Rendering Engine would not have to wait for CPU's to Process all the Commands, Thus Maintaining Fluid FPS

 

After a while, Multi-Core CPUs became the mainstay and Direct-To-Metal APIs no longer had an Advantage, and 3DFx Fell behind in R&D, and ATi/nVidia Soon where the only Major 3D Graphics Vendors Left (nVidia Bought 3DFx for access to IP and Multi-GPU Tech in the late 90s)

 

(Direct to Metal API's remained in use on Gaming Consoles, since they had a fixed hardware set).

 

So from 2000s-2010, nVidia and AMD both Conformed to Microsoft's DirectX API's and OpenGL API.

Enter 2011, When AMD Realized through several Articles, that DirectX was a CPU Hog entering the Generation of Ultra Realistic Graphics and High Object Count Scenes, the more commands DirectX had to process, the more the Single DirectX Thread would fall behind regardless of how many cores a User had in their system.

 

So AMD Starting w/ HD7000 Series GPU's and GCN1.0 GPUs/APUs, AMD Developed a Low-Overhead API Named Mantle as a Technology Demonstration designed to push MS and Kronos into developing Low Overhead APIs themselves.

 

Mantle saw mixed results, as some developers quickly patched their Graphics engines to use it, but did not code or optimize the engines to use it correctly.

 

Microsoft tried to Patch DX11 to be Multi-threaded as a stop gap to bypass CPU Overhead on a Single Thread. (Which only Offered Little to no returns)

 

Microsoft and Kronos both saw the promise in returning to Low-Overhead APIs, since there are now only 2 GPU Vendors using similar technology of stream processors/CUDA Cores (individual micro-math cores) (compared to over a dozen different architectures in the 90s), There's no need for a Big Beefy Driver Layer anymore, Let the GPU's Run the way they are now designed.

 

Microsoft Started to Work on DirectX12 from Scratch, Kronos on GL-Next.

 

AMD Realizing that a API Locked to a Specific Graphics Manufacturer was doomed to fail (Basically Glide (3DFx), and instead halted development and Donated the Mantle API to Khronos, who used it to Develop Vulkan.

 

 

So Enter DX12 and Vulkan into the Modern Day Low Level APIs.

 

 

Why is ED going with Vulkan instead of DX12?

 

Well I cannot say, But I can Speculate Conclusively the Benefits of Vulkan over DX12.

 

1. The DX11 -> DX12 transition/conversion, is not as simple as Microsoft Makes it, and any quick Conversion, would still have the same performance as DirectX11_0.

 

2. DirectX 12, is Limited to Windows 10 Only, Vulkan runs on Android, Linux, Tizen, Windows 7, Windows 8, and Windows 10 (third-party support for iOS and macOS is also available). (Plugin for Metal)

 

3. Vulkan has demonstrated to be very efficient in High Object Count Rendering Scenes (ie Flight Sims w/ Large View Distances), DirectX12, Not So Much

 

Choosing DX12, would Shut Out Windows 7 and Windows 8 Users, Vulkan would allow those users to continue to use DCS.

 

Although a DX12 offers a DX11_0 Compatibility Mode, ED would then be forced to develop a GFX Engine to Run both DX11 Commands as well as DX12, limiting the DX12 Engine to the same Performance w/ Little to no gains, and a bigger budget and 2 separate GFX Engines to Manage.

 

3. mGPU, While Both API's No Longer Need SLi/CrossFireX Drivers/Support from AMD/nVidia,

Vulkan's mGPU Modes work better than DX12's Implicit/Explicit/Linked/Unlinked Modes.

 

Both API's Offer resource Pooling (ie 2x 8 GB GPUs will show a a single 16GB GPU). Vulkan's just works better, a lot of developers are having issues w/ DX12's MGPU Modes.

The 3DMark benchmark results are also reliant on, gee what did you know, how well the benchmark it self was developed for each of the APIs.

DirectX is something established, even if DX12 is quite different from DX11, Vulkan is new, and depends on how much time developer puts effort into it, half the time you're not benchmarking the API really, but the developers work, unless you come to some point in future where there's a grandiose benchmark which has both/all APIs optimzed to the max known possibilities, but that's impossible really for humans to even know, the universe is endless, where is the end of optimization, you could be optimizing for a decade and not get to the end.

Haven't you heard about Xaudio2 and Cubeb for example, there's other newer and better things than DirectSound.

Nobody's even questioning DX12 vs Vulkan in terms of performance that much right now, there's still more benefits to Vulkan you can't see on the outside, Vulkan is expandable by the public, go ahead an submit some code or a bug report: https://github.com/KhronosGroup/Vulkan-Docs/pulls

Thank god they didn't stick with GL-Next naming. Vulkan simply has more potential in the long run than DX model. DCS needs all the optimization it can get, Vulkan is perfect match, there's many other types of applications which don't need the super-high-performance 3D games and simulators need, they are just fine with OGL or DX12.

Major emulator Dolphin-Emu has removed DX12 completely like more than a year ago https://github.com/dolphin-emu/dolphin/pull/4424 reasons: nobody cares, has nothing more over Vulkan, maintenance burden, requires Win10 SDKs

In my dreams DCS boots it's own dedicated Linux :pilotfly:

sleek, fast, reliable, Pick any THREE

....DX11 to DX12 is an evolution... taking what ED has already developed with the EDGE engine and extending that further to take advantage of the new features in DX12....

That's not true anymore for DirectX12, it was Microsofts counter to the Low Level API Mantle from AMD. If you want to write a DirectX 12 renderer you have to go through the same "shit" you have to do with Mantle or Vulkan if you want the benefits of an LowLevelAPI.

In my dreams DCS boots it's own dedicated Linux :pilotfly:

 

 

 

sleek, fast, reliable, Pick any THREE

+1 DCS is my main reason for not abandon Microsoft land and going full Linux. :joystick::pilotfly:

+1 DCS is my main reason for not abandon Microsoft land and going full Linux. :joystick::pilotfly:

For everything else I have macOS and Linux and since last week I usually boot my game rig into Linux Mint, it's much less annoying. I still need to shuffle some stuff over but Win10 is beyond tolerable for me atm. Constant issues with 1803, freezes for seconds, power mode issues and a few more. For now, I enjoy Mint mostly.

Oh no, not a linux vs windows again…

Hope ED release test version Vulcan next wednesday on Open Beta that will make an end of all speculations about it. :D

Next Wed?

We’re probably months away from receiving something worthy of release, and even then, optimisation probably won’t be finished.

Next Wed?

We’re probably months away from receiving something worthy of release, and even then, optimisation probably won’t be finished.

Wrong.. Vulcan Api is already in for testing NOW! :D

see: https://forums.eagle.ru/showpost.php?p=3596013&postcount=41

Wrong.. Vulcan Api is already in for testing NOW! :D

 

 

see: https://forums.eagle.ru/showpost.php?p=3596013&postcount=41

i don't see, how skatezillas statement implies vulcan being in testing right now.:unsure:

i don't see, how skatezillas statement implies vulcan being in testing right now.:unsure:

https://forums.eagle.ru/showpost.php?p=3592185&postcount=10

https://forums.eagle.ru/showpost.php?p=3592185&postcount=10

Not sure what calendar you are using, but today is August 24 and the posting you quoted was on August 9 and specifically stated they are still a MONTH away...

On my calendar this would mean September 9th at the very earliest.. Yet we all know that random predictions of this type stating "a month away" doesn't really mean anything as too many variables and they can all change in a day..

I wouldn't expect to see anything useable until probably October or later.

And this is not a slam on ED at all, just a realistic assessment.. Even if internal testing starts in September, I still think it would be doubtful they would have things tied up well enough to provide anything to us in that timeframe.

Not sure what calendar you are using, but today is August 24 and the posting you quoted was on August 9 and specifically stated they are still a MONTH away...

also they are a month away only from base programming. according to wags post, shader programming comes after that, so i assume that the internal build at the moment features unshaded geometry mostly.

fly like it's 1992!

For everything else I have macOS and Linux and since last week I usually boot my game rig into Linux Mint, it's much less annoying. I still need to shuffle some stuff over but Win10 is beyond tolerable for me atm. Constant issues with 1803, freezes for seconds, power mode issues and a few more. For now, I enjoy Mint mostly.

I've tried Ubuntu many times, but I don't understand how Windows 10 has more problems than a linux install that has multiple repositories and requires many, many command line items to run certain functions.

Just for the record (no direct relation can be made with DCS) :

a picture of VR hardware usages between Vulkan and OpenGL with another flight sim.

What can be relevant is : with vulkan gpu usage is 20% lower with same settings and same 90 fps cap (VR oculus rift).