[MERGED] DirectX 11/12, OpenGL, VulkanAPI Discussion

Look at the CPU usage in that pic, ProcessLasso tied them to real cores, Taskmanager is sadly not included in the frame, it had 6 cores al most full tilt.

This changes when you fly away from dense areas, it eaes off to like 5 x 20% and 1 x 90% core usage in the Mountains ( me and a million tress ).

I have no idea why, I am no ED dev, I just see and read the values.

:offline SP, KA-50 free flight quick mission:

same settings..mountains, treeeeees everywhere

*MP ; BF-Server, red:

( through MSAA 4x and Def. Shading my FPS are way down from 100+, which only work with MSAA off )

The most critical question to a multicore support is, what tasks can be run asynchronous?

The threads in that pic are StarForce copy protection and the sound engine from the looks of it. What needs breaking up is the graphics engine and game logic. Vulkan allows the graphics engine to be split across multiple CPU threads.

 

As for what can be run asynchronously, that's not a real problem. It doesn't matter what order the positions of each unit are updated or the order of AI actions. These are all calculated for a specific instant in time. It does matter what order different types of calculations are done, such as if the positions are updated before or after the draw commands are fed to the GPU. And that brings up the real limit, GPU draw commands. Vulkan allows these to easily be split across multiple threads. Doing so was the primary reason Vulkan was created in the first place.

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

Vulkan will be add with this update below, I'm thinking? This would not effect the asynchronous.

what is being refactored/rewritten does use multi-threading where possible.

 

atm the major parts which do it are:

resource loading and other I/O (logging, input, ffb ...), integrity checking, sound

 

w/o rewriting the engine, splitting simulation into a separate thread from the graphics will benefit it most - which will be, in fact, the mentioned client-server approach, just inside the app.

 

The post

 

Client-Server approach ! Thank You.

Tons of useful apps took this approach, almost standard in Linux btw.

So this sounds like it will come with the ded. server. That makes perfect sense.

Kicking StarF$$$ into the bin is a welcome thing too, everybody seems to be fed up with it, from user to devs. Great ! Less overhead is always welcome.

The threads in that pic are StarForce copy protection and the sound engine from the looks of it. What needs breaking up is the graphics engine and game logic. Vulkan allows the graphics engine to be split across multiple CPU threads.

 

As for what can be run asynchronously, that's not a real problem. It doesn't matter what order the positions of each unit are updated or the order of AI actions. These are all calculated for a specific instant in time. It does matter what order different types of calculations are done, such as if the positions are updated before or after the draw commands are fed to the GPU. And that brings up the real limit, GPU draw commands. Vulkan allows these to easily be split across multiple threads. Doing so was the primary reason Vulkan was created in the first place.

DirectX 11 and 12 API's are both Multi-Threaded, (DirectX11 Initially was coded to be single threaded, and was patched to have multi-threading enabled, so it barely works if at all)

The Issue w/ DirectX11, is the amount of processor it takes to process and decode DirectX Instructions before telling the GPU what to do.

DirectX 12 and Vulkan, are classified as "Low Overhead API's" meaning they have little to no CPU Overhead on Draw Calls/Processes/Instructions.

DirectX12 alleviated the problem considerably from DirectX 9/10/11, but it still has issues, and even then, the Engine has to be coded to use the features of DirectX12 Correctly to make use of the Low Overhead API.

E.D. Could Simply Convert and Patch in DirectX12 easily if they wanted to, but there would be no performance gain as the engine was not coded to use the specific functions and instructions of the DirectX 12 API, the only thing E.D. would be doing is Limiting their User Base to Windows 10, Re-Coding the Engine, would show some performance increase, but at the cost of dropping Windows 7 and Windows 8 Support.

Now, Vulkan on the other hand, is a Cross platform Low Overhead API, so, Converting to Vulkan, will Allow E.D. to utilize a Low Overhead API for their Graphics Rendering, but will not force them to Drop Windows 7 or 8 Support.

Now, Vulkan on the other hand, is a Cross platform Low Overhead API, so, Converting to Vulkan, will Allow E.D. to utilize a Low Overhead API for their Graphics Rendering, but will not force them to Drop Windows 7 or 8 Support.

As someone who's probably going to hang on to Win 7 until MS stops to support it, this sounds like very good news. :thumbup:

MS Already Dropped support for Windows 7.. lol

MS Already Dropped support for Windows 7.. lol

rip that guy lol

MS Already Dropped support for Windows 7.. lol

Care to elaborate?

Care to elaborate?

Yurgon,

I'm not sure if you're providing additional data or if you are refuting SkateZilla's point.

In the document you linked to, it says end of support for mainstream for Win 7 was 2015. And it's already end of sale.

Win7 is dead. The only fixes MS delivers are security patches, there is a HOLD on new features and error correction. They only fix what they really have to.

Win7 has so many drawbacks vs 10, updating to 10 is a pain reliefer imho.

Win7 is dead. The only fixes MS delivers are security patches, there is a HOLD on new features and error correction. They only fix what they really have to.

 

Win7 has so many drawbacks vs 10, updating to 10 is a pain reliefer imho.

That's what I'm going to do soon!

In the document you linked to, it says end of support for mainstream for Win 7 was 2015. And it's already end of sale.

Win7 is dead. The only fixes MS delivers are security patches, there is a HOLD on new features and error correction. They only fix what they really have to.

 

Win7 has so many drawbacks vs 10, updating to 10 is a pain reliefer imho.

Well that's the point. Win 7 still receives security patches.

I'm not looking for new features. In fact I feel quite comfortable with the system. But thanks for telling me how I should feel about it. :smartass:

In the meantime, it's a relief to see a decrease in the problem reports that are directly related to Win 10, like audio devices that stop working for no apparent reason, updates taking place and changing things for no apparent reason and with apparently no user notification and so on. Thanks for squashing all the bugs for me. :D

With DCS, it is at least labeled Early Access and/or OpenBeta/OpenAlpha. ;)

By the end of extended support for Win 7, or when new features or new hardware require Win 10, I'll certainly make the switch. Until then, I like to believe there is some truth in the mantra to never change a running system.

Yurgon,

you may partly "keep it as it is" but there are software products installed that you have to update, Firefox, Chrome, etc etc...actually all but the OS in your case.

I do respect your choice, I maintain several 7's myself for business use, very limited work scenario.

But the systems we run with Windows, online, you just cannot afford to put a hold on all updates. So that expression is somewhat biased, Software YES but Operating System NO.

That will only work for that long, until you stumble across an app that says "unsupported OS".

I have put 10 on the new Ofiice machine, 1600x, but all others remain 7's, knowing the linitations I accept and the problems I just postpone. Ther eis virtually no escape, sooner or later we all have to step up ;)

The biggest flaw in 7 is "svchost", they constantly fix it and it still grows out of control.

This "superservice" is the culprit for many mishaps in 7, for example the "ultra-long" searching for updates, sometimes for days on new installed machines. That alone wants me to grab the 10 stick..honestly. SVCHOST sux big time. Google it.

you may partly "keep it as it is" but there are software products installed that you have to update, Firefox, Chrome, etc etc...actually all but the OS in your case.

No argument there. :)

Ther eis virtually no escape, sooner or later we all have to step up ;)

I know. :(

Like I said, when extended support runs out or some software (like DX12) requires a newer OS, I'll make the switch.

But that's exactly why I was pretty happy reading about Vulkan and Win 7 support by DCS: It means that one of the most important applications I run won't force me to Win 10 in the foreseeable future. :thumbup:

Those hanging updates, yeah, noticed them once or twice, used WSUS Offline and manually installed the required patches that brought down the search for updates back to a few minutes.

On the plus side, it is possible to completely disable automatic updates on Win 7. I wouldn't advise anyone to do that, but reading the IT news daily and reacting whenever necessary, I feel fairly confident that my system is more up to date than most others. And these updates don't happen while I'm working or playing or waiting for the damn thing to shut down. ;)

Vulkan vs OpenGL: 80fps vs. 50fps.

https://www.hardocp.com/news/2018/02/26/vulkan_now_available_on_macos_ios_by_moltenvk_being_opensourced

NICE !

Let's hope DCS will see the same benefit in Windows.

is dcs opengl or diiect3d?

i tend to get better performance with direct3d. anecdotally speaking :)

is dcs opengl or diiect3d?

 

i tend to get better performance with direct3d. anecdotally speaking :)

DCS uses DX11. DX12 is the follow on Microsoft solution and in theory offers some of the same benefits as Vulkan, ie. multi-core/multi-GPU support.

Vulkan can be used on different platforms (including Mac and Linux). Not much out for it so far, but the games that are (e.g. Doom, Wolfenstein) show some very interesting potential performance benefits.

ED have announced that they're working on Vulkan, so hopefully we'll be getting that this year.

what we really need is DirectVR in DX13 :)

DCS 2.x / 1.5+ Uses DirectX11_0

DCS 1.2.16- Uses DirectX9_0

DirectX9c is a High Overhead API

DirectX11 is a High Overhead API

OpenGL is a High 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).

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.

Thanks a lot Skatezilla, for showing us the big picture in such a clear fashion :)

Thank you, we needed that !

Vulkan, FTW :)

thanks for that Skatezilla. it actually brought back some ancient memories.

my first rig i built in 96 had a matrox millennium. doom and dune, not so good for quake.

and i upgrade to voodo2 in 98. 3dfxglide was an eye opener. so was half-life.

and then jumped ship to ati in 2000, because 3dfx glide was dying and it only supported opengl and not direct3d in windows.

now its been NVidia and has been for over a decade.

you forget how quickly things changed then. my current mobo and ram are nearly 7 years old..

unthinkable back then :)

Great post Skatezilla, you have just written my whole gaming biography, I remember all of those events going way back to the last century.

DCS: not only do you get to fly planes and blow stuff up, it's also very educational.

Yeah, 3dfx Voodoo card was *THE BOMB* I remember one consulting gig (was there to troubleshoot why print jobs weren't working, to install some firewalls, etc) and got to talking with the IT director. I solved the printing problem so we had some time to kill. I mentioned how much I loved flying sims and Doom's of the world and how it would never work w/o 3dfx card. He said "wait a minute....it'll make games/graphics sing?"

Next day, he dragged his home computer in. I installed it for him, loaded the drivers etc. He was a big RC plane guy and had a real live RC controller that interfaced with a plane on the computer. He was blown away by the polygon hills that painted "instantaneously" instead of wireframes etc.

And look at DCS 2.5. Simply amazing. I couldn't stop grinning doing touch-n-go's with A10 in VR.