Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Graphics Intel Open Source Games

Valve Bootstrapped Source 2 Engine On an Open-Source Vulkan Driver 60

An anonymous reader writes A new article out details how Valve bootstrapped their VULKAN back-end with the Source 2 Engine over a period of just four months thanks to relying on an open-source driver. With designing for the open-source Intel Vulkan Linux driver developed by LunarG, Valve developers were quickly able to resolve issues and progress the driver in a turn-key manner. This Intel Linux driver will be released as open-source once the Khronos VULKAN specification has been published.
This discussion has been archived. No new comments can be posted.

Valve Bootstrapped Source 2 Engine On an Open-Source Vulkan Driver

Comments Filter:
  • by Anonymous Coward

    Open source is neat, huh? Sure, would be nice if Source 2 were, you know, open source.

    • Open source is neat, huh? Sure, would be nice if Source 2 were, you know, open source.

      Sure, and it would be nice if it was Christmas every day.

      But...tadadadattataa! Tim Sweeney to the rescue! Unreal Engine 4 is fully open source if you really need an engine that you can modify all the way down to the hardware abstraction layers.

  • Bootstrapped (Score:3, Insightful)

    by Anonymous Coward on Saturday April 04, 2015 @03:40AM (#49403197)

    That word does not mean what you think it means.

    Valve developers were quickly able to resolve issues and progress the driver in a turn-key manner.

    Oh I see, we're playing bullshit bingo. In that case, as you were...

    • by Anonymous Coward

      Turn-key solution - it just goes out of the box, no effort required. Turn key, go.

      In this context it means bugger all. In fact it's a nonsense; I can't make a meaningful statement out of that no matter how I try to mangle the term.

  • "With designing for the open-source Intel Vulkan Linux driver developed by LunarG, Valve developers were quickly able to resolve issues and progress the driver in a turn-key manner." . . Leaving aside the broken English "With designing for" vs "Using"... "progress the driver in a turnkey manner" sounds (quite lilterally) like a buzzword generator. . . Looks more like an April-1 post to me.
  • Why is the Vukan-based driver have a spec named for the Klingon homeworld?

  • 600 lines to write a program that renders a triangle? Such apis are obsolete in 21th century period. Don't care what cowboy coders do on their game consoles. There's no need for line of code count maximization techniques in opensource.
    • by abies ( 607076 )

      It doesn't meant that code to render million triangles will have 600 million lines. It is just a constant overhead to deal with various device trickery (multiple GPUs, multiple monitors, full screen versus window, etc etc). There will be 3rd party libraries immediately which will allow you to do 'render things on default screen, with default resolution, on default graphic card, not using SLI, using default malloc for memory allocation' with single function call, reducing line count drastically (but still pr

      • Vulkan is API for game engine programmers, not for game developers. It is a lot closer to kernel API than to libc API if you want to compare with normal programming.

        In this analogy that compares libc to a game engine, what's the counterpart to GNU C Library (glibc), a free implementation of libc?

        • by abies ( 607076 )

          Nothing yet, because Vulkan is not yet public, so no 'free' implementations exist. But I'm quite sure that as soon as it appears, projects like Ogre3D or openscenegraph will provide their bindings over Vulkan.

          This analogy is flawed in some respect - because glibc is a drop in replacement for libc. There is no such agreement on higher level API in this case, but rather competing APIs/engines.

    • How often do you render a single triangle? The goal of APIs like VULKAN is to provide complete control over every stage in the rendering pipeline (and a stable IR to make it easy to run code written in a custom DSL on the GPU). If you're just displaying a single triangle then this is not the API for you. It is intended to sit below APIs that provide scene graphs and so on for simple use.
      • Then it's not replacement for opengl and shouldn't be considered one, but an api one level below. And I don't really think it's such a good idea. Like switching from C back to assembly.
        • You may not think it's a good idea, but every single game engine developer on the planet thinks it's a great idea ;).

          • Well, you're getting too excited about something that is evolutionary step backward and such hasty statements are a proof of this. I myself have some opengl experience and I can tell you getting to lower level is NOT what I would want. Yet I don't want to be locked into using an engine either with their often suspect design decisions. I consider opengl to be in sweet spot in this regard, though shaders are kinda pushing it.
            • Well, you're getting too excited about something that is evolutionary step backward and such hasty statements are a proof of this. I myself have some opengl experience and I can tell you getting to lower level is NOT what I would want. Yet I don't want to be locked into using an engine either with their often suspect design decisions. I consider opengl to be in sweet spot in this regard, though shaders are kinda pushing it.

              So what you're saying is basically "I want I high level API for drawing graphics reasonably fast". That's fine, you should go grab an engine. There are plenty of very high quality ones out there, many of which are free (at least until you start making money). There are also plenty of mid-level ones that will not cause you to have significant lock in.

              However, the person writing said engine for a AAA game, or an app that involves 3D rendering and that has to conserve battery life as much as possible while

        • by Bengie ( 1121981 )
          More like going from JavaScript to C. We need the performance. For certain parts of the rendering, Mantle tech demos were showing upwards of a 10x increase in performance. Some of the stuff I was reading was saying that while OpenGL and Direct3D made getting a minimum viable product out the door, Mantle was dramatically faster for getting a game that got more than 10fps. Once you hit the stage of game development where you need to optimize the code to make the game playable, Mantle was much faster for codin
    • No, they're not at all obsolete in the 21st Century.

      When it comes to graphics programming, at the very low level (i.e. people who are writing the engines, not people who are using the engines), everything is about performance. These people (myself included) absolutely will jump through the hoops of writing 600 lines of setup code if it means I don't end up with half a CPU used up just recompiling shaders and verifying state changes all the time.

      Ultimately, this code is written once, by the rendering engine

  • working on half life 3? bastards.

Marvelous! The super-user's going to boot me! What a finely tuned response to the situation!

Working...