Vulkan API and DCS | USAF Sim/Wargame Developer Reacts

[@staubsauger2305]

Thanks Mike. A good presentation. I'm a developer who has worked with OpenGL for more than a decade. Here are some additional points: - DirectX was made to ease game development and while Apple and Unix were using OpenGL Microsoft decided on having its own API not only so they could innovate but it meant games ended up being written specifically for Windows, helping to keep users on their platform, and it worked. - Vulkan was create to give better performance on devices with weak CPUs such as mobile devices where OpenGL ES was running.On desktop CPUs the benefits are less mixed. - OpenGL ES drivers were complicated as the graphics driver writer worked hard to do the optimization and had to provide certified feature profiles. This made it easier for game developers. - Vulkan doesn't do nearly as much for you as OpenGL does. The upside is it gets out of your way so you have more direct control over the GPU and potential optimizations become available. The downside is the developer has to do more work to get good performance and the expert about the card (the CPU vendor's driver writer) can't help you as much. In this way you can think of Vulkan as a lower-level API closer to the hardware and OpenGL as a higher-level API, that is, similar to assembly vs C/C++. The trade off is higher performance at the cost of increased development complexity and much longer development time (hence, Eagle Dynamics is taking a long time and at great cost to go to Vulkan). - OpenGL is safer to use than Vulkan. If you get Vulkan wrong, it can go very wrong. - Vulkan's benefit isn't framerate on powerful CPUs, it is the ability to have lower latency, which matters in VR. - When Vulkan is tested on benchmarks versus modern OpenGL versions (eg. 4.x where shader programming is expected) then Vulkan wins some tests and OpenGL wins some tests. - Vulkan helps if you have a single-thread that is maxxed out and causing stalls in sending commands to the GPU. When programmed properly the GPU will always be 100% and the CPU is partially idle. Vulkan can't help if your GPU is already at 100%. - Some of the wins in going Vulkan is simply the allocation of developer effort to the application's graphics pipeline, which produces the modest gains if the pipeline is not well optmized for modern hardware. - Since the developer is responsible for making Vulkan work well, when hardware changes the developer has to update the application to keep best performance. With OpenGL the driver writer (who is far more expert on the internals of their hardware than most graphics developers) does the optimization for you. - Vulkan does beat OpenGL/DirextX in that some optimizations are available since you have more control over the hardware. - While developing an app in Vulkan is significantly more costly than using a higher-level API, once the work is done the user benefits without caring about the longer development time. - The performance difference between OpenGL and Vulkan is nothing compared to the real optimization, which GPU memory. In modern graphics the bus between RAM and video RAM (VRAM) is relatively slow - the real performance optimization is getting as much as possible into VRAM and keeping it there. Doing more work in shaders (that is, slower rendering) can be worth it if it prevents a lot of texture loading across the bus. - Adding more CPU cores can improve game performance if the GPU is waiting, but that effect is relatively minor for very fast single-cores and fast memory busses that can keep the GPU fed. This is why having 14 slower cores doesn't help DCS as much as having 4 very fast cores. - More and faster CPU cores can help a game by making everything else faster (I/O, netcode, AI units, aerodynamics/physics). That can result in higher framerate but that's because the CPU is not stalling the GPU, not because rendering itself is any faster. I hope this helps expand the general understanding of why Vulkan is good, but not an unqualified good, and how on very fast systems can make little difference - but is almost always helpful for VR. Please keep you excellent content coming.

[@TheOpsCenterByMikeSolyom]

What an excellent comment. Thanks for sharing. It helps to shed some light on some mysteries. You can see from my screenshots that I don't have a lot of cores. Yet I'm still able to get above 100 FPS even on relatively high settings in DCS. But that's because (like you mentioned) they are fairly high speed cores. Your comment also helps explain why ED wants to maintain DirectX in addition to going with Vulkan. There will probably a subset of the users that might get better performance from DirectX. In the end I think it will come down to how tightly coupled the individual tasks are within the code. If they can't be easily separated then no API is going to be able to utilize free cores. We shall see.

[@Blazs120gl]

The good thing in Vulkan is that it done right, it gives an uplift on machines that are otherwise aren't bad ones, they simply give what's rational to 99% of the PC users: multiple cores with lower turbo clocks and laptops with lower TDP and frequency budget. DCS devs have been carrying this technical debt for a decade now, expecting everyone to buy CPUs that can do 5GHz that are either too expensive to be a viable choice or just too impractical for anything else than DCS. DCS isn't scaling down well on graphics details for this reason as framerate is not really limited by the graphics demand (assuming you have rational setting relative to the hardware) but mainly how complex the aircraft/map/mission/server you're flying (=how much non-graphical workload is competing with the graphics pipeline). Just like with some other lightly threaded games like ARMA3, this will result in low GPU utilization, forcing the user to lower setting below what the hardware could otherwise do. Nvidia hardware/driver on DX11 is doing better than AMD as it creates worker threads on available cores/threads. However, this advantage offered by NV to counter a disadvantage of DX11 is no reason to punish buyers of AMD hardware which is otherwise a rational choice for everyone. This can be done with AMD as well on Vulkan (and DX12) explicitly by the programmer. This is where Vulkan forces the developer to understand how their very software works. X-Plane 11 is a fine example (+30% fps on a 2060S @ 1440p), but Aerofly Flight Simulator 2 did also switch to Vk, which resulted in a massive boost even on their new OpenGL version as they have actually understood how their OpenGL pipeline works and improved it as well. This is the reason why most projects switching to Vk will improve more than what's theoretically possible: even the baseline OpenGL/DX11 perfomance wasn't the maximum possible. IMHO, just because top-end GPUs and CPUs don't see that much of an advantage from Vulkan, it's still a strong reason to have it. Novadays one simply doesn't have access to affordable hardware so you play on what you have or what can be obtained. Mid-tier AMD CPUs and GPUs will benefit massively from Vulkan and it also helps to reduce dependency on strings-attached technologies. An optimized Vulkan renderer can deliver the same framerate at lower clock speeds. It's also resulting in much lower TDP (turbo clock power demand is not linear) and fan speed=lower noise (or more battery time on mobile systems). Another advantage of multi-core execution is that each core will have its own amount of cache so they'll less likely stall assuming the same work with the same data. In DCS, there are a lot of opportunities to split up simulation steps into parallel execution, but this requires DLC devs to work in this mindset. E.g. cockpit display systems not affecting the state of aircraft, could be done in a separate execution context as they don't have a strict timing requirement in the simulation, the player would not notice if e.g. MFDs or gauges have a latency of 5ms or 50ms. If we assume a stable 60fps, if a simulation step lags (due to inter-core data exchange) as much as 1 rendered frame, that is still only 16.66ms and even seasoned users will not be affected.

[@staubsauger2305]

@@Blazs120gl I have extremely good hardware. Vulkan will do nothing for me, perosnally. On potato hardware you now get slightly less potato, but at a ***much*** longer development time for ED. And when a new GPU architecture comes out ED has to do the work to optimize because the driver writer of the hardware can't do it for them. Vulkan has some strengths but it is not an unqualified good, which non-developers like yourself don't seem to understand - which is why I laid it out for you. > This is where Vulkan forces the developer to understand how their very software works. You understand this is a bug not a feature, right ? In this very video it was laid out early on before DX that every game writer not only had to write their game they also had to do a lot of work doing extra code for different manufacturers videos cards. Guess what, this problem is back although fortunately there are so few GPU manufacturers these days its less of a problem. Vulkan does give you more opportunities to optimize but it is not free, you have to do all the work - and part of my point is at the very high end the increased development time and cost of Vulkan is a mixed bad in terms of performance (sometimes Vulkan is marginally better, but sometimes it is also worse). The increased development time with Vulkan means some products will never make it to market, being abandoned during development because of the extra cost of Vulkan's longer development time. Like all engineering there are tradeoffs and a certain sign that someone doesn't understand these tradeoffs is when they are a biased fan of on tech. Sometimes in terms of performance Vulkan is better sometimes OpenGL/DirectX is better (although Vulkan and OpenGL are better than DirectX in terms of portability, which saves money which matters now that Android is also on the scene and the Windows-only world is long gone).

[@Blazs120gl]

@@staubsauger2305 I have a medium hardware which is reasonable for the time I spend flying simulators (mainly used to SW/3D development and gaming). As I mentioned, on X-Plane 11 I have a boost if 30% which pushed the frame rate into the active sync operating range (50 to 75fps, from the sub-40) which is a matter between yay and nay. The PC (2700X 32GB 2060S) wasn't a potato when I bought it and still not a potato today, hope we agree on that. I either spend my money on DLCs (income for devs), or hardware (no income for devs and DLC makers thus a lose-lose for both sides), Not bringing _you_ much to the table is no counter-argument for those who aren't looking for spending up just to fund technical debt. A technical debt that has never been so expensive on the customer end. A good example for the lose-lose situation: I've bought the Syria map but, compared to the Gulf map, it performs much worse, although there's no visible disparity between the two. Therefore I refunded it. This is where it becomes a conflict of interests, if ED and DLCs devs can't invest on improving performance, I can't invest in DLCs either. >> non-developers like yourself don't seem to understand I'm also a programmer and I've experimented with Vulkan programming for some hobby projects, even if not for long. I know how longer it is to do simple projects (e.g. a hello triangle, 500+ lines in Vk, you'll have to find out your pipeline, memory pool/management etc.) and also how much more hassle it is to debug. I know it's not free but no one said it was. Those trade-offs devs (like ED) make for performance vs time to market has become way off to favor the devs interests. ED has kept DX9 for way too long and has switched to DX11 way too late. Therefore I can't feel sorry for ED. A lot of devs have successfully transitioned their game to Vulkan and not all of them are big-time companies with endless budgets. Yes, it's hard work. Just because I'm expecting it in exchange for my money does not mean I don't understand how part of this work has no visible advantage to some. Until now, lot of ED's work has been of no visible advantage to me and now I'm hoping that the first time they'll the ones investing into the customers and not the other way around. Thank you for reading my opinion and I hope you understand my stance.

[@staubsauger2305]

@@Blazs120gl Thanks for clarifying > The PC (2700X 32GB 2060S) wasn't a potato when I bought it and still not a potato today, hope we agree on that. Sorry man. GTX 2060 is low end for a simulator. I hope that someday you'll find a way to acquire a newer card with the amount of Video RAM making the most difference out of anything. That's great you have done some graphics programming and realize how much *extra* work Vulkan is. Sure, better runtime performance can be had, but the amount of developer effort to achieve that is much larger than you'd expect. For a 5% improvement in Vulkan there could well be a 200% to 300% increase in developer time - and to retrofit a large code base would be even more complicated than starting from scratch (plus there is no such thing as a partial release, either everything is in Vulkan and production ready, or your production releases have to stay on a higher-level API). > ED has kept DX9 for way too long and has switched to DX11 way too late. Therefore I can't feel sorry for ED. I'm sure they would have changed already if it were possible. That added complexity of Vulkan make is hard to do - my original point. It'll be great when the work is complete but the reason we are waiting is because direct usage of Vulkan *requires* the developer to do so much more work. It is important for users to understand this so they have more realistic expectations of what might be delivered and when. Enjoy your flying.

[@Pricklyhedgehog72]

Thanks, Soly. It's essential software that will be a game changer, quite literally for DCS, and make it accessible for so many users with less high-end systems. The big winners, of course, the VR peeps.

[@TheOpsCenterByMikeSolyom]

Yeah, while I'm just speculating here on the performance boost for VR. I would bet money it will be significant and really make VR users happy.

[@skyhorseprice6591]

This points out an interesting idea, namely that VR users tend to think of advances in image quality in terms of advances in headset technology. Am I correct in saying that advances in core programming/rendering will make headsets perform waaaay better?

[@Pricklyhedgehog72]

@Skyhorse Price anything that boosts the performance of the games core engine interface with modern hardware should in theory, boost the performance of the headset.

[@teggy689]

@@TheOpsCenterByMikeSolyom Holy crap THIS. I love DCS in VR but it gives me head aches, I am running a high end system but it still runs terrible. Lot's of dropped frames and flickering. Compared to other VR games that look and run amazing DCS is really showing it's age.

[@Mark_Point]

With the new hardware and potential game engine improvement. You will all be VR peeps then!

[@kevinwinters4803]

One thing to remember is that DCS is also doing a lot of flight modeling outside of rendering graphics. Hopefully that too can be optimized to take advantage of more cores.

[@kazereal]

Flight and physics are upto each module so that is something module developers would need to adjust for. Multithreading that would need changes in both DCS core code and the API how it calls modules and how the different modules implement it. It is doable, but requires effort by both ED and module developers. You could do various things in modules (starting threads yourself instead of DCS calling into modules with multiple threads), but there are limitations to how useful this and there are problems that come up either way. Main thing in both ways is that modules would need to support multithreading which affects how data is handled and how code interacts with it (synchronization).

[@blkspade23]

Those things hamper render performance because of the pipeline, and because render is last in line. The modeling could likely become non-consequential once it's no longer holding up rendering. There is no way to measure what effect the modelling is having on the overall experience other than its effect on rendering. You know its a thing to be accounted for, but you aren't seeing errors due to its stage not getting the resources it needs. You see sub par GPU utilization. Multithreading is generally present in DCS, but currently only benefits IO.

[@efraimk1673]

9:17 no Mike.. I APPRECIATE you for making this video. Applause for the clean presentation and well put together content!

[@steeltiger5000]

Great job! Thanks for breaking this down and not burying non-developers in complex architecture.

[@TheOpsCenterByMikeSolyom]

I know what you mean. My brain melted while researching this stuff. I can only imagine what it must be like to people without a programming background.

Thank you for putting everything together so easy to digest way for everybody. It has been really hard trying to explain this to people.

[@toddwasson3355]

The same is true for D3D12 which I'm taking a crack at writing now. I'm new to it so there's a lot I don't know yet. The main thing with the multithreading is you're able to build command lists ("command buffers" in Vulkan as described in the video, it's the same thing) in parallel. On top of this, the CPU code doesn't block and wait for the GPU, so the GPU can work on rendering while your CPU code carries right on to the next cycle instead of blocking. By the time the GPU is ready to render another frame, the CPU has already created the command list(s) for it and simply hands it over. So it does open up a lot of parallelism potentially not only with CPU threads but with the CPU and GPU acting more in parallel. It gives you control over the three engines on the GPU separately as well: Copy, render(?) and compute. All three can run in parallel, so you can for example upload textures to the GPU while it's rendering or even running a compute shader simultaneously, and you have very low level control over all of it. I haven't done that last bit myself yet so can't say much there, but what I have done is tried some basic rendering (no textures or lighting/shadows, etc.) to stress test DX12 on a pure polygon level. What I found was I could render ridiculous poly counts, one example I made was a sine wave type 3D landscape with 134 million tiny little triangles (8192x8192 height map IIRC). This was very basic, just on a single thread, no texturing or lighting or anything, but it could do it at a pretty high frame rate. Here's the kicker: The CPU was sitting at only 1% use. The CPU fires off one draw call and then waits for the GPU to finish before doing it again. In a case like that, multithreading would be no help at all. If the GPU is loaded up at 100% you're not gaining anything by multithreading. It was all one draw call anyway so there was nothing to multithread. However, what it does mean is the CPU could start the next cycle, process game logic, AI, etc., while the GPU is busy drawing in parallel. In my simple example there was none of that, it was just rendering. I also rendered 100,000-200,000 cubes with separate draw calls (all with their own matrices so they can be moved/spun independently each frame) and the CPU was still quite idle. Again, the GPU was busy rendering all that so the CPU is just waiting. Again, multithreading that would not have made much difference. Anyway, what happens with DCS will depend entirely on the internals of DCS and how precisely it uses Vulkan (or DX12 for that matter) in the end. Without profiling it at the code level I couldn't even begin to speculate. One tricky thing with sims/games like DCS with tons of scenery is that they typically have to stream textures and other resources in and out of VRAM every frame. One of the recent games I worked on in Unreal 4 did that too and was the main reason we often had stutters in frame rate, often a frame would sit there for half a second before carrying on to a smooth frame rate again. Highly annoying and immersion breaking. It's mainly because the GPU has to stop and wait for some textures to get loaded or unloaded. In cases like that multithreading is not much help because it's limited by bus speeds. Then you just have to try to get more clever about how GPU resources are managed, but there's only so much you can really do there. Bottom line: If a particular game is already GPU bottlenecked (GPU is kept busy and not sitting around waiting for the game loop to hit the rendering section), multithreading or going to DX12/Vulkan might not matter very much. I have no idea if that's the case with DCS, so maybe they'll get a lot more performance with Vulkan and maybe they won't. Impossible to say as an outsider. Given how much DCS bends over when you throw lots of vehicles (even SAM sites/land vehicles) into a scene that are miles away and not even rendered, I suspect there are probably more performance gains to be had on the game loop side than the rendering side. One of the most expensive things is changing pipelines on the fly (changing to a different set of shaders between drawing different objects, for example), so if they can limit that or group them together (if they're not already) that alone could increase performance. At the same time though, those kinds of things become much cheaper to do on Vulkan/DX12 so it may be that even without changing algorithms significantly they could get some speed boost. How much is anyone's guess though. Just have to wait and see. It all comes down to the particular implementation, some games end up faster and some don't. I'd urge patience with the devs though. These are expert level APIs that are seriously difficult to work with and understand. I'm over a month into my project and I'm not even rendering with more than one texture in my scenes yet! :-D

[@TheOpsCenterByMikeSolyom]

Yeah I agree. As hard as it might be, patience is the best course. The devs have an incredible amount of work to do on this project.

[@staubsauger2305]

@@TheOpsCenterByMikeSolyom And therein lies the problem. While Vulkan can produce better framerates and lower latency for VR, particularly on lower-end hardware, the is a price in increased development time/cost. Since time-to-market is usually an issue this can be fatal for a project. Hopefully ED do better than average in this regard and avoid some of the bugs that increased complexity brings. The same consideration applies regardless of graphics API for all users - pay for the most VRAM you can afford, as transferring buffers across the bus (texture data but also geometry and shader data buffer objects) has the biggest effect on GPU performance. Game development teams that use engines (eg Unreal) where the low-level Vulkan integration is handled by the game engine team is a business savvy way to go.

[@Waffle4569]

Dx12 boasts performance gains, but ironically a lot of Dx12 titles are running worse than Dx11, probably because of the difficulty increase involved in implementing it correctly.

[@staubsauger2305]

@@Waffle4569 Exactly right. There is more control which can permit better performance, but at the cost of increased developer time, implementation complexity and risk that on new cards the optimizations may not end up as good (since the graphics driver now can't do it for you).

[@mr_whyy]

This is so good, and the details about it were really nice to learn, so thank you !

[@youtubeairways8646]

This will surely open up DCS to low-spec gamers/simmers.

[@wazza-au]

Beautiful video, your explanation taught me a lot about the differences (and reasons for them) between Vulcan and DX.

[@MrBrodyKnob]

GREAT video!! Thanks for putting this together. You did an excellent job.

[@madness8380]

Thanks Mike! Really appreciate this, very well put!

[@speed-of-heat]

That was a really solid brief. Thanks

[@Munky332]

I can't wait. Even if its buggy as hell at first. I can tell you Vulkan in XP11 was *fucking glorious* the last time I tried it. Simply offloading a lot of those threads that are limited to 2 "cores" would be a huge help, especially on multiplayer servers where the lua scripting gets jumbled in between those 2 cores and causes frame dips. Let's also not forget some of the shader and lighting optimizations, and, gasp, even freakin' raytracing, that's available in DX12/Vulkan.

[@theveryshinyone]

What an interesting video. Thank you. Learned a lot.

[@merefield2585]

This almost exactly the same transition CIG is taking Star Citizen through right now. Great to see DCS doing the same.

[@hmleao]

1 more subscriber here. high quality content is always appreciated.

[@after_midnight9592]

I have better hopes for BMS to make Falcon VR compatible than waiting for DCS to fix the engine for multi-core CPU and improved performance.

[@slammerf16]

They're still out there!! 😜

[@lowlevelheaven]

The final question. When? I may missed something in the video, but when we get Vulkan in DCS? 2023 2025. Ther is actual performance increase, but it is absorbed by more ditails and clouds and treasers.

[@gzaos]

Thank you for making me aware of BMS falcon.

[@rothn2]

I see a great opportunity here to add more nuance. Microsoft initially worked to support OpenGL and played a huge role in starting it, only to roll out its own competing standard a few years later. Also, Vulkan is explicitly not meant as a replacement for OpenGL according to a Kronos Group statement. It is for the people who want much lower level control of the hardware. These are likely large game studios and engine designers.

[@kazereal]

Close but a small correction. OpenGL was developed by Silicon Graphics to replace their own IRIS GL and one main difference was that OpenGL did not include certain patented and licensed parts from IRIS GL. Microsoft was working with OpenGL ARB and it was included in Windows too, but did not see as much support as DirectX did.

[@reptilianbrother5618]

Thanks a LOT for making this video!

[@nuggetz9857]

Very informative and helpful, thank you.

[@nuggetz9857]

Mike can I ask do you think Vulkan will also help with high VRAM usage, which is where my PC performance appear to be most demanding? Regards

[@shazam-253]

I remember the recent interview with Nick Grey, who said Vulkan is not going revolutionize everything, but be will bring some improvement. I would assume, they'll have the Vulkan part out first, where we'll see the 5-15% improvement. The update of the render graph for VR is probably something that'll happen a bit later, but if that's just another 20% on top, we would go from 50 to 65 frames, which will be noticable in VR!

[@pancakeoperator]

Just giving you guys a heads up, not sure if you just jumped into dcs. It ain’t happening anytime soon

[@vermin1970]

I’m not currently having any performance issues on my not quite up to date hardware at full settings in dcs

[@tb100]

I literally only understood the last 2 minutes of the video, but those 2 minutes say it all

[@mitch_the_-itch]

WinG was the precursor to DX. DCS VR desperately needs this. So even though the combined res of the G2 is about the same as my 4k monitor it needs two pipelines instead of one. That is what I was having trouble understanding. Thanks! Version 2.8 is on the verge of dropping do you suppose we get any Render Graph - Vulcan stuff?

[@JD96893]

if you want to see the true potential of Vulkan API you need to play games that were specifically developed with it in mind. Like Doom 2016 for example. Red Dead and mfs werent developed from the ground up for Vulkan.

[@bluewater82]

I really hope this brings some noticeable VR improvement. I’m so tired of having stutters despite having an 8c/16t processor (5.1 all core) and an overclocked 3080.

[@FelipePeixoto1991]

What VR headset do you use?

[@philippedemoulin2902]

Excellent explanation. Thank you.

[@mrdriver511]

My system is a 8700k with 16 gig of memory and a 2080 super, my graphics card is working at 100% in DCS would Vulcan improve the FPS or would it stay the same?

[@gregorverstraelen3347]

Anyone knows the timeline for the implementation in DCS?

[@Lisa-Azra_Broad]

Thanks for a very informative lecture :)

[@kenhelmers2603]

Nicely presented - thanks!

[@carymcrawford]

Thanks Mike. I so want my VR above 33 fps.

[@Shadow__133]

Maybe in the next decade?

[@jwbflyer]

Have they given a timeline for implementation?

[@Goit_Goit]

i'm expecting to see this update in two weeks.

[@SnowTiger45]

So it all sounds great. How do I/We implement this ? OR is this something that DCS has done for us requiring us to have to do nothing ? I have a new high-end gaming system (Built Myself) with a RTX 4090 Gaming Trio X GPU and tons of ram and CPU speed. I also have the HP Reverb G2 VR headset which I have yet to use because I'm waiting for Cataract Surgery. But I'd like to know I have everything set up and ready to rock for when my eyes have healed. So I'm asking what if anything I have to do to make the most of DCS's Multi-core threading ? Thanks in Advance.

[@mgplaying8435]

Any hint when it will come?

[@joeyjoey7972]

does anyone know when EA will implement Vulkan for DCS? they did mention it a couple years ago but not much since.. please not 2 weeks..

[@Isimus]

Very informative. Many thanks!

[@TheRadiag]

Something really important which didnt get mentioned is that no amount of better CPU Utilization will get you large FPS increases, unless you also have more available GPU power, I highly doubt any gains above 15% simply due to that fact. Of course its going to be more efficient, but the GPU will still have to do all the heavy lifting. I'd keep my expectations low, vulkan isnt going to be a silver bullet. But I can see bigger gains for VR.

[@bogdanrotaru6101]

when will DCS run on vulkan?

[@CMDRSweeper]

ANd one missed point... Vulkan is platform agnostic. So if you are on something other than Windows or you do not want to give Microsoft your data or limit their data with Win 11. Using a Vulkan API you can both get better performance under Linux and make it run better.

[@fullspecwarrior]

Came here to write this ^^^. With DirectX you are bound to Microsoft. With Vulkan there could be a Linux version of DCS or even a PS5 (MUCH less likely). Currently, if you have a top end GPU in VR you are probably gonna be CPU bound, i.e. we really need Vulka AND multi-core support, together to see the real gains we're after. Doing one at a time makes sense though.

[@WilliamDeanPlumbing]

When did eagle dynamics make this announcement?

[@cbz3237]

Excellent video!

[@new_comment]

Nice presentation. I really wish they would do something, with my build I get crazy good performance on my other sims, but in dcs it's pretty lackluster, it's very playable but the buffers and frame rate dives really take away from the experience, close ground attacks and smoke usually cuts my frame rate in half

[@jstorm7757]

Thank you!! I enjoyed seeing the graphical explanation. Unfortunately it's all based on a very optimistic dream that ED does all that is needed to properly utilize the most of the Vulkan API.

[@TheOpsCenterByMikeSolyom]

Yeah, it is purely speculation. But at least on my system there is spare processing power available. If they can harness it then people in my situation can see a dramatic improvement. Of course everyone will always question the "if" part. 😁

[@jadavis1000]

When are these changes going to be implemented?

[@astrixau8928]

No mention of Mantle? If not for Mantle Open GL couldn’t compete with Direct X in my opinion. We can thank AMD for creating Mantle then gifting the development to OpenGL to keep developing it as Mantle was designed on a AMD’s OpenGPU strategy. I used to use AMD GPU’s so I know all about it. And their OpenGPU strategy. It was actually co developed by AMD with the help of DICE, hence DICE had the first Mantle game BF4. If I remember correctly the Dice Dev co founded a studio his name is Johan Andersson. The studio is Embark Studios.

[@danielc4296]

I don’t understand, in my system all cores are doing exactly the same all time when running dcs. This was after an update I believe last year when they said they had added multiple core support. Am I doing something wrong?

[@S3NTRY]

Really great insight, thanks!

[@Because_Reasons]

The biggest issue with DCS is how CPU bound it is, so they need to be able to do multi-core effectively but there are no doubt challenges especially for multiplayer.

[@3d1e00]

Multi GPU supporting Linux version please.

[@optimal9094]

Great content. But even with my 3080, I still see the GPU pegged to max in single player scenarios, and rarely see my ageing 7700k anywhere close to maxing out that single thread. While in complex MP the gains will be surely fantastic and otherwise it will probably open up more complex NPC simulation, in the current SP scenario would it really deliver gains when the GPU fully loaded already?

[@TheOpsCenterByMikeSolyom]

Probably not. But every situation is different. It might be beneficial to others, and they did mention they would support multiple APIs. So you should be able to pick which is best for you.

[@ramtin-s8722]

Wow hope your results estimation will be the reality...even if it’s close to that it would be a game changer regarding VR and performance...it would open acceptable performance also for lower end hardware ..I am lucky to have a high end system and with the openxr I am managing to get very acceptable performance...but looking forward for everyone to join in on the wonderful experience

[@TheOpsCenterByMikeSolyom]

I hope they're able to realize some of those gains. But multi-threading is tricky and I have no idea what the inside of DCS looks like. On the bright side there is plenty of potential to work with. On my system DCS doesn't even use up 1/5 of the available CPU. Lots of room to grow there.

[@minewolf3605]

Something I would really like is rendering text outside of texture so DCS become actually playable on low settings

[@mikaelhogberg627]

Any ideas when vulkan is coming?

[@SteelbeastsCavalry]

They are very tight-lipped

[@kurtb369]

VERY interesting ! would you be able to discuss various parameter setups to achieve optimum results playing DCS with VR HMD ? I believe majority uses SteamVR to play DCS ( Vive / Reverb G2 / Pimax ) and the Oculus users.

[@Topper_Harley68]

Better to use OpenXR than SteamVR. That can improve your fps by 20-30%.

[@kurtb369]

@@Topper_Harley68 nope, it is a "myth" which only supposed to work for Rerverb G2 / WindowsMixed reality HMD

[@henryoshea4951]

Any idea when it is coming? ED said they were almost ready of an OB release on November last year

[@TheOpsCenterByMikeSolyom]

That's a question only ED knows the answer to. Their last update was in October and they mentioned being about 3/4ths of the way through their list of tasks then. In early 2021 they thought they would have it ready by the end of the year. Obviously, that didn't happen. My best guess is that it is "soon". Also, their initial release may not be everything I mentioned in this video. It could be Vulkan wrapped in a render graph with a multi-threaded optimization coming months or years in the future. Or maybe we get everything next month. 🤔

[@sahhull]

@@TheOpsCenterByMikeSolyom Coming soon DCS(tm) So in reality... 5 to 10 years 15 years if you dont want the bugged as shit beta version. Chances are, you will have upgraded and changed your PC a couple of times before its an issue.

[@armhunter]

any estimation on when this might come out? This is exciting.

[@Whiskey11Gaming]

Soon(TM), probably Two Weeks (TM) at the latest. Kidding... it happens when it happens. Maybe the end of this year if we are lucky.

[@armhunter]

@@Whiskey11Gaming haha.. yea, I bet its take quite a bit of time to convert something that big and intricate. New GPU's and CPU's will be out soon that will also give everyone a huge boost.

[@depapier]

Vulkan is great when the application is written for it. When its adapted, the win in performance is quite limited. Perhaps between 10 and 25 percent.

[@brunogm]

DXVK falls in what range?

[@depapier]

@@brunogm dxvk falls in the range of gambling at the poker table, depending on code and hardware.

[@depapier]

@FreeBirb No, its great when it works, no argument about that. Although no, there is quite a bit of dev work on implementing it, which is way more than a dollar, since as you know rendering engineers are perhaps the most costly ones in game dev. Its just that its been used too often as a saving grace type of thing for dcs. Imho they still need way too much work on the engine, before such things as vulkan will pay off. But we'll see, fingers crossed.

[@kendavid7082]

Nice video. Thanks!

[@maotseovich1347]

How much can we really expect from developers who only occasionally bother to include LODs, and even when they do, take upwards of a year after release to add them?

[@robertzurawiecki7837]

I will say the only thing I think is inaccurate was your supposition that going from 17 to 34% CPU utilization would double your framerate. That would be nice, but likely an "ideal scenario" only. Frame rates aren't solely CPU dependent, especially in VR. Will it improve performance? As long as you're not using a lower powered GPU that is the bottleneck, certainly. I would say though expecting a 100% increase is far too unreasonable. If we could get a 30% increase even that would be awesome. Look at games like rainbow 6 siege or ghost recon break point, which were written with DX only and updated to support Vulkan later. I experienced about a 10% increase overall in average fps, but the important part was higher minimum rates (less cratering during busy scenes) and smoother overall performance (the counter graph is smooth and not jagged with greatly reduced stuttering).

[@TheOpsCenterByMikeSolyom]

That's a valid point. I think people would be happy with what you described in R6.

[@jubuttib]

Wanted to hit upon that as well. If the CPU being able to feed the GPU was the only performance limitation, that could be true, but in most cases it's not. DCS can be REALLY wonky about how the performance behaves in different conditions. As an example of this checked my GPU load and frame rates in different conditions (for reference I'm running the game on a 120HZ 4K main display, and have two 1440p 144Hz display flanking it, but those don't show the game. CPU is a 3900X, GPU is a 3080, and I have 64 GB of RAM): 1. Load up a Caucasus Free Flight & Practice mission, which has over a 100 assets going around the place, land, sea and air. I loaded myself up on the Tarawa in a cold & dark Harrier, and was getting around 40-50 fps sitting in the cockpit, with GPU load hovering in the 60-67% range. Clearly GPU wasn't working at full tilt, so you could hope to get more FPS by optimizing the CPU side of the game. 2. I create a new mission, with nothing in it except a cold and dark A-10A (FC3 plane) at Maykop-Khanskaya. Sitting in the cockpit and looking around I get 25-35 fps with GPU load being between 96-100%. Same for going to F2 view and looking around. (This was a complete surprise to me btw...) 3. In the same mission from number 2, I go to freecam, move a few kilometers north to an area where there's nothing but fields, and push the camera into the ground, so that all I can see is a tiny patch of grass. I'm getting 105 fps and 97-100% GPU load. So in 1. we have a clear case of CPU bottlenecking, leaving GPU load very low, and middling FPS, in 2. a situation with no CPU bottlenecking and awful FPS (despite a super simple plane etc.), and in 3. a situation with no CPU bottlenecking and great FPS, when almost nothing is drawn. Would appear that populating the threads on the CPU better (12 cores and 24 threads to go around) would probably have helped in case 1., but not in cases 2. and 3. Improvement need to happen on the render thread optimization as well to get the performance consistency better.

[@andrewsmith2404]

Great video, thanks!

[@_Jake.From.Statefarm_]

To developers out there.. my understanding, besides the trade offs, and what has been mostly shared around the dcs community. Are features suck has DLSS, FSR waiting to be implemented because of the new API? I'm not sure how graphic features are implemented as I'm not an engineer but it seems logical that with the release of the new API features like this will be adapted as an option? I know a lot of mods are out there and openxr does she wonders but true DLSS support would be pretty big.. especially if it works for VR.

[@EagleLeader1]

Hadn't heard about this but I'm excited, my midrange gaming system could use a boost on DCS. When does ED expect to roll this out?

[@TheOpsCenterByMikeSolyom]

The last official thing on them wasn't a release date but rather an assurance that it will not be any time in the near term. I wish it was sooner but, it's a huge undertaking so I know it will take time to get it right.

[@EagleLeader1]

@@TheOpsCenterByMikeSolyom thanks for the reply/answer. Makes sense, based on your explanation it does seem like it would be a huge undertaking.

[@fr3ddyfr3sh]

What he says about Vulkan, mostly applies to DirectX 12 too. It might be named differently, but the fundamental concept is the same.

[@004307ec]

but why not choose dx12? Maybe future release on Linux?

[@TheOpsCenterByMikeSolyom]

I'm wondering that myself. One of Vulkan's big selling points is that it is cross platform. Though ED hasn't said so I do wonder if they are thinking about going to other systems.

[@DJHazzard]

and Ubisoft is working on Scalar which is supposed to revolutionize game technology... simply explained, they want to outsource calculations from the games to cloud/server... which then come back to the home pc. Imagine the DCS MAP and AI would be calculated by several external pc (CLOUD) and then my computer would have to work much less... that's how I imagine it. THX for the Video !

[@JasonBlack66]

oh I could use some improved performance on DCS. Especially while using VR!

[@FACrazyCanuck]

Thank you for the great explanation. Looking forward to Vulcan. “Live long and prosper”. 😁

[@OLIV3R_YT]

Thank you!

[@sundhaug92]

1:44 dx12 actually changed things massively when it comes to efficiency, it's kinda like Vulkan to OpenGL

[@TheOpsCenterByMikeSolyom]

Exactly. DX12 is a big deal too. ED might bring that in someday as well. That's one of the advantages of a render graph: modularity. But I imagine their plate is pretty full with the Vulkan implementation right now.

[@WyldestZakk1980]

Doesn´t that mean, that it could be Run on a Linux system?

[@TheOpsCenterByMikeSolyom]

One of Vulkan's strong points is that it is portable across environments. But I have not seen anything from ED indicating that they are working on a Linux port. Would be nice if they did.

[@bjsracer]

Good work

[@Megalomaniakaal]

1:57 - wrong, the Khronos group had been working on cutting the fat from OpenGL targeting version 4.6 in an effort/project called AZDO or "Approaching Zero Driver Overhead". In the meanwhile AMD and DICE(FPS shooters developer owned by EA with their own in-house engine called frostbite) were collaborating on developing a prototype 'next-gen' low driver overhead API called Mantle, which once they felt it was sufficiently proven as a concept they handed over to Khronos for it to be reworked into Vulkan. Meanwhile AMD was also working with Microsoft on a next gen API with primarily their new XBox One consoles in mind that became the basis for DirectX 12. Also, since apple was using AMD GPU's and had always been having a hard time keeping up with OpenGL versions changes as well as same for OpenCL (all because Apple is adamant write and maintain their own codebase rather than do what MS does and let the HW vendors write the drivers for their own HW) AMD and Apple worked on a new low overhead API also for Apple - Metal. All the next gen API's are essentially to some extent derived from Mantle.

[@magnetic333]

The dream: DCS Rewrited with Rust code and vulkan API and optimized by IA for code ! Rust is efficient, fastest C++ near C! Memory is protected

[@blameusa7082]

well if it can run for more than 20mins i will be happy. PC ranks as UFO on the grading site.... yet crashes on DCS every time, no other game ever had 1 issue

[@T-Cup314]

Very well done 👍

[@tomatojuices5340]

So, when?

[@TheOpsCenterByMikeSolyom]

Unfortunately, it looks like it will be a ways off. One of the ED devs posted on the forums that it will definitely not be in the near term.

[@tomatojuices5340]

@@TheOpsCenterByMikeSolyom ah that's too bad then

[@pn641]

@@TheOpsCenterByMikeSolyom when ED says near takes years I wonder how long it will be the not near...

[@Smokeyr67]

It would be great if Multi GPU’s was a viable option, currently that’s the choke point for me in most sims and games.

[@RaedAdlouni]

Great video, thanks. Now if we would only convince ED to actually accelerate working on this. They went silent since the last announcement they made on Vulcan last year. Since then I believe this was put on the side and the focus was on new modules like the Apache. Wonder how much longer do we have to wait :-(

[@eranmalloch]

I'm sure they're going as fast as possible. Trust me, this is NOT a simple undertaking. It's not like painting the walls to "renovate" the house, but instead, it's like knocking the entire house down and building a brand new one from scratch. It's a massive undertaking and expensive.

[@TheOpsCenterByMikeSolyom]

Eran Malloch is right. I just touched on what the technology is about. The really hard part is getting those threads to play nicely in a multi-threaded environment. That's also the place where we would see the most gains if the devs can get it right. So we'll have to wait on the final product to see how they do.

[@tonyascaso6254]

Where is Vulkan ED? Not a peep.

[@peterstubbs5934]

So how do I get DCS to run with Vulkan rather than DirectX?

[@DerekSpeareDSD]

Great explanation, Mike and a pro level presentation of the ideas. Tell me, in your opinion, if DCS (or other game) runs Vulcan does that mean it will utilize more cpu cores? Does this mean, then, if yes, would a user benefit from having a CPU with more cores on it instead of focusing on single thread performance ones?

[@sildurmank]

I believe devs already explained those two are different things. They said indeed that it's quite possible multicore feature could be released before Vulkan core itself.

[@TheOpsCenterByMikeSolyom]

It really depends on two things: 1) How much effort they want to put in for improving multi-threading performance. After all, they could just go with the lower overhead of Vulkan and not worry about splitting out the load. 2) How much of the logic can be untangled. If its all tightly couple it might not be easy to split it up. However, there certainly is room to grow. On my system I only see DCS using about 17% of the total power. On missions with a lot of units one of the pipelines on my CPU ends up getting overloaded. But if they could split that up there's over 80% of the CPU (other cores and threads) available to pick up the workload. The Gnomes video does a good job of showing how much that work that can be spread around with Vulkan and good multi-threaded code.

[@flightsimstuff5417]

@@TheOpsCenterByMikeSolyom #2 is, to me, the hardest part, "Concurrency" issues, sorta like: two operations can't 'touch' the same piece of data simultaneously. Sound is an easy one (and perhaps a bit of a contrived example): once a sound is put into use, you never have to touch the data (that makes up the audio) again, and thus can be handled by a separate process. However, if say, you needed to modify the sound data midway through playing it (for whatever reason) you now have two 'hands in the cookie jar', both trying to grab the same bit. My mind isn't good enough to see how you could ever solve this problem 100%. Been a long time since I messed with this stuff so things might be different/improved. Excellent video BTW, thanks. Should help the DCS users grok things a bit more. Your point on VR: I often wondered if DCS was sending the graphics output through twice. Seemed so. The transformations (math) might be, offhand, a perfect spot for parallel processing. And I'd think that could be done already, regardless of Vulkan.But again, it's been a while and I've never used Vulkan. Getting the pixels to the screen though is likely still an issue. In the end, a 25% improvement, in VR, is about all I expect from Vulkan & Multi-core changes. Your point about DCS being a long-term project (not a throw-away like most twitch games) is a good one - it's the only game in town (for us VR types).

[@go_dzilla5921]

Would be nice if ED made the change optional though. You know, rather than just switching to Vulkan, maybe just add a dropdown menu in the graph options where peeps can choose between DX11, DX12 and Vulkan. That'd be cool.

[@Grim_Prospects]

There would be no point. Everyone would just choose Vulkan with its massive performance increase, and it would just be one more piece of code and creation that would be a time hog.

[@aaronjessome1032]

Vulkan runs really well on lower end hardware. If you played Doom 2016/Eternal than you've played it before.

[@Djmaxofficial]

Low end gpu hardware doom 2016 🤣. I can't even run this game, i get message no gpu support. Also my gpu dosen't support vulkan.

[@S1lverspike]

I’d just like to not get 20fps while I’m taxing.

[@pn641]

I don't think that we will see DCS Vulcan in this life

[@outsidein3206]

Wait wut, VR streams two video streams one for left and right eye? If so, how is that practicable or worth doing over same image to each eye? #ImNotAnOptomotrist

[@TheOpsCenterByMikeSolyom]

You could do one single screen in a set of goggles. But to replicate how we see things in real life you would need to vantage points that are separated slightly. That slight separation is just enough for us to be able to get depth perception, and its how VR gives us that uncanny feeling that it is more "real" than it actually is. A single screen would make it feel like just like a monitor.

[@outsidein3206]

@@TheOpsCenterByMikeSolyom Hi +1 Was thinking along similar lines ^. Then the consideration when recalling the VR headsets where you put your phone in, which is a single screen. Ive never tried one of those to compare against a PC VR headset.

[@slammerf16]

@@outsidein3206 Those headsets (like the Samsung Gear VR) rely on the phone creating two images - one for each eye. if you pop the phone out of the headset you can see both images at once, but they're very slighty different to give you that stereoscopic 3D effect.

[@outsidein3206]

@@slammerf16 Thats Interesting. So id then wonder why a PC creates 2 complete images. PC could also Alternatively use the same image, but with different aspect ratios / viewing angles as a phone method uses. So instead of rendering 2 complete different images for PC VR it would use the same image but display 2 different viewing angles for each eye, aspect being the key on a single image, applied to each eye. Surely the overhead would be less on pc, than two total outputs, one for each eye if that was adopted. Am i missing something here? To logical or easy?(in theory at least) Or the quality isnt even the same as end user experience with phone methodology? Is the phone VR method vastly inferior? Im not familiar with VR outside an arcade, therefore please forgive my novice line of questioning.

[@slammerf16]

@@outsidein3206The left scene/picture is rendered from a different position to the right Scene. This gives the separation between your eyes that delivers the 3D effect to your brain. It's a variation of the 3D effect that has been used in films for decades except in cinemas they had to use red/green filters or vertical/horizontal polarising filters in glasses to separate two images in the film so that each eye saw a different perspective. With a computer and HMD you can show one image per screen without filtering and you just put each image in front of the correct eye.

[@swilks8547]

I have 7 modules, and have recently stopped playing due to poor VR performance with my rig. I just can't justify the $$$ needed to buy the spaceship of a rig needed to play at a decent frame rate with a VR headset on. Unfortunately for me, once I donned the VR headset, I could never go back to TrackIR. I'm patiently waiting for ED to catch up on the optimization end of things. The content is great, and I absolutely love loading up and flying with random people online, but the constant issues in VR have just killed it for me as of late.

[@TheOpsCenterByMikeSolyom]

Hopefully, this improves things for you (when it eventually comes out).

[@psaunder1975]

Same here I am running dcs on notebook rtx2060 ryzen 4800h, rift s, and it's not great. I'm playing vtol vr instead.

[@goldmastersimulations]

Vulkan will be a blessing for those playing flight sims on Linux. Hoping to see it in BMS and IL-2 (not just the mod for GB). After DCS gets Render Graph and Vulkan, ED should port to Apple Silicon and Metal too. Could prop up a front to bring native VR gaming to Mac. The users of higher-end Macs are likely able to afford DCS modules too. And they could offload the AI processing to dedicated NPU cores to allow more bots in all scenarios at once for same or better performance.

[@duck_that_quacks]

The vast majority of Game AI are not neural networks and will not be able to be accelerated by NPUs, this is very likely the case for DCS as well. Reason being, it's incredibly resource intensive to train a real neural network to do even simple tasks, let alone far more complex actions like SEAD or BVR transitioning to BFM/ACM. This is why there are conditions inside the mission editor to tune the AI's behaviour. The next bottleneck in terms of performance will probably be game AI as it is single-threaded in nature

[@youtubeairways8646]

Forget Apple, embrace GNU/Linux

[@goldmastersimulations]

@@youtubeairways8646 X-Plane 12 is enough reason why Apple Silicon deserves flight sims. Laminar Research has way fewer employees than ED and manages to do it. ED just has to find the right talent to bring them. M1 Mac mini would be an amazing entry-level flight sim machine. It has good I/O and value for money. It’s certain the M1 Max and M1 Ultra can handle VR. The latter may not be 3090 level, but it’s still way above the VR baseline, RTX 3060 and 3070 mobile are able to handle DCS VR at low-medium settings. In Baldur’s Gate 3, which is a well optimized game, the M1 Max with 32 GPU cores delivers comparable performance to a full powered mobile 3070 with MUX switch in an Alienware laptop. So if DCS actually gets properly optimized, it’s gonna run amazing on VR on any platform. I am gonna dual boot Linux. Compatibility issues with flight simulators is the only thing holding me back.

[@youtubeairways8646]

@@goldmastersimulations I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project. There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run.The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.

[@valrond]

Why would you even play flight sims on Linux? I already have some troubles having all of my equipment working fine in Windows, and that's with official drivers and supported software. It's a lot, not just a hotas, and that's it, no, that's trackir, vr headsets, saitek flight controls (a lot of them), thrustmaster mfds, the streamdeck, and other things I don't remember now.

[@Steve-ou9ed]

Thaks brilliant

[@rhysgoodman7628]

This would help with optimization widely, but it would also allow high-intensity maps, such as the Marianas and Syria, run better. It would also open the door for a Vietnam map with all the trees! Can’t wait for the day it arrives!

[@dcs-web-editor]

There was a vietnam mod for caucasus, check "green thunder". Trees were not an issue, even back in 2015. Desctructible trees are still an issue.

[@rhysgoodman7628]

@@dcs-web-editor well with much more modern map graphics, as in the Marianas and Syria, I reckon more detailed trees would be quite a hit. I hope I’m wrong, I’d love a Vietnam map. It would be a great change from sand, sand, sand!

[@rkwatchauralnautsjediparty7303]

One can hope.

[@imdrako0411]

I think that Vulkan vs openGL is a gain for AMD, what happened for xplane, for me, on xplane, with my Intel and Nvidia config, I don't notice much better. except losing the rain effects on the windows in vulkan. On read dead, low I played in directX12, because after a try in Vulkan, low nothing. So I don't know what to think about it except to tell the developers to switch to DX12.... Well it's dead for XP 12.

[@joshfps8546]

Great, now im hungry

[@KarsonNow]

You haven't mentioned that Vulkan was pushed by AMD. The same case is with AMD open source mindset for their software and drivers. 🤷‍♂️

[@SkateZillaSimulations]

Vulkan was sourced from Mantle, which while developed by AMD, was open source from the start.

[@KarsonNow]

@@SkateZillaSimulations that is what I meant.

[@astrixau8928]

Yes, I too noticed this. I used to use AMD GPU’s so I know all about it. And their OpenGPU strategy. It was actually co developed by AMD with the help of DICE, hence DICE had the first Mantle game BF4. If I remember correctly the Dice Dev co founded a studio his name is Johan Andersson. The studio is Embark Studios.

[@steeltribe3967]

Thanks.