Former Nvidia Dev's Thoughts on Vulkan/Mantle
1–10 of 163 posts
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#2From the looks of it, it seems Khrono's API may actually be significant better/easier to use than DirectX?
I haven't heard of DX12 getting overhauled for efficient multi-threading or great multi-GPU support. DX12 probably brings many of the same improvements Mantle brought, but Vulkan seems to go quite a bit beyond that. Also, I assume DX12 will be stuck with some less than pleasant DX10/DX11 legacy code as well.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#3This is interesting, it's good to hear the opinion of somebody who's actually programmed against the APIs. I think the increase in exposed complexity is probably a good thing. The AAA studios have proved that they're able and willing to throw engineering resources at tough problems, so actually allowing them to directly interact with a lower level of code is probably a good thing.
I'm sure there's a counterargument that it raises the bar for indie game devs, but when's the last time an indie game directly programmed against DirectX or OpenGL (barring webGL)? This should let engine developers better use their development time.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#4I've been discussing this a fair amount with a colleague, as I'm curious to see further uptake on linux as a gaming platform. I think the biggest barrier for this is when games are written for D3D and all of a sudden your game cannot communicate to any graphics API outside of windows.
More companies are starting to support OpenGL, but I'm just curious as to why uptake is so slow. It seems like poor API design may be a part of it. I'd like to see more games written with OpenGL support, and I think it's happening slowly but surely. We even see weird hacks add Linux support at this point... Valve opensourced a D3D -> OGL translation layer[0], though hasn't supported it since dumping it from their source.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#5Very interesting post.
So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold.
This begs the question: what about DirectX 12 and Apple's Metal? If they didn't have similar engine developer involvement, that's clearly a point against DX12/Metal support in the long run.
Also, the end is worth quoting in its entirety to explain why the APIs are taking such a radical change from the traditional rendering model:
Personally, my take is that MS and ARB always had the wrong idea. Their idea was to produce a nice, pretty looking front end and deal with all the awful stuff quietly in the background. Yeah it's easy to code against, but it was always a bitch and a half to debug or tune. Nobody ever took that side of the equation into account. What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. And that's been my experience so far in retooling: it's a pain in the ass, requires widespread revisions to engine code, forces you to revisit a lot of assumptions, and generally requires a lot of infrastructure before anything works. But once it's up and running, there's no surprises. It works smoothly, you're always on the fast path, anything that IS slow is in your OWN code which can be analyzed by common tools. It's worth it.
I wonder if/when web developers will reach a similar point of software layer implosion. "Easy to code against, but a bitch and a half to debug or tune" is an adequate description of pretty much everything in web development today, yet everyone keeps trying to patch it over with even more "easy" layers on top. (This applies to both server and client side technologies IMO.)
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#6From the looks of it, it seems Khrono's API may actually be significant better/easier to use than DirectX? I haven't heard of DX12 getting overhauled for efficient multi-threading or great multi-GPU support. DX12 probably brings many of the same improvements Mantle brought, but Vulkan seems to go quite a bit beyond that. Also, I assume DX12 will be stuck with some less than pleasant DX10/DX11 legacy code as well.
DX12 is actually a complete zero-legacy overhaul, just like Vulkan. It's designed with the same philosophy of tight, explicit control over how the GPU spends its time, and thin drivers - and from the information we have so far, it seems to have a quite similar design.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#7From the looks of it, it seems Khrono's API may actually be significant better/easier to use than DirectX? I haven't heard of DX12 getting overhauled for efficient multi-threading or great multi-GPU support. DX12 probably brings many of the same improvements Mantle brought, but Vulkan seems to go quite a bit beyond that. Also, I assume DX12 will be stuck with some less than pleasant DX10/DX11 legacy code as well.
DX11 already had a way better multithreading story than current-gen OpenGL (at present you can't even reliably do your swapbuffers on another thread - I was told this by a driver developer from one of the vendors about a year ago.)
It's possible Khronos will leapfrog DX12 with Vulkan in regards to threading but I find it highly unlikely. We'll know when one of the two actually publishes documentation (likely not soon, based on how long it took for Mantle to become available to the public)
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#8I've been discussing this a fair amount with a colleague, as I'm curious to see further uptake on linux as a gaming platform. I think the biggest barrier for this is when games are written for D3D and all of a sudden your game cannot communicate to any graphics API outside of windows. More companies are starting to support OpenGL, but I'm just curious as to why uptake is so slow. It seems like poor API design may be…
Having shipped multiple PC games with separate D3D/GL backends, and one game with GL only, a contributing factor here is that OpenGL (at least on Windows) still totally sucks.
To be fair, driver vendors have gotten a lot better. And the spec itself has matured tremendously, with some great features that don't even have direct equivalents in Direct3D.
Sadly as a whole the API still sucks, especially if you care about supporting the vast majority of the audience who want to play video games. Issues I've hit in particular:
Every vendor's shader compiler is broken in different ways. You HAVE to test all your shaders on each vendor, if not on each OS/vendor combination or even each OS/vendor/common driver combination. Many people are running outdated drivers or have some sort of crazy GPU-switching solution.
The API is still full of performance landmines, with a half-dozen ways to accomplish various goals and no consistent fast-path across all the vendors.
At least on Windows, OpenGL debugging is a horror show, especially if you compare it with the robust DirectX debugging tools (PIX, etc) or the debugging tools on consoles.
Threading is basically a non-starter. You can get it to work on certain configurations but doing threading with OpenGL across a wide variety of machines is REALLY HARD, to the point that sometimes driver vendors will tell you themselves that you shouldn't bother. In most cases the extent of threading I see in shipped games is using a thread to load textures in the background (this is relatively well-supported, though I've still seen it cause issues on user machines.)
OpenGL's documentation is still spotty in places and some of the default behaviors are bizarre. The most egregious example I can think of is texture completeness; texture completeness is a baffling design decision in the spec that results in your textures mysteriously sampling as pure black. Texture completeness is not something you will find mentioned or described anywhere in documentation; the only way to find out about it is to read over the entire OpenGL spec, because they shoved it in an area you wouldn't be looking to debug texturing/shading issues. I personally tend to lose a day to this every project or two, and I know other experienced developers who still get caught by it.
I should follow with the caveat that Valve claims GL is faster than Direct3D, and I don't doubt that for their use cases it is. In practice I've never had my OpenGL backend outperform my Direct3D backend on user machines, in part because I can exploit threads on D3D and I can't on GL.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#9Very interesting post. So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold. This begs the question: what about DirectX 12 and Apple's…
I wouldn't call it a software layer implosion -- most people are going to continue to use abstractions on top of these API's for game development. Unity is to Rails, etc ...
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#10Very interesting post. So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold. This begs the question: what about DirectX 12 and Apple's…
About your last paragraph, I would say that that is even more important to optimize and to make low level layers for than graphical game engines (believe it or not :)).
The thing is while gaming is seen as a "performance critical" application, where it is natural to want the maximum performance to be squeezed out of your hardware, Web development is just a behemoth of inefficiency, and we think that that is the norm, an inevitable drawback of developing for the web, an inescapable trait of web applications. Web apps are dozens or even hundreds of times slower than native applications, and we think nothing of it, because it seems to be an inherent characteristic of the web about which we can't do anything.
Your comment made me reconsider that. Maybe it doesn't have to be so. What if there was a Vulkan for the web, instead of the layers upon layers of inefficiency which are all the rage these days? What if I could run a medium complexity web page or app without it bogging my computer several times harder than a comparable native app?