 We're here at the Lunara Connect and who are you? I'm Neil Trevitt, I'm VP at NVIDIA but I'm also president of the Kronos Group. So, what is a Kronos Group? What does it stand for? What's the name? Well, the name is a proud history of misspelling Roman deities. But Kronos is an open standards organisation. We create API specifications, sort of royalty free to the industry for software using hardware acceleration for things like graphics and parallel computation and vision processing. So, it's allowed to do the GPU, right? GPU is certainly one common accelerator, but not by no means the only one. For graphics, you would typically have a GPU and for compute as well. But there are other types of accelerator too. Some people want to run their code across multiple CPU cores. Some people want to use DSPs. For some of our APIs, like OpenCL, you can even use hardware blocks, ISPs, as well as FPGAs. So, there's quite a diverse mix of hardware acceleration that we can use. So, you're the core of the heterogeneous computing's future, right? It's a bunch of APIs for people to use all this hardware. It's really important. Right. So, probably our two best known APIs are OpenGL for graphics and OpenCL for compute acceleration. So, for parallel computation, people would use OpenCL. And in OpenCL, yes, you can use very wide diversity of processor cores. You write your software, you divide it up into kernels, and then you can distribute those kernels to run across any of the available computing resources. And those compute resources you can use. CPUs, GPUs, hardware, DSPs, FPGAs, the list goes on and on. And we just at the beginning of how developers are able to use the hardware, right? What's going to happen in the future? You were talking about Vulkan. What is that about? Yes. So, the new generation of APIs, the key one is Vulkan. It's still in development. We'll have the spec by the end of the year. And unlike the older generations where we had separate APIs for graphics and compute, OpenGL, OpenCL, Vulkan brings everything into one API. So, you can mix and match graphics and compute in a much tighter, more intertwined way. So, Vulkan has the same kind of queuing structure as OpenCL. It has all the graphics functionality of OpenCL and OpenGL. So, you don't need to have two APIs interoperating. Everything can be in one API framework. And it's going to work on all devices, like from mobile to desktop? That's right. So, again, in the old generation, we started out with OpenGL, which was originally designed for workstations. And then we had the opportunity to bring it to mobile, so we created a subset for OpenGL ES. With Vulkan, we're going to have one framework. There's going to be no need for Vulkan ES. The framework has feature set capability, so a particular platform can define which parts of Vulkan will be available on that particular platform. But it'll be the same API framework wherever you go, as you say, from embedded through mobile to PCs all the way up to supercomputers. Is it backwards compatible somehow? Like if people are creating a game, should you just focus on that? Or is it something to do with that? It's not backwards compatible. So, the industry is going through a new generation API, backward compatibility break. DirectX 12 is not backwards compatible with DirectX 11. Apple has Nettle, which is entirely new. Vulkan is entirely new. It's a clean sheet design. OpenGL has been around for almost 25 years, so it's time for a reset. The systems and the processes have changed a lot in that time. You need a new generation, clean design. So, if your Vulkan 1.0 is going to be primarily aimed at the developers need absolutely best performance and are willing to put in the time to optimize to the new API, there's going to be quite a long transition, where people will continue to use OpenGL and OpenGL ES. It's familiar. It does a very good job. But over time, more and more people who want the very best in performance using the new generation features will transition across to Vulkan. So, it sounds like it's, how complicated is it to program for Vulkan? Like, is it something that's really hardcore? You need hundreds of developers in a big game company? It's not necessarily more difficult. It's just the difficulty is in a slightly different place. So, it's a much lower level API. So, the memory and buffer allocation or the multi-threading is not hidden in the driver anymore. It's just exposed and it's the responsibility of the application developer. So, with the old generation APIs, if you were developing a game that had to port across multiple different platforms, the problem is that the OpenGL or OpenGL ES drivers would behave slightly differently on each of those platforms. So, it's a high-level API. It's easier to write the code. We had to spend a lot of time forensically trying to understand why it behaves differently on different platforms, and that's where your time went. With Vulkan, it's much lower level, but you can see everything much more clearly. So, you might spend a few, a little longer writing your code because there's more things you have to do, but you won't spend, it'll be much more reliable and much more performance easily across multiple different platforms. So, you won't have to spend all that time trying to figure out what are the drivers doing behind my back. And I think with Vulkan, it'll be a great foundation layer. When people are developing games, they'll probably never have to use Vulkan, they'll just use a games engine, like Unity or Epic. They will be optimized for Vulkan, and games developers will just use the games engines that run better because of the new API. And Google Android is totally on board with this? Yes. So, in the summer at SIGGRAPH, Google announced that Vulkan API, along with OpenGL ES, they're not throwing out OpenGL ES, OpenGL ES is still going to be there, but Vulkan is going to be natively supported on Android, in an upcoming Android version. They didn't announce precisely when or what, but they have announced their support. So, we hear the Nenaro connect. So, you're saying that you want input, you want to discuss what's going on? Yes. So, with the new generation API, Vulkan and Spear, which is the intermediate representation that goes along with Vulkan and OpenGL. A lot of the tool chain, the conformance tests, the compiler front-ends, Kronos are committed to put all this into open source, to enable the open source community, like Nenaro, to contribute and to leverage the work we're doing in open source. So, Nenaro, I think the Nenaro community has a real opportunity to contribute to the tools and the front-ends and the compilers that we're building and to leverage what we're doing in their own projects. Vulkan is going to be much, the ecosystem is going to be much more open source based than OpenGL ES ever was. So, it really brings the two communities much closer together. More open source based. Yes. So, there is some stuff going on with the free Drino, which is kind of cool, no? There's an open source driver that's happening. What do you think about that? Is it something that's very good for the industry? It's always good to have more choices and some developers where open source drivers are critical, obviously it's good to have the drivers available. For many hardware vendors, silicon vendors, being able to do optimized drivers is still an essential part of the real-world business model. That's why you still need a specification for Vulkan so people can implement and optimize their own runtimes even if that particular implementation is not in open source. Because we have a reliable performance-tested specification, people will be able to use different runtimes, open source runtimes, closed source runtimes and their application will be able to run reliably across all of those different implementations. There's a lot of competition going on with the GPU and all these different GPUs and the ARM ecosystem. There's a lot of innovation happening. It feels like every year, things are getting twice as better. It's crazy fast. Like a phone now is as powerful as a home console. It is. Yes, you can plug in to many mobile devices like in my own company, the Nvidia Shield, you can plug it in and you cannot tell. It's not a high-end PC, but for many of the games that are out there, it's amazing how fast mobile graphics has come. One of the important attributes of a successful API specification is that it encourages implementation differentiation and competition underneath the specification. It shouldn't stifle and mandate implementation. It should encourage multiple different implementation styles that compete. That's what keeps the GPU moving along and that's why we're getting such rapid progress. It's amazing quality, but we still need some kind of push in the platform because the content is not really there. So maybe it's something to do with Android too. What do you think needs to be a big platform where all the games will be amazingly awesome on phones? I think the Android platform has made amazing progress. The number of games that run great on Android is actually pretty amazing to go to the Play Store. But Vulkan will help, and I think that's why Google have stated their support for this new generation API. It's this low-level, explicit access. It's very similar to what the consoles have had for a while. If you're coding to an Xbox or PlayStation, you kind of get down and dirty with the hardware. It's much more than you do with old-style DirectX or OpenGL. The fact that that style of API is going to be available on Android and across multiple other platforms too. So you can get a games engine or a games application or other applications that can be written to OpenGL to get the best out of the platform and be portable. I think it's going to encourage other games developers to invest in the API platform and users will benefit. We'll get better games and run better. Do you consider the Corus Group and your job as managing the gaming world or do you see it as much bigger than that? It's going to be computing, right? Our job is to enable innovation. We're just working one layer in the software stack. We're just working at the interface between hardware and software. It's a very important interface. That's why we think what we do is relevant to many people in the industry. But we're just solving that one problem. And then other people can build games engines, middleware layers, applications that we've never imagined. We're just making sure that application developers and middleware engines can get to the hardware efficiently and then we let the rest of the market innovate on top of that. May I ask you shortly, how does it work that all these companies work together and work with you and how do you do the daily work to get things moving? Well, from a logistical point of view, we just make sure that Kurnos is a safe place. We have a good IP framework. Everyone understands good, well-proven processes. But that's the boring answer. The real answer is the people that join Kurnos, they understand that their business will get better if they cooperate over some things and then compete on other things. If the world is just big competition and we can never agree on a standard to break down barriers to market adoption and to improve technology that can be implemented in an affordable way, then everyone loses. So we need to have a place where we can solve the problems that we don't need to compete on. We should cooperate together. And then we can all go off into the marketplace and compete on our implementations of those standards. And the people that are inside Kurnos kind of realize that their business as well as the industry benefits from having a place to work together. It sounds a little bit similar to Leonardo, no? It is. It is similar to Leonardo. Lots of the core values are exactly the same, which is why I think there is a real opportunity to work together. Our missions are slightly different. Leonardo is primarily an open source consortium with building products, the building distributions, upstreaming them to Linux and Android. Kurnos' primary mission is to create specifications that people can implement in hardware. But increasingly, we are using open source to enable those specifications to be used and to be adopted throughout the industry, which is why I think we are coming together. Do you think those things are going fast enough, like Leonardo and Kurnos, to go even faster? And how would it go faster? It's never fast enough. I think... Well, that's a good question. We're going about as fast as we can. There's not a lot of overhead now in processes. We are going pretty much as fast as the hardware is evolving and can cope. We could go faster, and we're not ten times too slow. We could be a little bit more efficient, but we're working always to make our processes more efficient. But we're pretty much working as fast as people are able right now. Do you think Leonardo is working as fast as they can too? I'm sure they would say the same thing. They could always go faster. But no, Leonardo is doing awesome work. It is actually possible to go too fast, but sometimes if you... On specification standardization, if you try to standardize something before people have actually agreed what they actually really want, you can actually get a standard that goes haywire and confuses the industry for standard creation. In some ways, you're just tracking proven implementations and proven market needs. They become... proven through implementations and products, and then it becomes a time to actually standardize. You don't want to do R&D. A design by committee is horrible. It's very slow and argumentative. But refinement of an idea by multiple vendors, that's an awesome thing to do in a committee because you get multiple perspectives and you come up with a much stronger standard foundation that can be the foundation for a whole industry. So there's something like a lot of standards that you're working on. There's vision, all kinds of camera stuff. So this sounds like a little bit like the Google self-driving car stuff or some other things that go in cameras. People can read about it online and learn more. Yeah, on kernel.org, information about everything is there. And again, we're not trying to make self-driving cars, but the self-driving car is going to need a thousand standards. Everything from wireless to camera and processing standards. Cronos can contribute a small part of that galaxy of standards. We can contribute to where software needs to communicate well with silicon for effective acceleration. That's where we can add value. We have the right people to create those acceleration APIs.