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

41–50 of 163 posts

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

#41

Post by hellotimmutton »

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?

Except that it would all still be done via a layer of javascript (using asm.js may mitigate this)

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

#42

Post by jeremiep »

dietrichepp wrote: post #11
higherpurpose wrote: post #2

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

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…

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 or GPU is starving for work. We have a triple-buffering setup and on consoles you also get to create your own front/back/middle surfaces as well as implement your own buffer swap routine. This provides a sync point where we can mark the resources as safe to release.

It's definitely more complexity on the engine part, but as mentioned in the forum post it makes everything much, much easier when you get to debug and tune things. Also having to implement (or maintain) all of that engine infrastructure gives us a better perspective into how the hardware works and how to optimize for it.

However, even with Vulkan or DirectX12 I doubt NVidia or AMD will expose their hardware internals publicly which is critical in optimizing shader code. On consoles we get profilers able to show metrics from all of the GPU's internal pipeline. It makes it easy to spot why your shader is running slow without having to send your source code to the driver vendor.

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

#43

Post by malkia »

jeremiep wrote: post #31
mreiland wrote: post #30

Earlier quoted context omitted.

That last quote really resonates with my experience of software dev in general. "easy" API's generally do it by making a ton of assumptions. Modifying those assumptions becomes a huge pain point and that's if the API even allows you to modify that particular assumption.

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 reference invalid memory, something you would make sure is not the case for a console game through tests, but something that the driver/os/etc. must enforce and stop in a non-console game world - PC/OSX/Linux/etc.)

From little I've read on this API, it seems like security is in the hands of the developer, and there doesn't seem to be much OS protection, so most likely I'm missing something... but whatever protection is to be added, definitely would've not been needed in the console world.

Just a rant, I'm not a graphics programmer so it's easy to rant on topics you just scratched the surface...

----

(Not sure why I can't reply to jeremiep below), but thanks for the insight. I was only familiar with one I posted above (and that was back in 1999, back then if my memory serves me well, drawing primitives on Windows NT was slower than 95, because NT had to check all index buffers whether they were not referencing out-of-bounds, while nothing like this was on 98).

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

#44

Post by sounds »

korethr wrote: 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!

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

#45

Post by achamayou »

angersock wrote: post #13
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…

So, this suits big engine and AAA studios really well, right, because they can spare that time. Indies are going to increasingly look at the web and other interfaces because of the easy layers.

With all the free engines available these days, the situation for indies has never really been better.

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

#46

Post by sounds »

jeremiep wrote: post #42
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…

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?

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

#47

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…

Security is actually much easier to implement on the GPU than on the CPU. For the simple reason that GPU code has to be pure in order to get this degree of parallelism. A shader is nothing more than a transform applied to inputs (attributes, uniforms and varyings) in order to give outputs (colors, depth, stencil).

Invalid data would simply cause a GPU task to fail while the other tasks happily continue to be executed. Since they are pure and don't interact with one another there is no need for process isolation or virtualization.

Basically, its easy to sandbox a GPU when the only data it contains are values (no pointers) and pure functions (no shared memory). Even with the simplified model the driver still everything it needs to enforce security.

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

#48

Post by jsheard »

cwyers wrote: post #25
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…

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

The Xbox One is being updated to support DX12 as well, so the major engines will adopt it regardless of whether Windows 10 gets any traction - in fact, Unity and UE4 already have.

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

#50

Post by comex »

dietrichepp wrote: post #11
higherpurpose wrote: post #2

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

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.
Post reply on HN