DirectX 12 & Vulkan as Fast As Possible

Показать описание

Should we expect to see the amazing performance gains we have seen rumored about DirectX 12 and Vulkan in practice?

Рекомендации по теме

Комментарии

Just a few answers to questions:
Q. Will DirectX12 and Vulkan improve the performance of my games?
A. No, not unless the devs release a new version of the game with a new rendering back-end that actually takes advantage of the more explicit interface.
Q. Will new games with DX12/Vulkan rendering back-ends run faster?
A. Impossible to tell. They could be anywhere from slower to faster, depending on how the devs use the APIs; just because there is an increase in performance potential doesn't mean it will be taken advantage of.
A(Continued). Also, games will still be capping out at 60(updates per second) FPS for a while. That huge FPS # just means that (that # - game updates per second) frames are being spent rendering objects where they WOULD be assuming that their current velocity/anything else that has an effect on their movement stays constant. These APIs are only giving a boost to how fast we can render objects; any extra CPU time gained in one update/render cycle will likely just be spent on adding more features to the game logic, physics, etc because
1) The extra time won't be significant enough to be able to afford to up the refresh rate to say 120 FPS and
2) Even if it were that significant, there is more demand for computationally expensive game-mechanics than there is for higher FPS.
Q. Which is better?
A. While they offer similarly explicit access to the GPU and, thus, similar potential performance gain, the answer is Vulkan, Vulkan, Vulkan... Why should this answer be so obvious? You have equal performance gain potential with both, yet Vulkan is an open-source C API. This means that Vulkan implementations can be provided and used on ANY platform (including Windows!) and will be friendly for compiling against/calling into with multiple compilers. The only use for DX12 is for XBOX/other non-desktop Windows platform development. Couldn't they just support Vulkan in the future as well? Of course they could, but they are Microsoft, one of the greediest, most corrupt tech companies in existence; I wouldn't put it past them to go out of their way to thwart a Vulkan app's performance on Windows, creating yet another artificial dependence on Windows products that isn't based on features and coming out on top of fair competition.
Comments:
1. Hopefully, if you are not a programmer, you will start to see how Microsoft is hurting the gaming community, not helping it.
2. If you are planning on learning programming in the future, please do us all a favor and use open-source/free APIs/data formats and tools. In case Microsoft has successfully indoctrinated you into thinking that you can't build games on Windows with cross-platform stuff, here are my recommendations for different components:
Graphics: OpenGL/Vulkan. Vulkan isn't a replacement for OpenGL for ALL purposes. If you are writing a game on par with the games you currently play on Desktop, you will be fine with OpenGL, and your development time would probably be reduced significantly.
Audio: OpenAL. It has a similar API to OpenGL, and can do everything you need for a 3D game.
3D data exchange file format: COLLADA.
Audio file format: OGG Vorbis.
OS Window/Events/Keyboard abstraction layer: SDL2.
Any platform specific code that you need for performance or capability will be greatly reduced and more easily managed if you start from these.
Nit Pick: these APIs (Vulkan and the proprietary interface that DirectX12(just a framework) uses) are not offered by OSes, they are offered by device drivers or wrappers that use a different DDI.

EDIT 6/2020:
The graphics landscape has changed since I made this comment. Vulkan had a lot of potential, but now that Apple has dropped OpenGL/Vulkan in favor of Metal, the answer for which API is best to use on Windows/XBOX is D3D11/12. For Mac/IOS, it's Metal, for Linux, it's OpenGL/Vulkan, and for PlayStation it's their proprietary API. It's sad, but we're at the point where the standardization effort has failed, and it's best to go as native as possible on each platform.

rationalcoder

My Benchmark:
DX11: 143fps
DX12: 998fps

SimonNitzsche

If I'm being completely honest, I only watch FAP for the seamless transitions into the sponsor.

boywhogames

Vulcan is on Linux as well, making it the far superior choice to me.

TemplePate

DirectX 12 will be great!
...where it's applicable to BE great, that is...

pigolus

The biggest benefit from DX12 will be in VR. Depth faking shaders simply look like wallpaper in virtual reality, you need real geometry; which DX12 claims to bring in the truck load with its much higher draw calls. Add in the lower latency asynchronous shaders and other utilisation of multi-threading and maybe you won't need a beast to run VR after all.

AnnoyedDragon

IDK about anyone else, but I'd be interested in seeing an API As Fast As Possible video. Not just going over differences between APIs and giving a rough description of APIs that we've all heard once or twice, but helping us understand the difference between DX11.2 (that's current on Xbone), the PS4's API, and understanding what makes it difficult/easy to develop games using those APIs.

VGDocs

Might be a good idea to do an APIs as fast as possible...?

luketimothy

I'm just hoping DX12 will bridge some of the difference in gaming performance between an AMD 8-core and an Intel i5.

RongGuy

Combining nVidia and AMD GPUs .... WHAT DIMENSION IS THIS?!?!!

BuGBurnout

Hey Linus I'd love to see a video on gaming for linux.

iridiumflare

The hot AMD girl shows how hot the GPU gets.

Jathax

Will the 690 be able to use all of it's vram with directx12?

Haneix

Can we take a moment to acknowledge how satisfying is the way "Application Programming Interface" aligns with Linus' silhouette? OCD Nation Unite!

descoiatorul

We'll see what Vulcan really gets us, but I just made some of my code use multi-threaded OpenGL command issuing.
Yes, you can already do this with OpenGL.
Yes, you need a separate GLX context per thread, but you can *share* textures etc. between contexts, so you can prepare data and issue GL commands from separate threads.
So, that idea is not new.
Of course, there are other performance benefits to Vulcan.
And, it's a *cross-platform standard*.
So, suck it Microsoft!

gnagyusa