Slashdot Mirror
NVIDIA Shows New Doom Demo On GeForce GTX 1080 (hothardware.com)
MojoKid shares a video showing the upcoming Doom game on NVIDIA's new GeForce GTX 1080 graphics card using the Vulkan API, quoting this report from HotHardware:
At a private briefing with NVIDIA, representatives from id software came out on stage to show off the upcoming game...the first public demonstration of the game using both NVIDIA's new flagship and the next-gen API, which is a low-overhead, cross-platform graphics and compute API akin to DirectX 12 and AMD's Mantle. In the initial part of the demo, the game is running smoothly, but its frame rate is capped at 60 frames per second. A few minutes in, however, at about the :53 second mark...the rep from id says, "We're going to uncap the framerate and see what Vulkan and Pascal can do".
With the framerate cap removed, the framerate jumps into triple digit territory and bounces between 120 and 170 frames per second, give or take. Note that the game was running on a projector at a resolution of 1080p with all in-game image quality options set to their maximum values. The game is very reminiscent of previous Doom titles and the action is non-stop.
With the framerate cap removed, the framerate jumps into triple digit territory and bounces between 120 and 170 frames per second, give or take. Note that the game was running on a projector at a resolution of 1080p with all in-game image quality options set to their maximum values. The game is very reminiscent of previous Doom titles and the action is non-stop.
Because Pascal is a lot safer than, say C++, because the compiler won't let you shoot yourself in the foot, rather than you ending up bleeding to death because the EMTs can't find you in a heap of 8192 bitwise copies all pointing at each other saying, "That's me, over there."
one of the big blockers for gaming via WINE has always been DirectX, specifically translating DirectX Graphics to OpenGL. Now with the Vulkan API, we'll be able to implement the various DirectX API versions and OpenGL versions in a completely portable way as function calls to RISC-V GPU code. The only thing left is for someone to make open source firmware that implements the Vulkan API and we'll finally have a truly open source video card.
as for non-gaming, looking over how our desktops are rendered, we should implement a minimalistic window rendering API using the Vulkan API that UI libraries can build upon. this reduces the number of layers involved in rendering and can solve the accelerated vs software only problem via the LLVM implementation that runs RISC-V code. at the same time, the desktop API allowing you to choose a target GPU could forward calls from the remote system to your local system so that the forwarded windows are actually rendered locally which would vastly reduce the bandwidth as well as enable the total integration of multiple desktops.
Vulkan is the rendering API that Linux has needed all along.
Anons need not reply. Questions end with a question mark.
in the sense that it has DOOM in the title, maybe.
Correct. Vulkan drivers are easier because they do less and contain fewer optimizations. The optimizations are pushed to the application developer to do. This is both a blessing an a curse:
the blessing is that application developers can gain better performance in some cases, as there is less hardware abstraction and they can gain more control over execution of graphics operations.
the curse is that the driver has fewer optimizations built in, and future drivers can't contain optimizations for games.
This approach is helpful where call overhead is significant, and on less-powerful devices such as mobile devices. On much more powerful desktop GPUs the real-world improvements of such an approach is less clear. In actual implementations with AMD Mantle and Apple's Metal on desktop-class GPUs there are mixed performance gains (sometimes faster than OpenGL, but also sometimes slower). Given the fact that the simplicity of the Vulkan driver pushes complexity to the application (more control, but more unavoidable work for application developers too) then this simpler-driver approach is actually less useful for most of the developers actually writing the applications. Think of the difference between OpenGL and Vulkan as the difference between using a Linux distro and creating a distro out of parts you choose. You can get better performance if you choose all the parts of your custom distro, but it takes a non-negligible amount of effort and is really only beneficial on low-end hardware where every cycle counts, rather than on high-end hardware where you can have cycles to burn in some areas so time-to-market matters much, much more.
Vulkan has its good points - but as a desktop OpenGL developer, it is actually a step backward for the kinds of problems I want to solve (a desktop jet-combat flight simulator to be run on mid- to-high end desktop/workstation class GPUs).
It is HotHardware's own video, embedded in HotHardware's article, posted to Slashdot by HotHardware's editor-in-chief (MojoKid). So it has nothing to do with nvidia and everything to do with HotHardware.