in development Vulkan API Discussion

If you read just before,

 

it means they are transferring shaders since then because there's A LOT of them.

 

 

S!

I am interested in what the actual shader work consists of, not about the DCS status. You misunderstood or I have not been clear enough.

I think that example can help.

http://diligentgraphics.com/diligent-engine/shader-converter/

I am interested in what the actual shader work consists of, not about the DCS status. You misunderstood or I have not been clear enough.

S!

98abaile, It's well documented that Vulkan allows far better distribution of workloads across mutliple CPU cores and offers parralel tasking features. Vulkan is an interface, not a graphics engine.

Linus of LTT recently did a video about overlocking an 11 years old computer with a special motherboard with 2 cpu sockets. The game did HORRIBLY in traditional DirectX on most stuff, then he went on to test it on Vulkan games and it was crazy - he had Titan graphics cards that weren't used by the game because the CPU was bottlenecking it, moving to Vulkan le the game use the CPU so much better that he achieved smooth 100 fps gameplay at high settings on a game that would previously struggle to not stutter at low settings.

I don't think Vulkan is coming anytime soon to DCS, but it will be groundbreaking when it finally does!

Yes the potential with Vulkan is high, but id software people are the bleeding edge when it comes to that stuff, Doom 2016 is heavily multithreaded by it self, not just the graphics side of things.

So Vulkan alone may not rasie the bar as much as if both the Vulkan and the whole engine would get a revamp in the CPU area.

So Vulkan alone may not rasie the bar as much as if both the Vulkan and the whole engine would get a revamp in the CPU area.

That's why , my guess , multi-threading project on DCS is parallel to Vulkan port.

One doesn't make much sense without the other.

That's why , my guess , multi-threading project on DCS is parallel to Vulkan port.

Guys the engine is multi-threaded, its just not doing all the things we'd like to see it do. Some one started a thread showing some degree of performance scaling with various thread counts. The only way the extra threads are being leveraged atm is in IO it seems, but the engine is aware of them. DX/D3D11 doesn't easily thread well. The Vulkan implementation should then be able to work with that thread availability. We probably don't need a bunch of engine features to have there own thread, since the main issue now is the render operation must be last and tied to the main thread behind everything else. One of the areas of focus in Vulkan is in not having the GPU waiting, by various means.

Having searched through many pages of everything and all opinions etc I have not seen a

release date

for Vulkan implementation. I had heard early 2018, then late 2018 then early 2019 and with it being now late 2019 I am very optimistic it might be soon.

Is it please, has there been any dates or set goals posted yet☺?

thx for the feedback :)

Vulkan API is a high priority for the team, we do not have any time line yet however.

 

When we get closer to implementing we will share more information.

 

Thanks

Thanks for letting us know :thumbup:

And it should use Async Compute on day 1 IMO. Which is what makes Doom 2016 stand out so much. If the release would be postponed because of that, I'm fine with it. :smartass:

I do not agree such a new core type of change should come with an Early Access type of deal, new things when there is certain uncertainty should come in their best light at the beginning, instead of a gradual thing, it would all be bitter sweet after the update comes, it just makes drama too.

Except if, it's a big enough thing that would push back the release too far, like 2 years, or if a new big version feature drops shortly before release, ofcourse, within reason.

EDIT: Here's interesting thing, if Async Compute is still rare, and DCS focuses on it, maybe it'll be somethig that sparks interest with benchmarking, if some big channel does one benchmark that would give DCS some exposure it deserves, I'm not saying it as some hype trick, but it's so unfair that serious stuff like this always gets the WORST share of exposure with this gamer heads out there.

+1 again for Async Compute. That's one of my hopes too

And remember, we will really see results only when ps5 slim or something like that comes out, that is when the sony studios will show us how to use the new vulkan, rtx technology etc ... the rest is rumor or Azure AI

how many success stories are there with vulkan?

any titles go from mediocre to profits after the switch?

I hope some big benchmarking channel on yt does a deepdive video on dcs with its (hopefully) excellent implementation of vulkan and async compute. Even if it would bring only a few people on board. Like u said Worrazen serious and absolutelly amazing games like dcs only get a lil interest. While other companies are milking lil kids on rather bad games.

For some reason it took me so much time to actually remind to check about draw calls:

Test: First 2-11-2019

Release version

Nevada

F-18C Free Flight

-------------------

Stats for DCS.exe_2019.11.02_12.52.02_frame2528.rdc.

 

File size: 985.52MB (2507.34MB uncompressed, compression ratio 2.54:1)

Persistent Data (approx): 17.66MB, Frame-initial data (approx): 533.12MB

 

*** Summary ***

 

Draw calls: 2141

Dispatch calls: 162

API calls: 30045

Index/vertex bind calls: 4780

Constant bind calls: 4443

Sampler bind calls: 143

Resource bind calls: 2306

Shader set calls: 6660

Blend set calls: 2179

Depth/stencil set calls: 2179

Rasterization set calls: 2309

Resource update calls: 2355

Output set calls: 504

API: Draw/Dispatch call ratio: 13.046

 

473 Textures - 1727.89 MB (1727.49 MB over 32x32), 56 RTs - 503.88 MB.

Avg. tex dimension: 1092.61x1215.78 (1163.82x1288.53 over 32x32)

2376 Buffers - 298.09 MB total 7.71 MB IBs 41.53 MB VBs.

2529.87 MB - Grand total GPU buffer + texture load.

 

*** Draw Statistics ***

 

Total calls: 2141, instanced: 763, indirect: 762

/////////////////////////////////////////////////

***********************************

/////////////////////////////////////////////////

Stats for DCS.exe_2019.11.02_12.52.02_frame102034.rdc.

 

File size: 916.39MB (2476.54MB uncompressed, compression ratio 2.70:1)

Persistent Data (approx): 5.82MB, Frame-initial data (approx): 495.11MB

 

*** Summary ***

 

Draw calls: 3706

Dispatch calls: 355

API calls: 50325

Index/vertex bind calls: 7413

Constant bind calls: 6359

Sampler bind calls: 359

Resource bind calls: 4541

Shader set calls: 11548

Blend set calls: 3708

Depth/stencil set calls: 3708

Rasterization set calls: 3952

Resource update calls: 4098

Output set calls: 890

API: Draw/Dispatch call ratio: 12.3923

 

809 Textures - 1603.49 MB (1603.01 MB over 32x32), 51 RTs - 475.79 MB.

Avg. tex dimension: 699.788x790.168 (722.512x818.678 over 32x32)

3252 Buffers - 411.89 MB total 17.85 MB IBs 47.55 MB VBs.

2491.17 MB - Grand total GPU buffer + texture load.

 

*** Draw Statistics ***

 

Total calls: 3706, instanced: 1927, indirect: 1927

Lesser difference than I expected as far as the pure number goes, the number doesn't mean anything it self, contextless, depends on how much the draw calls cost on a given API, for DX11, a lot, those extra 1000 draw calls are partially responsible for bringing down the FPS from 70 to 27.

DX11 Draw Calls are processed by a CPU thread before going to the GPU.

and DX11 isnt Multithreaded, it was updated to expand to be multithreaded, but it didnt really work very well as specific calls have to be done in a specific order so essentially its still single threaded.

More cores seems to be the hardware we`re about to get. You can expect the 4000 series CPU from AMD overtake Intel even in gaming next year. Guess what? They gonna raise the cores even more. At least thats what officials from AMD stated recently.

Right now only a very few games really take adventage from SMP, but hey - it`s the (close) future, and I really hope a so demanding game like DCS will move to massive SMP usage asap.

I would even help crowd-funding some dedicated developers for that topic ;)

More cores seems to be the hardware we`re about to get. You can expect the 4000 series CPU from AMD overtake Intel even in gaming next year. Guess what? They gonna raise the cores even more. At least thats what officials from AMD stated recently.

 

Right now only a very few games really take adventage from SMP, but hey - it`s the (close) future, and I really hope a so demanding game like DCS will move to massive SMP usage asap.

 

I would even help crowd-funding some dedicated developers for that topic ;)

It's actually unlikely that AMD is going to increase the core count on next GEN mainstream. The density increase of 7nm+ still doesn't allot the room needed on the AM4 package, unless they can shrink the IO die. They've already stated that there isn't going to be a change in core counts on the server package (which is the same silicon), so the CCD core density is likely remaining at 8. Physical changes more likely to happen are more cache and/or APUs with higher cores than previous gen. More cores is an eventuality though as ~5Ghz is the clock wall (before the power/thermal curve get out of hand) and IPC will eventually top out when they can no longer shrink features anymore. At some point more performance will only come from taking advantage of the increased density, for as long we're still on silicon anyway.

It's actually unlikely that AMD is going to increase the core count on next GEN mainstream. The density increase of 7nm+ still doesn't allot the room needed on the AM4 package, unless they can shrink the IO die. They've already stated that there isn't going to be a change in core counts on the server package (which is the same silicon), so the CCD core density is likely remaining at 8. Physical changes more likely to happen are more cache and/or APUs with higher cores than previous gen. More cores is an eventuality though as ~5Ghz is the clock wall (before the power/thermal curve get out of hand) and IPC will eventually top out when they can no longer shrink features anymore. At some point more performance will only come from taking advantage of the increased density, for as long we're still on silicon anyway.

I for one welcome our quantum germanium overlords. ;)

It's actually unlikely that AMD is going to increase the core count on next GEN mainstream. The density increase of 7nm+ still doesn't allot the room needed on the AM4 package, unless they can shrink the IO die. They've already stated that there isn't going to be a change in core counts on the server package (which is the same silicon), so the CCD core density is likely remaining at 8. Physical changes more likely to happen are more cache and/or APUs with higher cores than previous gen. More cores is an eventuality though as ~5Ghz is the clock wall (before the power/thermal curve get out of hand) and IPC will eventually top out when they can no longer shrink features anymore. At some point more performance will only come from taking advantage of the increased density, for as long we're still on silicon anyway.

Well, I dunno what your sources are. But from what I have found, the IPC will go up, the amount of cores will go up, the frequency will be at the same level or only very slightly go up.

Anyways, lots of users have newer Intel or AMD CPUs with 8 threads or even way more. My point was and still is: It would be nice if SMP would get more attention - as soon as possible. 9900K, 3900X, even a 3600X would perform way better if SMP gets more attention.

Currently I got the 9700K (8 cores at 5,3GHz - no multithreading) and DCS just don`t want to use all given cores - which is kinda sad :cry:

Well, I dunno what your sources are. But from what I have found, the IPC will go up, the amount of cores will go up, the frequency will be at the same level or only very slightly go up.

 

Anyways, lots of users have newer Intel or AMD CPUs with 8 threads or even way more. My point was and still is: It would be nice if SMP would get more attention - as soon as possible. 9900K, 3900X, even a 3600X would perform way better if SMP gets more attention.

Currently I got the 9700K (8 cores at 5,3GHz - no multithreading) and DCS just don`t want to use all given cores - which is kinda sad :cry:

AMD's own leaked roadmap still reads 64 core max for Zen 3 Epyc Milan. That alone suggests the CCD design isn't being bumped up. Further extrapolation from would suggest that to increase cores on Ryzen they would need a 3rd CCD. TSMC says there is a density increase of 20% with 7nm+. The math really doesn't add up given the current die size minus 20%, and the size of the GloFlo 12nm IO die. Zen 4 (Ryzen 5000) will be 5nm where AMD has suggested will be a doubling of cores, on their roadmap. I wasn't saying those other things weren't going to happen, just that the core increase likely won't be coming to Zen 3 based Ryzen 4000.

The IPC will be higher, and there will likely be a clock increase. What I was saying in regards to those things in my previous post was long term limits, getting down to 3nm-1nm. The byproduct of hitting those limits, means increased core density is probably going to be the only way performance will progress. Along with software being able to scale with threads. Common ways IPC goes up, is in shrinking the distance between components/features and being able to keep an adequate amount data in cache. Its my own speculation that there may be challenges in shrinking the IO features, which might have something to do with Intel's monolithic 10nm designs and why they will eventually move to chiplets as well.

The issue in DCS is that it's hard to get meaningful benefits from multithreading in the DX11 API. I'm hopeful that the situation will get better with Vulkan.