Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Former Nvidia Dev's Thoughts on Vulkan/Mantle

gamedev.net

Post reply on HN
Print view View original

71–80 of 163 posts

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

#71

Post by zanny »

comex wrote: post #50
dietrichepp wrote: post #11

Earlier quoted context omitted.

It sounds like Vulkan is not going to be easy to use. If anything, it is going to be harder to use. For example, in OpenGL, you can upload a texture with glTexImage2D(), then draw with glDrawElements(), then delete it glDeleteTextures(). The draw command won't be complete yet, but the driver will free the memory once it's no longer being used. It sounds like with Vulkan, you'll need to allocate GPU memory for your te…

I wonder if we'll start to see lightweight Vulkan (or DX12) wrapper libraries that attempt to restore some of the convenience of old fashioned OpenGL, sans legacy baggage, without the complexity and opinionatedness of full-fledged game engines.

There is some interest from LunarG to reimplement OpenGL in Mesa on top of Vulcan eventually. So yes. Its the same way Gallium3d can implement Direct3d and OpenGL against one intermediary representation (TSGI) and backend hardware interface (winsys).

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

#72

Post by tarpherder »

malkia wrote: post #62
gavanwoolery wrote: post #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 spee…

That's great, and for project like yours (Voxel Quest), it'll definitely help. I'm wondering though, if the demo also uses the CPU for other things - physics, audio, collision, path-finding or some other form of ai, state machines, game script, game logic. My point is that 10x might be possible (on a 10 core cpu) if the cpu's are only used for graphics, but there are other things that come into play... But even then,…

  The bigger question to me, is how would game developers
  on the PC market (OSX/Linux included) would scale their
  games? You would need different assets (level of detail?
  mip-mapped texture levels? meshes?) - but tuning this to
  work flawlessly on many different configurations is
  hard...
This isn't really any different from what it has been until now. All AAA games have different levels of detail for meshes/textures/post-processing etc. Even when not exposed to the user as options in a menu these different levels of detail exist to speed up rendering of for example distant objects or shadows where less detail is needed. DX12/Vulkan is not going to change anything in that regard.

Doing a good PC port is not as easy as it may seem at first glance. Different hardware setups and little control over the system cause lots of different concerns that simply don't exist on consoles, which means nobody bothered taking that into account when the game was originally built. These new APIs will help though; the slow draw calls on PC are a pain compared to lightning fast APIs on consoles (even Xbo360/PS3!).

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

#75

Post by archagon »

pavlov wrote: 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…

> I wonder if/when web developers will reach a similar point of software layer implosion.

Will doing things the "good but hard" way force me to write tons of boilerplate? Because as a (currently iOS) programmer, as soon as I start having to write generic, structural code, I find it difficult to sustain my interest in the project. I want to go from idea to something that works as quickly as humanly possible; having to remake the universe from scratch just because somebody somewhere needed the performance is not what I got into the game for.

(I'm currently working with OpenGL for the first time, and, ugh, all the state management stuff and shader boilerplate is driving me crazy — especially after years of the relative ease of dealing with UIKit! Am I to understand that Vulkan will only make things worse in this regard? I guess it's good for engine devs, but I would not want to code like this in my day-to-day.)

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

#76

Post by jeremiep »

malkia wrote: post #43
jeremiep wrote: post #31

Earlier quoted context omitted.

Exactly. This is why I like Rich Hickey's Simple Made Easy [1] so much. Basically with easy constructs it becomes harder to build simple systems, even though the simple constructs are harder to learn. [1]: http://www.infoq.com/presentations/Simple-Made-Easy

I love this talk, and Rich Hickey's talks in general, but I think this goes beyond that. At one point you want full control of the HW, much like you did with game consoles.. On the other you want security: This model must work in a sandboxed (os, process, vm, threads, sharing etc.) environment, along with security checks (oldest one that I remember was making sure vertex index buffers given to the driver/api must not…

(To anwser the lack of a reply button:)

This is just hn adding a delay until the reply link appears related to how deeply nested the comment is. The deeper the longer the delay. It's a simple but effective way to prevent flame wars and the likes.

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

#77

Post by adrusi »

lambda wrote: post #26

These are the vanishingly few people who have actually seen the source to a game, the driver it's running on, and the Windows kernel it's running on, and the full specs for the hardware. Nobody else has that kind of access or engineering ability. One option is to release the source of the drivers, making it possible for motivated engine developers to do this without explicit access to AMD developers. If they did this…

It seems to me, based on this article, that providing support to major game studios and releasing driver updates to accommodate their games is a major revenue source for GPU manufacturers. I guess that's why only Intel releases open source drivers: their GPUs aren't really expected to provide high performance for games.

I guess with Vulcan/Mantle, the drivers are just trivial hardware abstraction layers, so the GPU manufacturers no longer have to make up for the cost of developing complex drivers by doing part of the work on every AAA title.

We might see Nvidia and AMD releasing open source Vulcan drivers, and if not, it would at least be easier for reverse-engineering projects like Nouveau to produce competitive drivers. This at least means you don't have to have non-free code running in ring-0 to use a discrete graphics card on Linux.

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

#78

Post by RaleyField »

emilsedgh wrote: post #24
andrepd wrote: 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?

WebGL should never have been invented, at least on current architectures. It's a ticking bomb, precisely for the reasons this articles explored - drivers are complex and buggy black boxes that lie in kernel space so ring 0 access is never too far from reach for many exploits. WebGL has a potential to be exploit vector much more severe than what we've seen with other auxiliary web technologies like JavaScript or Java applets. Why not confine web to (mostly) nicely behaved x86 VMs?

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

#79

Post by ertdfgcb »

vehementi wrote: post #49

"Former Nvidia dev" - s/he did an internship there. Maybe too weighty a HN title.

I'd agree, but they certainly know what they're talking about so I don't really mind. They obviously did some form of software development at Nvidia if only as an intern.

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

#80

Post by ekianjo »

gavanwoolery wrote: post #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 spee…

> 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.

Valve was showing DOTA 2 running on Vulkan with Source 2 at greate framerates too (with many peons on screen) running on... Intel HD graphics.

So it does seem that we will get a large performance boost with Vulkan / DirectX 12.

Post reply on HN