Comments Locked

43 Comments

Back to Article

  • jann5s - Wednesday, February 17, 2016 - link

    The important thing is that the API is here, and that we already have some SDKs, profiling tools and even a game demo. The performance question will need much more analysis and maturation time before it is really understood. Kudos to Khronos for getting this done.
  • nathanddrews - Wednesday, February 17, 2016 - link

    Yes, good for them for rushing this beta out the door, I guess. It's better than nothing, but not being better than DX11 is a mistake I think. If the beta needed more time to make an impressive splash and everyone involved knew this, then they should have waited.

    As far as the marketing push goes, so far we've seen DX12 demos/betas surpass DX11 counterparts, but then Vulkan comes out and does horribly against DX11. First impressions are the most something... something...
  • Flunk - Wednesday, February 17, 2016 - link

    The SDK needs to be out there for anyone to develop for it, the argument that the first release of an SDK is buggy or a demo that exists just to prove that something works is rather silly. Production code using Vulkan won't be around for a year or so.
  • CajunArson - Wednesday, February 17, 2016 - link

    If you had been around when DX11 launched then you would have seen another poster exactly like you insulting DX11 as a failure because mature DX9 titles performed better.

    This is nothing new and frankly having a new high-end game operational under Vulkan on launch day is actually massively better than what we've seen with previous API launches.
  • bug77 - Wednesday, February 17, 2016 - link

    You do understand this is just the OpenGL engine wrapped into a Vulkan adapter at this point, don't you? Why would you even compare such a contraption to DX11?
    For the time being, Talos Principle just a testbed for Vulkan rendering, noting more.
  • nathanddrews - Wednesday, February 17, 2016 - link

    "Why would you even compare such a contraption to DX11?"

    Did you forget what the article above is about? LOL
  • extide - Wednesday, February 17, 2016 - link

    Again, you're confused. This is just a "Look it works" demo, NOT a performance demo!
  • nathanddrews - Wednesday, February 17, 2016 - link

    Not confused at all. It is both an article about its operational state and its performance. Throw whatever caveats you want at it, the point is that performance at present is severely lacking. Personally, I find that very disappointing. I also understand that with time and effort, it will perform better, but that doesn't change the fact that its performance right now is weak. Pack up your pitchforks and save them for someone else.
  • extide - Wednesday, February 17, 2016 - link

    Yeah but the performance is slow because of the GAME, NOT the API!
  • MamiyaOtaru - Wednesday, February 17, 2016 - link

    the performance of *that game* is weak. That game, developed by someone who is not Khronos. Which is in early development anyway. People would put down the pitchforks if you'd stop being such a lumbering Frankenstein's monster of a terrible poster
  • nathanddrews - Thursday, February 18, 2016 - link

    Last I checked, Khronos will not be developing any games. If I had any other metrics from which to judge Vulkan, I would. At each step along the way of Mantle (pre-Vulkan) and DX12 (ongoing), we were treated to demonstrations, real world games, and beta benchmarks that showed us dramatic performance improvements over DX11 (which, in turn, pushed game/driver devs to make DX11 implementations better). This implementation of Vulkan - being the first out the gate - is not great PR for Vulkan when viewed against previous API releases. This wasn't just some random developer pushing out a random build either, this was planned release by a major studio hyped across the blogosphere by AMD, NVIDIA, and Khronos. I go back to my original post, that if everyone knew it was going to perform poorly, they should have waited for a few more nightly builds before unveiling it.

    Look, I just want Vulkan to be awesome - more awesomer than DX12. Microsoft just announced that Quantum Break will be DX12/Win10 Store exclusive and rumors suggest that Forza, Gears of War, etc. will also be going that way. We need a powerful cross-platform API so that Windows XP-10 gamers, Linux gamers, etc. can all play together. DX12 is great, but locked to W10 is terrible for everyone. Croteam has shaken my confidence in Vulkan. If you don't feel that way, then you're more optimistic than me.
  • BurntMyBacon - Thursday, February 18, 2016 - link

    @nathanddrews: "If I had any other metrics from which to judge Vulkan, I would."

    An excellent point. That's why I'm reserving judgment for now. Interestingly, I had the opposite problem with DX12. The earliest benchmarks were extremely targeted and though they performed well, they were not representative of real world performance. So, I still had to reserve judgment.

    @nathanddrews: "At each step along the way of Mantle (pre-Vulkan) and DX12 (ongoing), we were treated to demonstrations, real world games, and beta benchmarks ..."

    Mantle and DX12 demonstrations and the likes were funded (at least in part) by AMD and Microsoft respectively. I'm not sure what kind of funding Khronos has to work with. Of course that is also something to consider before putting all our hopes in groups like Khronos.

    @nathanaddrews: "This implementation of Vulkan - being the first out the gate - is not great PR for Vulkan when viewed against previous API releases."

    Can't argue with that. If they wanted better PR, they definitely should have put a little more work into it.

    @nathanaddrews: "This wasn't just some random developer pushing out a random build either, this was planned release by a major studio hyped across the blogosphere by AMD, NVIDIA, and Khronos."

    Croteam isn't an indie studio to be sure, but they aren't really in the same league as Valve, EA, and Ubisoft either. IIRC they only produce the Serious Sam games and Talos Principle. I'd consider them a smaller studio more in line with developers like GSC Gameworld than Ubisoft. That said, the hype really should have waited until they saw some preliminary results. It is not encouraging that this is the demo Khronos chooses to hype. Though, I suppose they may not have expected it to be released in this state. Lack of options is also probable, though neither of these options are confidence inspiring either.

    @nathanaddrews: "Croteam has shaken my confidence in Vulkan. If you don't feel that way, then you're more optimistic than me."

    With DX12, I had to contain my optimism lest I be disappointed. In hindsight, that was a good approach to take. I'd suggest the opposite here. I'd contain my disappointment as there is some evidence to suggest it may not be warranted.
  • RobATiOyP - Sunday, February 21, 2016 - link

    Also, Vulkan SDK is multi-platform, with many vendors and architectures. They need to get the API out early, have drivers implement it, find the specification mistakes early before there's a large software base; for me given there were obvious driver issues it is quite encouraging that Vulkan showed a small improvement on OpenGL.

    Unlike the Star Swarm demo, which was an example of an engine which had been bottle necked by OpenGL & DX11 APIs, this "Puzzle em Up" isn't throwing draw calls at a maximum rate at the API.

    This is very much a notice to software developers that Vulkan is real, not vapour.
  • BurntMyBacon - Thursday, February 18, 2016 - link

    @nathanddrews: "... the point is that performance at present is severely lacking. Personally, I find that very disappointing."

    Just to be clear, what do you find disappointing? Croteam/Talos Principle or Khronos/Vulkan.

    I can understand the first as one could argue that they should have held the Vulkan release until it at least outperformed its OpenGL counterpart universally. Sure it is a beta and should be viewed as such, but there is something to be said for first impressions. ; ' )

    The second I don't agree with (at least not yet). Putting aside API comparisons, there are plenty of examples of games with the same API that perform wildly differently. The Half-Life series, for instance, generally has excellent performance for the visual quality it brings to the table. Doom 3 was often compared to HL2 and while it was technically superior and the engine had the potential for far superior graphics (full dynamic lighting, etc.) it was held back to what was considered comparable graphics by the lack of performance. For more modern DX11 examples, you can look to Batman: Arkham Knight and Assassin's Creed Unity. For their performance, they should be leagues ahead of Crysis 3 in image quality and that isn't even considered a well optimized title. If you don't like these examples, there are many others to choose from. The point is, you can't judge an API based on one game (particularly from a smaller developer) that may not be well optimized (explicitly stated here).
  • RobATiOyP - Sunday, February 21, 2016 - link

    This is dead wrong, "they should have held the Vulkan release until it at least outperformed its OpenGL counterpart universally." this is NOT production optomised code, this is early implementations of a new API, which needs developers to use it, use it NOW, not wait.
    Large applications relying on Vulkan, have to wait for API & driver maturity, there's risks & costs in early adoption.
  • Manch - Thursday, February 18, 2016 - link

    Did you? 2nd paragraph after the graphs "The real reason we set about to run these tests was not to compare early Vulkan to DX11, but rather to compare Vulkan to the API it succeed, OpenGL."
  • extide - Wednesday, February 17, 2016 - link

    I think you are confused here.

    Vulkan is release 1.0 NOT a beta.
    The Drivers for AMD and nVidia are both in beta state right now.

    The only reason it's slower than DX11 is because this specific game's engine is not as fast when running in vulkan, not because of vulkan itself. It's a brand new API, the developers need time to learn it to tune it for speed. Plus this was not an implementation even designed for speed at all, it is more of a proof of concept simply to show it works. That's all.
  • RobATiOyP - Sunday, February 21, 2016 - link

    Is this game even something that is bottlenecked by OpenGL/DX11 API? It looks like typical game graphics, not the crazy busy Star Storm demo, with an engine able to send 60,000 draw calls a second at the hardware. if the DX11 version is "highly tuned", would they see any benchmark improvement in DX12?
  • Zingam - Wednesday, February 17, 2016 - link

    I bet Vulkan will become relevant in 5 years when most people would have bought modern graphics cards.
  • bcronce - Wednesday, February 17, 2016 - link

    AMD released GCN 1.0 5 years ago, and they support Vulkan back to 1.0.
  • ddriver - Wednesday, February 17, 2016 - link

    This is comparing apples to oranges. The engine is not optimized properly for OpenGL.
  • Duckeenie - Wednesday, February 17, 2016 - link

    Sorry I have no time for that like farming nonsense. Consider this, Wine+DirectX likely runs that game faster than Vulkan at this point. So much for close to the metal; we're going to change the world and stick it to the man.
  • Zak - Wednesday, February 17, 2016 - link

    Early DX12 tests were also underwhelming. So much for "close to the metal" revolution IMHO.
  • bcronce - Wednesday, February 17, 2016 - link

    Which tests? I saw some that were nearly 10x faster with DX12 unoptimized than DX11 optimized, from a group that had a strong background in optimizing DX11.
  • fallaha56 - Wednesday, February 17, 2016 - link

    really? dear god it looks awful!
  • Stuka87 - Wednesday, February 17, 2016 - link

    "We’ve also gone ahead and run our two most powerful cards, the GeForce GTX 980 Ti and Radeon R9 285, at 1440p to also showcase a more strictly GPU-bound scenario."

    I understand the point of running a 285 to test it. But to say its the most powerful card you guys have is stretching it a bit?
  • Ian Cutress - Wednesday, February 17, 2016 - link

    I believe that due to time, Daniel ran the tests here, and only has the cards Ryan has sent him, which I think are some of the extra non-reference cards (that were adjusted to reference card clock speeds for this test). Contrary to popular belief, we're not in one single office - editors are dotted all over NA and EU, which makes shipping stuff around very expensive or very slow.

    Vulkan drivers and rendering paths are still in their early days/betas, hence why we're seeing it perform behind DX11, so there's no need to stretch the gamut with a dozen or two dozen cards here.
  • Kontis - Wednesday, February 17, 2016 - link

    Vulkan could be used to easily outperform Dx11 (e.g. using draw calls bottlenecking) with a driver in an alpha stage.

    The wrapper used in Talos will most likely not outperform DX11 even in 5 years with mature driver.

    tl;dr it's not a driver problem, it's a game engine problem (quick port made by one guy in 3 months for a completely new API).
  • extide - Wednesday, February 17, 2016 - link

    That was just the fastest AMD card the writer had available to him at the time.
  • TristanSDX - Wednesday, February 17, 2016 - link

    Vulkan is mistake, it won't be faster. This slowness is not caused by driver, but by game. Driver is thin and easy to write. Driver in DX11 is highly optimized, and use lot of complex code to perform convoluted tricks to make rendering as fast as possible. With low level access to hardware, all of this complex code must be moved to game or engine. This is enormous task, as this code are millions of lines, and only biggest teams will be able to do this.
  • Flunk - Wednesday, February 17, 2016 - link

    You're right about only the largest developers having the resources to implement DX12 or Vulkan, but a lot of smaller companies are using 3rd party engines like Unreal or Unity so if they support DX12 or Vulkan it significantly lowers the bar of entry.
  • Murloc - Wednesday, February 17, 2016 - link

    I guess small teams will use game engines or DX11 then.

    Most of the business is captured by the big companies. They'll make proper use of this.
  • Nintendo Maniac 64 - Wednesday, February 17, 2016 - link

    RetroArch already has a Vulkan implementation, and it has a "team" of something like 5 people:
    http://www.libretro.com/index.php/day-1-vulkan-sup...
  • bcronce - Wednesday, February 17, 2016 - link

    All of those "tricks" are undefined and engine specific and can break at any moment. All current 3D graphics APIs are horribly slow unless 1) someone spends a lot of time optimizing and 2) the driver makers make undocumented "tricks" specific to a given engine or game

    It is currently impossible to make a high quality fast 3D games without being a AAA programming shop because AMD and Nvidia don't have the time of day to create these hacks to make your game work decently. Instead, small shops have to mimic existing AAA games and hope the drivers mistake them for the optimized game.

    This is exactly why you can see large performance increases for specific games with every new driver release. All of those "we made some game 25% faster!" isn't because the game engine got updated, it's because the drivers got a whole bunch of undocumented hacks and shortcuts added.
  • Senti - Thursday, February 18, 2016 - link

    ^ This. Developing as huge company with dedicated support from drivers and developing as small group are two absolutely different things.

    Do you know how small developers feel about all those "driver optimizations" that bring 25% speedup to some stupid overhyped game? The absolutely hate that driver developers instead of fixing their pile of bugs that cause your programs to just plain break instead spend all the time on one-time point hacks.

    Harder to develop for low level API? Harder compared to what, to extremely buggy high level API? It probably can't be any worse...
  • RobATiOyP - Sunday, February 21, 2016 - link

    Well said! Mozilla's Servo project developed a GPU render back end, which accelerated things, one key thing is to mimic what games do, to try and stay on relatively well tested code paths, currently GPU acceleration has defaulted to off in Firefox on most HW for this reason.
    Probably a mix n match toolkit to aid applications, construct HW dependant drivers, avoiding the middle layer mistake anti-pattern will evolve, putting small developers onto more comfortable ground using widely used code paths & techniques.
  • RobATiOyP - Sunday, February 21, 2016 - link

    With time, there'll be patterns and probably helper toolkits which lower the investment required to target Vulkan. There's already talk of re-implementing OpenGL with it's state tracking and so on, over the top of Vulkan.
    For now performance is the last concern, finding the necessary revisions in 1.0 version of Vulkan specification is the priority.
  • tipoo - Wednesday, February 17, 2016 - link

    I wonder if they're just using a wrapper to bridge HLSL shader programs to Vulkan. That would leave a lot of performance on the table without hand writing new ones. With the small team size and quick turnaround I think this is possible.

    Anyways, huge leap over OGL at any rate, and with polish should hopefully be competitive with DX.
  • przemo_li - Wednesday, February 17, 2016 - link

    It possible.

    However more likely is that shaders are generated in pseudo code, and them transpilled to HSLS, GLSL, SPIR-V, etc.
  • Kontis - Wednesday, February 17, 2016 - link

    As explained by the dev here: http://steamcommunity.com/app/257510/discussions/0...

    this is currently a quick wrapper.

    This kind of a naive port from a high-level API (like dx 9/11) to DirectX 12 or Vulkan will always result in a degraded performance.

    If you want to benchmark Vulkan working in a way it was designed to be used, you have to wait for proper Vulkan renderer implementations.
  • ntsarb - Wednesday, February 17, 2016 - link

    Fully agree. Vulcan allows OpenGL to run on top. Hence, unless an application uses Vulcan directly, to take advantage of its multithreading capabilities, it can't take full advantage of it. Also, OpenGL over Vulcan will eventually be optimised.
  • ruthan - Wednesday, February 17, 2016 - link

    Yeah there will be some improvements, but it could be still badly designed API.
  • Klimax - Thursday, February 18, 2016 - link

    It won't matter much. In few years we will be all back in DirectX 11 and OpenGL. R7 285 already proved it in Battlefield 4 and Thief under Mantle. Guess, people need to be hit with far bigger hammer to understand. (Because nobody remember history nor theory for Turing machines...)

Log in

Don't have an account? Sign up now