Slash Boxes

SoylentNews is people

posted by martyb on Saturday August 12 2017, @08:38AM   Printer-friendly
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.

Previous story.

Original Submission

Related Stories

Vulkan 1.1 Specification Released 13 comments

Vulkan 1.1 Specification Released: Open-source Tools, SDKs, and Launch Driver Support

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.

Khronos Group press release and Vulkan Resource Page.

SPIR: "Standard Portable Intermediate Representation"

Previously: Khronos Group Releases Vulkan 1.0 Graphics Specification

Related: Open Source Doom 3 BFG Gets a Vulkan Renderer
AMD Finally Pushing Out Open-Source Vulkan Driver

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by redneckmother on Saturday August 12 2017, @05:14PM (4 children)

    by redneckmother (3597) on Saturday August 12 2017, @05:14PM (#552903)

    I'm not a gamer, but it seems to me the most popular excuse (among young folk) for using MSWin is "games".

    It would be interesting if a major game development company released Linux versions first, then "backported" to Windows.

    Pitchforks? Check. Torches? Check. Lampposts? Check. Rope? Oh crap, Colorado smoked all the Hemp!
    • (Score: 2) by takyon on Saturday August 12 2017, @05:31PM (2 children)

      by takyon (881) Subscriber Badge <{takyon} {at} {}> on Saturday August 12 2017, @05:31PM (#552906) Journal

      I think it's a lot easier to make cross-platform games than it was 10 years ago. If your company uses Linux internally for development, you might just do that.

      Worst case scenario, offer a less stable Linux version.

      [SIG] 10/28/2017: Soylent Upgrade v14 []
      • (Score: 0) by Anonymous Coward on Sunday August 13 2017, @03:07AM (1 child)

        by Anonymous Coward on Sunday August 13 2017, @03:07AM (#553077)

        Nothing. Ever.

        It's all a matter of abstraction.

        It's just that game programmers aren't interested in cross-platform compatibility; rather, they're interested in MONEY! Their software isn't beautiful; it's functional for making money.

        • (Score: 3, Interesting) by jmorris on Sunday August 13 2017, @04:27AM

          by jmorris (4844) Subscriber Badge <> on Sunday August 13 2017, @04:27AM (#553113)

          Don't be a tard, K? Game studios, unless they are Id software or something, are not all that great at programming. They license an engine and shovel content into it until it is deemed shippable, then a point release or two to fix the worst day zero bugs, a few expansion packs and then onto the next game. A game studio these days has a lot of artists, modelers, level creators, writers, and all those creative types but not a lot of Mt. Dew swilling code jockeys anymore. What programming they do is more likely to be Python or Lua to drive the internals of the game engine. If they license an engine that is cross platform they MIGHT give enough of a crap to bother getting a Mac and Linux box and building those versions and they might not. If the engine they license (the key devs having prior experience with it being the primary reason to pick one over another) is Windows only or Windows and XBox only, that is what they use and they DO NOT CARE. They are in the entertainment business, not tech.

          Do I like that? I don't own a Windows PC so you figure it out. Thankfully Steam is starting to make some inroads in that thinking.

    • (Score: 2) by ledow on Sunday August 13 2017, @04:50PM

      by ledow (5567) on Sunday August 13 2017, @04:50PM (#553302) Homepage

      That may be true at home. But it doesn't really matter what you use at home. Most people still buy Office "because I need it" rather than them actually needing it. But they have an Android tablet, an iPad, an iMac, etc. as well as several games consoles, too, so it's not that ONLY Windows will do in the environment.

      Windows survives because of business apps, and ease of management (you may snigger now, but it's true). Setting up a network is literally "Boot Server, run a couple of wizards, add users, now starting joining shop-bought PC's to the domain". Everything from Hyper-V to DFS to AD to DHCP failover to WSUS to Group Policy is all there ready to go. Even Exchange, the bane of most of our lives, is very simple to get up and get running and do some quite complicated stuff on it.

      Now the business apps, they are going the way of the dodo and everything is going "web". That's a good step. But still that web step often involves Windows Server, SQL Server and IIS. We have to ask ourselves why that is. It's nothing to do with technical ability of the OS or the application. It's to do with setup, management and availability of that knowledge in the workplace.

      I once set up an entire school, on fresh hardware, from scratch, 150+ machines, single-handedly unboxing them and configuring them, in the space of a summer holiday with PLENTY of time to spare. It wasn't difficult. However I then spent a week getting 50 netbooks on Ubuntu booted, configured, using Likewise Open (called something else now) to access files and authenticate against the network. I'm sure if I paid a fortune for Red Hat something-or-other, I could make it simpler, but it still wouldn't be as simple as it was on Windows. I've done the same with MacOS (which I hate) - all the golden-triangle authentication junk just to get it to join a network, let users log in and access their files. Is it because MS make it obtuse? It doesn't appear so. We just don't have the kind of integration necessary. MacOS eventually got it (was it Sierra? From then on, you just forget all that old junk and join the machine to the AD LDAP and off you go). Linux hasn't.

      Windows discovers devices on the network and sets them up. Joins domains and sucks down their settings, software, etc. Linux doesn't. I can provide a billion good reasons WHY it doesn't, but it doesn't.

      So the Linux machines I see deployed are nothing to do with games or not (RetroPie is fabulous if you haven't tried it, SteamBox has 1/3rd of my 1200 games on it, etc.), they are the black boxes that just work. Unfortunately, there's no black-box desktop that just works. Deploy Ubuntu on a Windows network, it honestly couldn't care less and doesn't help you join anything at all. There are good reasons, yes, but to a user or even an admin who's been tasked with managing it as part of their job, they want simplicity and hand-holding. "Hey, we detected this domain... do you want this computer to join in so users can login to this machine?". There's nothing like that on Linux.

      As such, I can create a virtualised, failover, resilient network from a handful of server GUI installs, with hundreds of services capable of servicing hundreds of users and doing things like resilient DB backends to a public mail server in a matter of minutes on Windows. You can't on Linux. You can do it all. You just can't without knowing the whole process inside out. I literally learned how to do VM failover, file system distribution, mailserver database mirroring, etc. "on-the-job" with Windows. Never done it before. Read up a bit about it. Clicked the buttons. Voila.

      On the other hand, it took me hours to set up a proper DRBD setup for one test loopback file system across two servers, after I'd spent days updating them to the same versions on two different distros.

      Linux has billions of advantages, and it does great things. But it's still not user-friendly. Go set up a VM in Ubuntu to boot Ubuntu. From a fresh install. No knowledge. Off you go. Now do the same in Windows Server using HyperV to boot Ubuntu (which should be a lot harder!) or Windows. Or even - nowadays - a Server VM virtualised in a Server VM virtualised on a physical hypervisor. Or things like remote desktop services with VM's that auto-create from template and destroy themselves on disconnection.

      Windows, believe it or not, wins because its easier. If you look at Windows processes and laugh "How is that easy?", just imagine what someone booting up Ubuntu or similar for the first time feels when they just want to put the close button on the right of the window, or get rid of the side-bar. I'm not saying Windows is any better, but there's a reason it wins in commercial space, and people take that home and it means it wins at home too.

      Unless it's in a device so simple to operate that they don't even know its Linux (e.g. a satnav, a games console, a Kodi box etc.)