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

151–160 of 163 posts

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

#151

Post by mreiland »

saidajigumi wrote: post #112
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.

> "easy" API's generally do it by making a ton of assumptions. Well, perhaps a better way of putting it is that "easy" APIs try to model a domain. Sometimes the API designer just nails it, and folks forget eventually take it for granted. The problem is now "solved". For example, the Unix userspace filesystem API (open, close, read, write, etc.) is pretty damn solid for what it is. I admit that I took it for granted u…

No, it's about the assumptions and it's a mistake to move away from that mindset.

The Unix filesystem api isn't complete, if it were ioctl wouldn't exist. Assumptions all around, and ioctl is the way you adjust those assumptions.

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

#152

Post by mreiland »

stupidcar wrote: post #60
venomsnake wrote: post #33

Earlier quoted context omitted.

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

I don't think anyone is saying the browser et al aren't abstractions. Think of it like this, no amount of abstraction will save you from having a network connection go away. That sort of use case adds complexity, and you can't get around it.

The browser severely limits what you're able to do with the network connection, but at the end of the day dealing with the network is a complex beast.

If you doubt, look no further than the HTML5 caching API's. The tooling around them is absolutely terrible, but even if it weren't there's an inherent complexity with that sort of thing.

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

#153

Post by thechao »

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…

> Many years ago, I briefly worked at NVIDIA on the DirectX driver team (internship).

I've been a full-time GPU engineer at a couple of major companies for about 6 years now. My colleagues at my current company have all been GPU engineers (and video, prior to that) in the 20--30 year range.

While a lot of the technical details are correct, there are a lot of red-flags in this guy's essay. For instance:

> Although AMD and NV have the resources to do it, the smaller IHVs (Intel, PowerVR, Qualcomm, etc)

Intel owns, what? 60? 70 percent of the desktop market? More? PVR, Qualcomm, etc. own 90% of the mobile market? Intel has an enormous number of GPU engineers---far more than AMD, and easily comparable to (or more than) NV.

Now, to OP's statement about DX12 & Metal: obviously they were developed cojointly with AAA game developers. The major title developers are in constant contact with every major IHV and OS vendor (less so for open-source) at all stages with respect to driver- and API- development.

Furthermore, it's not like the major architects and engineers of these driver teams are total tools; these guys live and breathe GPU architecture (and uarch), and are intimately familiar with what would make a good driver.

The impetus for these low level APIs is differentiation and performance. When those couldn't be had from GPU HW, the next place to look is "one up the stack": driver & API. It surprised no one in the industry that Mantle/Vulkan/Metal/DX12 all came out at about the same time: we've all been pushing for this for years.

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

#154

Post by pjmlp »

greggman wrote: post #88
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…

Maybe you're optimizing for the wrong thing? Let's imagine a world where a browser is just a secure place to execute code. You get vulkan, io, networking, input, camera access in a cross platform way. So, how do search engines find any info? How do you share links to content? How do you support braille readers? Browser extensions? I'd argue those things are pretty essential to the web as we know it (well maybe not th…

> So, how do search engines find any info?

Desktop integrated search.

> How do you share links to content?

Extensions, contracts and intents.

> How do you support braille readers?

OS Accessibility APIs

> Browser extensions?

Plugins

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

#155

Post by vcarl »

yoklov wrote: post #34
vcarl wrote: post #3

This 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 t…

> when's the last time an indie game directly programmed against DirectX or OpenGL (barring webGL)? I don't work in indie, but my understanding is that this is still pretty common, especially for games with any budget at all.

I'm sure it still happens, but the popularity of Unreal, Unity, etc says to me that they likely wouldn't be too negatively effected.

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

#156

Post by outworlder »

vcarl wrote: post #3

This 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 t…

Minecraft?

Most indie games can happily use Unity or whatever, but there are cases where they are not suitable.

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

#157

Post by cwyers »

thechao wrote: post #153
cwyers wrote: post #25

Earlier quoted context omitted.

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

> Many years ago, I briefly worked at NVIDIA on the DirectX driver team (internship). I've been a full-time GPU engineer at a couple of major companies for about 6 years now. My colleagues at my current company have all been GPU engineers (and video, prior to that) in the 20--30 year range. While a lot of the technical details are correct, there are a lot of red-flags in this guy's essay. For instance: > Although AMD…

Thanks for this. It makes sense that DX12 was developed alongside engine devs. As jsheard notes, Unity and Unreal Engine have already announced support for it, and we're already seeing tech demos of Unreal Engine on DX12:

https://www.youtube.com/watch?v=FIk8Q8luWsI

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

#158

Post by whizse »

sounds wrote: post #44
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!

There are workarounds for broken behaviour though: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/...

I think that in some cases the developers (at least Intel) have reached out to game developers first, to get them to fix their own bugs/out of spec behavior.

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

#159

Post by cwyers »

venomsnake wrote: post #33
pothibo wrote: 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.

Oh sure you can. It just costs something. The most common tradeoff is that you abstract away complexity in favor of performance.

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

#160

Post by byuu »

likeclockwork wrote: post #130
near wrote: post #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…

Would you mind sharing the scaling/filtering code you spoke of?

Sure. Here is the main index:

https://gitorious.org/bsnes/bsnes/source/1a7bc6bb8767d6464e3...

The platform abstraction layers are wgl.cpp, cgl.cpp and glx.cpp

Go inside the opengl/ subfolder to find all the platform-agnostic OpenGL code. opengl/surface.hpp gets particularly fun using matrix multiplication to compute model view / projection / texture coordinates by hand (which you need to do for the new GL3 / no-fixed-function-pipeline stuff.) Also has lots of required internal allocations.

In my own case, I allow user-defined additional shader passes, and that adds to the code a bit. But note that another thing about GL3 is that you do actually have to create and execute at least one vertex + one fragment shader.

GL2's FFP, while still difficult, was a whole lot easier. The driver did a lot of the work you have to do manually if you want to follow GL3.2-core/GL ES/etc.

Post reply on HN