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…
Isn't Google's Native Client the Vulkan of the web? Or rather wasn't it, given adoption outside of Chrome is unlikely to ever happen.
Former Nvidia Dev's Thoughts on Vulkan/Mantle
61–70 of 163 posts
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#62Performance 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, even if only half the cpu's are used for graphics, it's still better.
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...
Especially if there are applications still running behind your back.
E.g. - you've allocated all cpu's for your job, all to be taken by some background application, often a browser, chat client, your bit-coin miner or who knows what else.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#63Very 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…
Both are valuable. Plenty of people don't need the full power & debuggability of a difficult high-performance API- but plenty of people do, too.
Much like the simultaneous ubiquity of C/C++ and Python, in their respective spaces.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#64Reminds me a bit of what I recall as a unix principle: The API should be designed so that the implementation is simple, even if that makes the use complex.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#65Earlier 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…
GPUs these days have MMUs and have address spaces allocated per context. It's implemented internally to the driver though so you don't see it. And it's normally mapped differently, but the point of AMD's HSA stuff is to make the CPU's and GPU's MMU match up.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#66Very 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…
Both are valuable. Plenty of people don't need the full power & debuggability of a difficult high-performance API- but plenty of people do , too. Much like the simultaneous ubiquity of C/C++ and Python, in their respective spaces.
I wonder if we'll see opengl-old implemented on top of vulkan. Actually one thing I would love to see is vulkan on linux accessible from userspace without any involvement of a window server, so that you can write the rest of the APIs on top of it. Maybe even have graphical console running on it.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#67What an horror show.
I always was interested in game programming, but never was able to really get interested enough in graphics programming, I guess having a messy API is not an excuse, but you can really sense that CPUs and GPUs really have different compatibility stories, and that's maybe why it's not attracting enough programmers.
I still hope that one day there might some unified compute architecture and CPUs will get obsolete. Maybe a system can be made usable while running on many smaller cores ? Computers are being used almost exclusively for graphic application nowadays, I wonder if having fast single core with fat caches really matters anymore.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#68For reference, here's a tutorial on drawing a triangle in Apple's Metal, which follows some of the design principles as Vulkan, Mantle and DX12: http://www.raywenderlich.com/77488/ios-8-metal-tutorial-swif...
So, essentially, no validation, you have to manage your own buffers (with some help in DX12 I think), you can shoot yourself in the foot all day long. But if you manage to avoid that, you are able to reduce overhead and use multithreading.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#69How come, that the open source drivers did not show much better performance?
Because the documentation for the hardware is not open source. You need to sign very strict papers to be able to look at the hardware documentation which means few selected people have access to it which means not much support, etc. Can't remember why I know this but it was something related to my linux open source back in the days.
AMD and Intel publish ISA documentation and design docs for their gpu parts. Intel usually does it same day as release, AMD usually do it a few months post release. Nvidia, Qualcomm, etc all release nothing, and therefor everything is proprietary and must be reverse engineered from scratch.
Re: Former Nvidia Dev's Thoughts on Vulkan/Mantle
#70Earlier quoted context omitted.
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)
Native JavaScript performance is not generally what makes web apps slow.