The past year or two has marked a considerable shift in the graphics industry, one spurred on not just by faster hardware and ever demanding games, but by the evolution of two new graphics API’s: Microsoft’s DirectX 12 and Khronos Group’s Vulkan. Both API’s were created for a modern computing era, an era filled with multi-core CPU’s, ever more complex usages of GPU computing and the emergence of Virtual Reality.
Vulkan differs from Microsoft’s DirectX 12 in a number of key ways, the most obvious being Khronos Groups steadfast approach to being multi-vendor, multi-platform. Vulkan allows developers a familiar API structure whether they’re creating for a high end PC running Windows, Linux or even porting their engines to mobile platform such as Android.
We managed to snag an interview with Tom Olson (Director of Research over at ARM and chair of the Vulkan Working Group) and Neil Trevett (Vice President of Mobile Ecosystem at Nvidia and elected President of the Khronos Group). For the profiles of both Tom and Neil, check the bottom of the article!
https://www.youtube.com/watch?v=WVDYAE2puTc
Q: How did Khronos feel essentially ‘starting over’ again with Vulkan, given that the roots of OpenGL date back to 1992, it must have been an equally exciting and daunting task to bring the API into the modern era?
Tom: “The OpenGL and OpenGL ES working groups actually started talking about a new architecture back in 2012. It had become pretty obvious that GL’s legacy architecture was holding it back, and that in order to move forward, we’d have to make major changes. Yes, trying to replace such a mature API and ecosystem was scary, and it took us a while to get started. The bad experience of Longs Peak also gave us pause. But once we finally committed to the project in 2014, there wasn’t really any nostalgia for the good old days, and nobody looked back. It helped a lot that we had massive commitment and participation from the top game engine companies, who said over and over again that if we built it, they’d use it – and then jumped in to help us build it.”
Neil: “We like to joke that you should really update your API architecture every quarter century whether you need to or not In the end, the feedback from the games engine and AAA games developers grew to be very loud and clear – they needed predictable, no surprise control over GPUs. The tipping point for me personally was listening to a developer explaining how they were having to forensically reverse-engineer OpenGL drivers from multiple vendors to try and predict their built-in heuristics, in order to route around performance glitches. Life is too short for that.
There was also an interesting debate whether we should call this new API something like ‘OpenGL New Generation’ or a completely new name.
“From a marketing perspective it is scary to have to build a new brand as familiar as OpenGL. In the end I think we made the right decision to go with a new name. Vulkan takes a different philosophy to getting work into the GPU that is very enabling to many developers – but OpenGL is not going anywhere and will remain the best choice for many types of developers. It would have been confusing to call two different API approaches the same name – and Vulkan is already building good name recognition within the developer and user communities.”
Q: How do you feel Vulkan has been received by the gaming and technology industries? Is the adoption rate on track with what you’d anticipated for the various platforms (PC, mobile…)
Tom: “The rate of adoption and uptake of Vulkan has been unprecedented for a Khronos API, certainly much faster than adoption of recent versions of OpenGL and OpenGL ES. That’s partly due to hardware – core Vulkan will run on any GPU that can support OpenGL ES 3.1, so it makes fewer demands on the hardware than, say OpenGL 4.5. But it’s also partly due to demand. I think everyone recognizes that this is where the industry is going, and is working to get there as quickly as possible.”
Neil: “I agree – the rate of Vulkan adoption has been faster than any API that Khronos has ever produced. I think it speaks to the fact that the developer community were hungry for this API – and that it fills a real market need.”
Q: Now that Vulkan 1.0 has launched, what do you believe is your (Khronos Groups) proudest achievements on the API, from both a technical and logistics point of view?
Tom: “OK, that’s a tough question – where do I start?
“On the technical front, our biggest challenge was to come up with an API that preserves the close-to-the-metal, low-level, no-compromise-on-performance philosophy of AMD’s Mantle, but at the same time can be implemented efficiently on a huge variety of GPU architectures. I’m incredibly proud (and maybe a tiny bit surprised!) that we were able to pull that off. Vulkan works equally well on desktop-style immediate-mode GPUs and on the tile-based GPUs common in mobile, while OpenGL on tile-based GPUs was always kind of an awkward fit. So if you think about it, Vulkan is actually more architecture-neutral than OpenGL and OpenGL ES, despite being at a much lower level of abstraction. That’s pretty amazing.
“Another thing I’m very proud of is the way we’ve changed how we interact with the developer community. Developers tell us that historically, Khronos has seemed very opaque and mysterious – hard to talk to and hard to communicate with, unless you were a member. We’re still a membership organization, and we still develop new specs under NDA – there are good reasons for that, having to do with trying to keep our specs patent-royalty-free. But with Vulkan, all of our conformance tests, software tools, man pages, and even the specification itself are available in open source on GitHub. The software is under the Apache 2.0 license, so you can do pretty much anything you want with it. And if there’s something in the specification that isn’t clear or looks wrong, you can open an issue and ask about it. People do that every day, and we are doing our best to respond to all of them. It’s a work in progress, and we have further to go, but I’m really happy about the direction.
“I guess the thing I’m proudest of, though, is the way the whole industry worked together to make Vulkan happen. It was truly a team effort by people in all kinds of different businesses. A lot of the companies in the working group are bitter rivals in the commercial arena, and they don’t usually go out of their way to help each other out. But I think we all recognized that this project had to succeed, and that it wouldn’t succeed if it didn’t work for all of us. It had to run well on everyone’s GPU, it had to provide good support for everyone’s game engine, and it had to integrate smoothly on everyone’s platform. It took a lot of hard work, and some painful compromises, but we managed to do it. I’m incredibly proud of that.”
https://www.youtube.com/watch?v=TGZFa7A_k-Y
Neil: “Yes – I have never seen the level of energy and commitment being put into making an API successful as with Vulkan. It’s a privilege to be involved with a group of people that believe passionately in what they are trying to achieve. From an ecosystem perspective, I think it was critical that Khronos managed to create an API that met the technical and commercial needs of Google and Android – having the largest volume platform on the planet adopt Vulkan as its core GPU API will be huge factor in driving Vulkan forward.”
Q: There’s been many obvious comparisons between Vulkan and DX12, so in your own words – can you explain to our readers and viewers some of the key differences between Vulkan and Microsoft’s DirectX 12 from a developer’s point of view?
Tom: “From a technical point of view, the two APIs are pretty similar. Obviously there are fine-grained technical differences – for example, in DX12 a fair amount of state leaks across command buffer boundaries, while in Vulkan it generally doesn’t – but these aren’t fundamental architectural differences. On issues like that, we made our decisions based on what our GPU vendor members said they could implement efficiently. We took it as a key design principle, that we wouldn’t hide work inside the driver and make expensive operations look cheap.
“But the high-order bit, certainly, is that Vulkan is radically cross-platform. That’s more than just a statement about what platforms it ships on – Vulkan is designed from the ground up to run on the widest possible range of GPUs and OSes, without sacrificing performance for that flexibility. For example, it has features that exist specifically to allow Vulkan applications to run well on mobile GPUs, but those features do no harm on desktop GPUs, and in some cases they turn out to help there as well. DX12 doesn’t have that breadth, and of course it only runs on one console and one version of Windows.”
Q: Back in Siggraph 2015, Dan Ginsberg was rather famously quoted in saying ” I would argue that there is really not much reason to ever create a DX12 back end for your game”. Would you say this is still largely the case, unless you’re tied into a Microsoft ecosystem (for example, exclusively creating for Xbox)?
Tom: “Dan’s a good buddy and a key member of the Vulkan working group, so I wouldn’t dream of arguing with him . But I’m not a game developer myself, so it isn’t for me to give that kind of advice. I will say, if you care about running on the broadest range of platforms, Vulkan is the obvious place to start. And if your game runs well on Vulkan, porting to DX12 (if you need to) will be pretty easy.”
Q: In a follow up to the previous question, do you find public and developer interest of DirectX 12 hard to combat, particularly for PC gaming thanks to the massive Windows install base?
Tom: “We’re not really trying to ‘combat’ anything – we’re trying to make a great API that can run on all modern hardware and platforms. We think it’s obvious that that’s what the market needs, and that if we do a good job, people will use it. We recognize of course that it’s about more than just the API – we have to create and support a complete solution, a whole ecosystem. Hence the emphasis on defining a standard loader, validation and debug layers, a shader compiler, and other tools, all available in open source.”
Neil: “DX12 is a fine API and it will be the right commercial choice for some developers addressing a certain set of platforms. It may not be good for readership ratings to say this – but I think the ‘API wars’ are often overblown – developer choice in APIs is a good thing. Additionally, I think that over the years healthy competition between Direct3D and OpenGL has been a positive incentive for both families of APIs to improve – which ultimately is good for the developer community. But, if you look at the industry as a whole, it is a healthy thing to have the choice of a graphics API that is not being defined by a single platform vendor, as it provides an avenue for API innovation that is independent of the underlying platform dynamics of the day.”
Q: AMD’s Robert Hallock had told us in a previous interview that AMD had donated their Mantle API to Khronos to help ‘ jumpstart the process of bringing Vulkan to life’. Can you tell us how the conversation started and how Mantle helped your team kick start the project, and insight into the API evolution over time?
Tom: “Sure. The Khronos committee process is really good at rubbing the rough edges off an existing specification, but it isn’t very good at coming up with a brand-new API from scratch. That’s a major reason why our early, pre-2014 discussions went slowly. When the effort moved into high gear in 2014, we knew we needed a place to start. There were some initial conversations between AMD and ARM. A couple of weeks before our first organizational meeting (at Valve’s office in Bellevue), senior AMD technologists contacted us to explore whether Mantle could provide that starting point – basically asking if we were willing to commit to its goals and philosophy, even if we had to change a lot of mechanism. We did some all-nighters reading their spec, and in the end it was clear that it was a great fit. We voted to adopt it as our starting point at the Bellevue meeting. It was a huge boost, both technically and psychologically; we went into the meeting saying “how are we going to do this”, and came away saying “damn, this is going to work”.
Neil: “Mantle definitely got us off to a great start, but just as important is the enormous amount of effort and input from a significant number of companies in the working group to refine, and build out the final API design. In the end it really was a team effort – an API by the industry for the industry. At Khronos we try hard to avoid ‘design by committee;’ as that can be a painful way to put the essentials of a design in place – and starting with Mantle spared us that. However, ‘refinement by committee’ is a very powerful process that can bring multiple perspectives into play to make a final API design much stronger and well rounded.”
Q: Vulkan and SPIR-V seems to have been carefully crafted to allow developers to delve into creating games whether they’re going for extreme performance (direct control), choosing libraries if they want to speed up development or jump into by using an engine which natively supports it (say UE4).
Combining this with the flexibility of features such as Validation Layers, the API is extremely customizable. Can you tell us how this works for developers across different platforms and how you came to the decision this was the best option for Vulkan?
Tom: “I think this was one of the benefits of having so many key ISVs involved in the project early on. They brought with them a huge range of experience with different kinds of engines and different development styles, and they drummed into us the idea that there is no one-size-fits-all solution. You’ve got to be able to go right to the hairy edge for ultimate performance on a specific piece of hardware, but you also have to be able to write one code path that will have good performance on a wide variety of devices, and all points in between. Another point the ISVs made is that you should only have to pay for what you use. If you’ve carefully beaten all the errors out of your API calls, you don’t want the driver spending a lot of time checking for them. If your engine is already tracking dependencies in order to avoid stalls and frame hitching, you don’t want the driver doing it too.
“That was what drove the layered architecture in the beginning, but later it became part of what drove us toward a more open, community-facing ecosystem, with all of the key tools in open source as I described earlier. The ISVs made it crystal clear that if we tried to lock down the ecosystem and push developers down paths that we controlled, we would fail. The winning strategy was to empower developers, give them control, and give them the ability to configure the API and tools to fit their needs and where they are in the development process.
Neil: “I am really fascinated to see how the ecosystem of Vulkan layers, samples and tools evolves – I think there is a lot of opportunity for innovation and community involvement here.”
Q: ID Software and Nvidia used Doom running on Vulkan to show off the GTX 1080 GPU, and performance was very damn impressive. Can you provide any insight into how modern engines such as IDTech 6 and Source 2 will implement Vulkan, and if their engines were designed from the ground up to support Vulkan (and other low level APIs)?
Tom: “You should really ask the guys at id, Valve, et al, who really know the answers on that one – I have to admit that I don’t know. A number of the engine guys have obviously been working on Vulkan for a while, and were working on Mantle before that. But my guess is none of them can afford to over-optimize for a single API, and certainly not a new one that is still building market share. So they all need to be able to run well not only on Vulkan and DX12, but also DX11, OpenGL 4.x, the consoles, and maybe Metal, OpenGL ES and even DX9.
“ISVs I talk to say that if you architect for Vulkan or DX12, you’re in pretty good shape to port to the other APIs, while going the other way is a lot harder. They also say that optimizing a high-end engine for a new API architecture is a lot of work and takes time. So my guess is, the cutting-edge engines have moved quickly to exploit the opportunities Vulkan offers, have certainly picked the low-hanging fruit, but may not yet be fully optimized for it. The good news is that they’re seeing pretty good speedups already – in the case of Doom, I’ve heard talk of 30-40% faster than GL on some AMD cards – but they will probably continue to get better as Vulkan becomes widely available.
Neil: Yes, we shouldn’t forget the new generation APIs has only been shipping for a few months and so the industry is still figuring out how to optimize and use them to best effect – but the early results are encouraging. Of course the speedup from Vulkan will depend on where the bottlenecks are in a particular system, if an application is already saturating a GPU with a powerful CPU, Vulkan might not provide much advantage”
Q: Mantle, DX12 and Vulkan were created to improve graphics performance and eliminate bottlenecks (such as Draw Calls). What does Khronos feel are the next set of technical challenges for both virtual reality and general high end 2d gaming?
Tom: “Let me say first that while it’s true that improving performance and removing bottlenecks were key goals for Vulkan, improving predictability and consistency of performance was maybe even more important. That led to the design principle we had, that a Vulkan driver should do what you tell it to, when you tell it to. We called it explicit control, and it’s at the heart of the Vulkan design philosophy.
“VR raises a bunch of issues – multiple views of the same scene, low-latency rendering, precise synchronization, and so on. Multi-view is something we’re interested in adding fairly soon, and there are GL extensions for that that work pretty well. For controlling latency and so on, we think the explicit control principle gets us a long way toward what is needed – at this point we need developer experience to tell us where the API falls short. Pretty much all of the major players in VR are members, and we’re working closely with them to stay on top of that. We also welcome input from the larger community.”
Neil: “Yes VR is driving the need for high-end graphics and the predictable, low-latency nature of Vulkan makes it a natural fit for delivering the best VR experience – so we are working hard to bring a coherent set of VR functionality to Vulkan ASAP. The fact that Google’s Daydream VR within Android is using Vulkan adds additional impetus to this initiative.
“Another, major ISV request we are getting is for multi-GPU support – where OpenGL has a long history. We are working towards a multi-GPU strategy for Vulkan that fits within the explicit nature of the API.
“Lately, we are getting a lot of requests to enable HLSL shaders to be used by Vulkan; there is already a GitHub project underway for a HLSL direct to SPIR-V front-end compiler that will enable HLSL shader investment to be suddenly portable to anywhere that Vulkan is available.”
Q: Valve’s SteamOS (and several other Linux distros) have attempted to wrestle away Microsoft’s dominance of PC gaming. While many indie developers natively support Linux, AAA developers are in a bit of a chicken and egg situation with Windows massive market share. Do you believe Vulkan can help open up AAA developers to Linux gaming thanks to easier porting?
Tom: “Being strictly platform-neutral is a key part of our philosophy, so I don’t usually think about it in those terms. Vulkan isn’t meant to be pro-Linux or anti-Windows. It’s just the best 3D API we know how to make, and it’s available to be used on any platform that can support it. We think that’s good for developers, which means more and better games for consumers; and that’s good for both Linux and Windows, in fact for the whole ecosystem.”
Q: In a follow up question to the previous, can you give any insight how much work it is for a games developer to port their titles over to Vulkan if they’ve already developed their own engines which work with today’s common API’s (DirectX, PlayStation GNM…)
Tom: “I’ll refer to what I said earlier. If you do a direct line-by-line port from an old-style “safe” API (like OpenGL or DX11) to Vulkan, you basically have to replicate in your engine the dependency tracking, memory management and synchronization that the GL/DX11 driver used to do for you. That’s a lot of work, and performance will be less than optimal. If you are willing to re-architect significantly, or are creating a new engine, you can be smarter about it, because you know how the application is structured.
“You can use that knowledge to manage memory and resources in semantically related groups, rather than tracking every object and allocation individually. That’s less work for you, and will perform better as well. If you’re porting from PlayStation GNM, DX12, or any other console-style API, you’re probably already doing most of what you need to, so it’s even easier.”
Q: Low level API’s (Metal, DirectX 12 and Vulkan) appears to be much more console like in their traits: with low level GPU access, memory management and an emphasis on compute functionality. Do you believe modern games consoles have had a positive impact in how APIs and hardware were created, and how game engines function, despite the hardwares performance limitations?
Tom: “Yes, absolutely, at least in terms of getting people to think differently about the division of labor between system software (APIs and drivers) and applications. They’ve showed us that some of the conventional wisdom about how software should be organized was just wrong. Of course, there is definitely a trade-off – if you just want to get correct images on the screen, it’s easier to do it in the older APIs. The new ones are all about trading ease of programming for real-time performance.
“I suspect the pendulum has swung as far as it can in that direction, and will probably swing back a bit in the next few years. But it will do it by adding layers and convenience libraries on top of pedal-to-the-metal APIs like Vulkan, rather than by embedding more smarts in the driver – think GNMX versus GNM. And in the Vulkan universe, those layers and libraries will be open source, so developers can debug into them and tune them for their applications.”
Question: Now you’ve got Vulkan 1.0 out of the door, what types of features will you be adding for future versions of the API? Will they be performance orientated, quality of life or a mixture of both?
Tom: “Probably a mix. We’re really eager to hear from first-generation developers about what kind of experiences they are having, and we’re pretty sure they’ll tell us that we got some stuff wrong. We’ll need to fix that as best we can. Then there are the features in GL and DX that we don’t have in Vulkan 1.0, most obviously multi-GPU support – that’s a very high priority. And there are the new application spaces, like VR which you mentioned. We’ve got a substantial list and are working actively on it.”
Neil: “Also, don’t forget that Vulkan is extensible – just like OpenGL – so we have the option of delivering this functionality in between major spec updates.”
Q: With Vulkan’s huge list of supported hardware and Operating Systems, has it been difficult to maintain great performance and compatibility across the entire ecosystem without favouring one particular hardware vendor or OS?
Tom: “It’s a constant struggle, something we work on every day. So far, we’re pretty happy with how it’s turning out. But it depends on people being alert, and also willing to compromise. As I said, the cooperative spirit that we have in the group is something I’m extremely proud of.”
Q: The computing market has gone through many different ages, from the advent of fast CPUs, 3d graphics chips, unified shaders and the latest being Virtual Reality.
For VR game developers and gamer’s (both mobile and high end PC hardware), do you think Vulkan can help with reduced lag (between input and screen display), improved frame rate and an overall better VR experience?
Tom: “Short answer, yes. Vulkan’s key design principle is to do what developers ask for, when they ask for it – it’s all about predictability. That’s exactly what VR needs – even more than frame rate, it needs things to happen when they’re supposed to.”
Q: Certain tasks such as AI, Physics, collision detection and real-time lighting and shadows are extremely taxing for modern systems. Will reduced CPU overheads and multithreading and better GPU utilization lead to rapid improvements in these areas on low level APIs?
Tom: “Absolutely. Multithreading is the big win here. With 8-thread CPUs common even in mobile, the GL / DX11 limitation to a single thread was totally unacceptable. Of course, by allowing CPU multithreading, we’ve effectively changed the ratio of CPU to GPU power in the system. Vulkan makes it possible to submit a lot more work to the GPU, which may mean that we’re all going to want bigger GPUs. The next few years are going to be interesting!”
Neil: “And of course as Vulkan is a GPU API it can be used for GPU compute that can significantly offload many of these compute intensive tasks. Vulkan’s multi-queue architecture already provides enhanced compute flexibility over OpenGL and I think it will be interesting to see how the compute side of Vulkan expands to match the primarily rendering focus we have had so far. For example, we have the option to bring some OpenCL-like functionality into Vulkan – enabling graphics and compute to be used within a single runtime.
“The fact that Vulkan uses SPIR-V as the foundation for its programmability is going to give us significant kernel and shading language agility. As chair of the OpenCL working group, it’s good to see Vulkan and OpenCL working groups proactively discussing how to mix and merge the technology pieces we have at Khronos to best serve developers, and avoiding internal API turf wars.”
Q: There are a lot of key partners and contributors to Vulkan, including Nintendo and Sony – can you comment if either company are considering Vulkan as an alternative API for their systems? If they did, I imagine it would be an excellent positive for the API.
Tom: “I honestly have no idea, but of course I wouldn’t be able to say anything if I did!”
Q: It’s incredible how quickly mobile processors have evolved with performance, especially if you remember back to the early days. Vulkan is very interesting for mobile developers, can you give insight into how Vulkan will help mobile developers push the graphical envelope and any other key benefits of the API?
Tom: “Vulkan is absolutely the best thing to happen to mobile graphics since OpenGL ES! OpenGL ES enabled the mobile graphics industry by defining a standard API and a standard feature set, so that developers could write portable apps and GPU vendors could compete based on how well they ran them. But the rendering model was still immediate mode rendering (IMR), while all of the dominant mobile GPUs were tile-based (aka deferred rasterization), because of its power and bandwidth advantages. That meant that an OpenGL ES driver has to spend a lot of CPU cycles guessing what the developer intends, and doing magic behind the scenes to make a tile-based GPU look like an IMR. That’s expensive, and when the driver guesses wrong, you get frame rate hitches or just plain unpredictable performance.”
“With Vulkan, all of that goes away. A correctly written Vulkan application tells the driver exactly what it needs to know, when it needs to know it, in order to optimize for either an IMR or a tiler. Beyond that, Vulkan’s renderpass/subpass construct lets tile-based architectures avoid writing intermediate render targets to memory, saving huge amounts of bandwidth and power. The information can also help IMR GPUs make good scheduling decisions.
“If that weren’t enough, Vulkan’s relentless focus on minimizing CPU usage means that it takes less energy to keep the GPU busy doing useful work, saving battery and reducing thermal load. It’s a huge, huge win for mobile.”
Neil: “Which I think help explains why Android has adopted Vulkan. Did I mention that Android is the world’s highest volume platform – and it has adopted Vulkan?”
Q: For high end gaming on DirectX 12, we’ve seen Microsoft tout Explicit Multi Adapter, allowing multi vendor GPUs to work together in the same system. Is this to achieve in Vulkan?
Tom: “Full multi-GPU support was definitely a goal when we launched the project, and there is some support in the API, but we weren’t able to finish the job in time for the 1.0 release. In 1.0, you can query your VkInstance and find out that it supports multiple VkPhysicalDevices, e.g. GPUs, and those can come from either the same or multiple vendors. And you can then create logical devices and queues from the physical devices, and submit work to them from a single application. What you can’t do in 1.0 is share resources or synchronize directly between different devices, so the use cases are limited. Fixing that is a high priority for us.”
Q: With older API’s (such as DX11), their single threaded nature often led to CPU bound scenarios, especially in games with thousands of draw calls. Thanks to Vulkan and other low level APIs, we can start pushing more work to the GPU, which presumably leads to many more GPU scenarios. Can you provide insight to budding developers how Vulkan can help in GPU bound scenarios?
Tom: “Well, Vulkan is just software, so it doesn’t literally make your GPU faster. You do get an indirect benefit, because Vulkan frees up a lot of CPU cycles. If you notice that your CPUs are underutilized in your Vulkan port, you can use the leftover cycles to do things that reduce the GPU load – better culling for example – which may be as good as boosting GPU perf. But if you are already GPU bound in OpenGL / DX11, you probably won’t get an enormous benefit from moving to Vulkan.
“There is one way in which Vulkan can effectively make the GPU faster, and that’s the renderpass/subpass feature. If you are running on a tile-based GPU, data items that you pass from one subpass to the next can stay in the on-chip tile memory, and that can save a huge amount of bandwidth, which is often what limits performance on mobile. On an immediate mode GPU, the same information can help the scheduler order rendering operations to improve cache locality. It works great for deferred shading and some kinds of post-processing. Vulkan is the only 3D API that has this as a core feature. You can do it in OpenGL ES using the EXT_shader_pixel_local_storage extension, but you have to code a special path for it, and have a fallback path in case the extension isn’t supported.”
Massive thank you to both Tom and Neil for their time in answering our questions – below is a synopsis of their biographies and experience!
Tom Olson is Director of Graphics Research at ARM®. After a few years as a musician (which he doesn’t talk about), and a few more designing digital logic for satellites (one of which eventually actually flew), he earned a PhD and became a computer vision researcher. Around 2001 he saw the coming tidal wave of demand for graphics on mobile devices, and switched his research area to graphics. At ARM, he works on the team responsible for the ARM Mali™ GPU architecture. He chaired the Khronos OpenGL ES Working Group from 2006 to 2016, and has chaired the Vulkan Working Group since its founding.
By day, Neil Trevett works at NVIDIA where he helps to drive the developer API ecosystem that enables applications to take advantage of advanced GPU and silicon acceleration. By night, Neil is the elected President of the Khronos Group that defines open standard APIs for graphics, compute and vision acceleration. At Khronos, Neil initiated the OpenGL ES standard now used by billions worldwide every day, helped catalyze the WebGL project to bring interactive 3D graphics to the Web, chairs the OpenCL working group defining the open standard for heterogeneous parallel computation and has helped establish and launch the new generation Vulkan GPU API.
