Live data from Hacker News

Former Nvidia Dev's Thoughts on Vulkan/Mantle

gamedev.net

51–60 of 163 posts

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#51
post #12

> What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. So true and yet, we have all those crazy JavaScript frameworks trying to abstract everything away from developers. There's a lesson in there.

You cannot abstract away complexity. This is a lesson people relearn every 2-3 years or so. From the javascript frameworks - I use only backbone and jquery - first as a simple router, second for easy dom traversal.

> You cannot abstract away complexity. This is a lesson people relearn every 2-3 years or so.

This is so true. You can, however, successfully abstract away a bunch of boilerplate for common actions, and enforcing patterns. The key to a framework (and skill of the developer), is knowing when and how to avoid the abstractions.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#52
Performance gains are worth any trouble IMO, here is why:

While at GDC I saw a DirectX 12 API demo (DX12 is more/less equivalent to Vulkan from an end-goal perspective). On a single GTX 980:

DX11 was doing ~1.5 million drawcalls per second. DX12 was doing ~15 million drawcalls per second.

This API demo will ship to customers, so I am pretty sure we can easily verify if these are bunk figures. But a potential 10x speedup, even if under ideal conditions, is notable.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#53
post #10

Earlier quoted context omitted.

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…

Write your whole webapp in WebGL? Edit: Seriously, how feasible is that? Creating a GUI framework on top of WebGL and creating an abstraction layer (which the original article advises against) would be a huge performance boost comparing to current webpages, wouldn't it?

Someone did this with their WebGL Terrain demo [0]. You can find a detailed post-mortem in the author's blog [1].

[0] http://zephyrosanemos.com/windstorm/current/live-demo.html

[1] http://zephyrosanemos.com/

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#54
post #46

Earlier quoted context omitted.

This is already how we do it on most consoles. The CPU has to sync with the GPU to know when the resources associated with draw commands are safe to release. Having something like glTexImage2D is way too high level for these graphics APIs and would be a luxury. Instead we get a plain memory buffer and convert manually to the internal pixel format. There is no waiting to free resources however, unless either the CPU o…

Do you think -- since the XBox One and PS4 both use an AMD GPU -- that the developer tools will improve on Desktop PCs?

Hard to say, they are very different tools aimed at different audiences. Console SDKs are behind huge paywalls and all their tools and documentation are confidential. The developer networks even go as far as checking if the requesting IP address is whitelisted.

I haven't had to profile an AAA title for the desktop so far and therefore don't know much about the state of tools there. However, I heard only good things about Intel's GPA.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#55
post #10

Earlier quoted context omitted.

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…

Write your whole webapp in WebGL? Edit: Seriously, how feasible is that? Creating a GUI framework on top of WebGL and creating an abstraction layer (which the original article advises against) would be a huge performance boost comparing to current webpages, wouldn't it?

To be fair, I think the takeaway isn't don't make/use abstraction layers, but don't make a one-size-fits-all abstraction and then hide the lower level stuff. A targeted abstraction that correctly supports the domain you are in is still a good thing. That's what the engine developers end up being here, an abstraction on top of this low level API that gives many devs exactly what they want.

Edit: To be clear, I don't think writing a web rendering engine meant to do the same think as the browser on top of WebGL will be faster in any respect, as really the HTML and CSS are just inputs fed into super optimized low level rendering engines. I don't see how JS could compete in that domain.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#56
The idea that nVidia and AMD are detecting your games, and then replacing shaders, optimizing around bugs, etc should be absolutely terrifying. And vice versa, the idea of having to fix every major game's incredibly broken code is equally terrifying. And it's a huge hit to all of us indie devs, who don't get the five-star treatment to maximize performance of our games. So overall, I'd say this is a step in the right direction.

However! Having written OpenGL 3 code before, the idea that Vulkan is going to be a lot more complex, frankly scares the hell out of me. I'm by no means someone that programs massive 3D engines for major companies. I just wanted to be able to take a bitmap, optionally apply a user-defined shader to the image, stretch it to the size of the screen, and display it. (and even without the shaders, even in 2015, filling a 1600p monitor with software scaling is a very painful operation. Filling a 4K monitor in software is likely not even possible at 60fps, even without any game logic added in.)

That took me several weeks to develop just the core OpenGL code. Another few days for each platform interface (WGL/Windows, CGL/OSX, GLX/Xorg). Another few days for each video card's odd quirks. In total, my simple task ended up taking me 44KB of code to write. You may think that's nothing, but tiny code is kind of my forte. My ZIP decompressor is 8KB, PNG decompressor is another 8KB (shares the inflate algorithm), and my HTTP/1.1 web server+client+proxy with a bunch of added features (run as service, pass messages from command-line via shared memory, APIs to manipulate requests, etc) is 24KB of code.

Now you may say, "use a library!", but there really isn't a library that tries to do just 2D with some filtering+scaling. SDL (1.2 at least) just covers the GL context setup and window creation: you issue your own GL commands to it. And anything more powerful ends up being entire 3D engines like Unity that are like using a jack hammer to nail in drywall.

And, uh ... that's kind of the point of what I'm doing. I'm someone trying to make said library. But I don't think I'll be able to handle the complexity of all these new APIs. And I'm also not a big player, so few people will use my library anyway.

So the point of this wall of text ... I really, really hope they'll consider the use case of people who just want to do simple 2D operations and have something official like Vulkan2D that we can build off of.

Also, I haven't seen Vulkan yet, but I really hope the Vsync situation is better than OpenGL's "set an attribute, call an extension function, and cross your fingers that it works." It would be really nice to be able to poll the current rendering status of the video card, and drive all the fun new adaptive sync displays, in a portable manner.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#57
post #44
post #19

To me, this neatly explains why in just about every performance comparison of video drivers in Linux shows the proprietary drivers having an edge, even if only a slight one. I've never actually dived into the source code for the open source video drivers but I'm now curious how much time the devs of the open-source drivers have to spend on anticipating and routing around the brain damage of the programs calling them.…

I've spent a fair bit of time in the open source radeon and nouveau drivers and I never noticed any workarounds in place solely to fix a broken client. Open source driver developers don't have the time or resources to pull off a stunt like that!

Or, more importantly, motivation.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#58
post #25
post #5

Very 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…

"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." There's several parts to this. DirectX 12 is going to run on Windows 10, and its adoption by developers is probably going to be entirely driven by how much of their target audience can be persuaded to upgrade from Windows 7. If…

We don't know yet whether Apple will adopt Vulkan or not. Vulkan is not just a direct competitor to Metal, but also an evolution of OpenGL ES, and so far Apple has adopted OpenGL ES.

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#59
post #10

Earlier quoted context omitted.

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…

Write your whole webapp in WebGL? Edit: Seriously, how feasible is that? Creating a GUI framework on top of WebGL and creating an abstraction layer (which the original article advises against) would be a huge performance boost comparing to current webpages, wouldn't it?

Take a look at what Flipboard did recently, with their whole mobile site built in JS and canvas

http://engineering.flipboard.com/2015/02/mobile-web/

Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle

#60
post #12

> What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. So true and yet, we have all those crazy JavaScript frameworks trying to abstract everything away from developers. There's a lesson in there.

You cannot abstract away complexity. This is a lesson people relearn every 2-3 years or so. From the javascript frameworks - I use only backbone and jquery - first as a simple router, second for easy dom traversal.

Hearing web developers discuss the dangers of abstraction is just about the craziest thing in computer science. JavaScript and the DOM sit atop layer upon layer upon layer of abstraction that hides an absolute mountain of complexity around networking, memory management, hardware capabilities, parsing, rendering, etc.

Believing you're somehow avoiding abstraction because you only use a couple of additional libraries on top of JS and the DOM is like insisting on a 99th storey apartment instead of an 100th storey one, because you prefer being close to the ground.

You can by all means argue that all the big JS frameworks are poor abstractions. But a sweeping statement like "you cannot abstract away complexity" completely ignores the fact that web development as a field is only possible because of the successful abstraction of huge quantities of complexity.

Post reply on HN