from the getting-the-fat-out? dept.
Doom 3: BFG Edition, the remastered version of Doom 3 (id Tech 4) which had its source code released in November 2012, has gained a Vulkan renderer (Vulkan is a graphics API successor to OpenGL that can better utilize multiple cores and GPUs):
Dustin Land of id Software has been working on the "vkNeo" project in his spare/personal time as a Vulkan renderer for Doom 3 BFG / idTech4, which was open-sourced a few years back. This is along the same lines as the vkQuake open-source port of the original Quake to running on Vulkan.
Doom 3 can easily run on nearly any modern PC these days with its classic OpenGL renderer, but now with Vulkan the game can run at 500+ frames per second in simple areas or 150~300 FPS in the more demanding areas of this first person shooter.
The Doom 3 Vulkan code was open-sourced over night via vkDOOM3 on GitHub for those interested. Land commented, "It was written as an example of how to use Vulkan for writing something more sizable than simple recipes. It covers topics such as General Setup, Proper Memory & Resource Allocation, Synchronization, Pipelines, etc."
This new build of Doom 3 is Windows-only for now but the code will be added to RBDOOM-3-BFG soon which does support Linux.
Since the release of Vulkan 1.0 in February 2016, the successor to OpenGL slowly but surely made its way into applications and game engines. Today, roughly two years later, the Khronos Group is releasing Vulkan 1.1 and SPIR-V 1.3 specifications, and much like Vulkan 1.0's 'hard' API launch these are accompanied by updated developer tools, open source conformance tests, and launch driver support from GPU vendors. [...] In sum, the evolution of Vulkan from 1.0 to 1.1 is three-pronged: integration of developer-requested functionalities, driver support and seamless porting of Vulkan to more platforms, and then practical implementation by way of a developed ecosystem.
Moving straight into the core changes, Vulkan 1.1 brings two new wide-ranging functionalities: protected content and subgroup operations. The former utilizes low-level restrictions such that applications can render and display using resources they cannot access or copy, in turn securing playback and display of protected content. While ostensibly for DRM purposes, Khronos noted that Vulkan was exposing GPU capability rather than pushing for hardware-level DRM, leaving usage or implementation up to the developers.
So on the one hand, developers may choose to create a highly-restrictive multi-layered DRM scheme with a high degree of granularity. On the other hand, perhaps the feature could be used for an advanced low-level adblocker, not only for browsers but one that could hook onto ad-serving mobile and desktop games and applications. All might be possible with Vulkan 1.1 and beyond. To that end, Vulkan is in many ways simply looking to enable what is possible – in the purest sense of the idea – on GPUs.
That idea carries over with the new 'subgroup operations', where a set of threads can communicate and coordinate amongst themselves where normally this would be done by accessing off-chip memory. Ultimately, this offers developers a method of parallelizing certain workloads to a very high degree, and while compute and deep learning are the more obvious use cases, subgroup operations are not limited to only compute shaders and could presumably be used for graphical purposes. Naturally, the new SPIR-V 1.3 likewise supports subgroup operations.
SPIR: "Standard Portable Intermediate Representation"