Play episode

#104: Neil Trevett on the Khronos Group & the new Vulkan Standard for Next-Generation Graphics, OpenCL 2.1 & SPIR-V

March 12, 2015by kentbye

Neil_TrevettThe Khronos Group is an open standards organization for compute, graphics and media, and they provide interoperability APIs to enable the portability of hardware. Neil Trevett is the President of the Khronos Group, and he talks about the three main announcements that were made at GDC including:

Neil talks about how SPIR-V is used by both Open CL 2.1 and by Vulkan, and he explains more about what SPIR-V enables.

VR requires a lot of different pieces of hardware and software to come together. Khronos Group brings 120 companies together ranging form Google, Intel, Oculus VR, Nvidia and AMD. They’re taking feedback from VR display vendors in order to drive more pixels and optimize the graphics pipeline to be performant enough for VR.

He explains the tension between platforms and interoperability of the hardware and software vendors. This helps the ecosystem to evolve, and he talks about the importance of standards that come from the Khronos Group. Neil sees that VR is still very much in that chaos phase of experimentation for creating the most compelling VR experiences. Then once it’s clear the direction of the industry is moving, then standards start to play a bigger role.

Open standards like Vulkan usually work best when they have proprietary competitors like DirectX 12. He talks about the advantages of having both in the ecosystem, and how that competition can drive innovation and provide choice to developers.

Microsoft recently joined the Khronos Group, and they joined for the WebGL working group, and the Khronos Group invites a lot of different companies to participate.

The WebVR standard currently lives between the World Wide Consortium (W3C) and the Khronos Group. WebGL ended up being governed by the Khronos Group instead of the W3C because it’s more tightly tied to the GPU, and all of the hardware stakeholders were already a part of the Khronos Group.

Khronos Group has interoperability APIs to enable portability of hardware, and they’ve started to implement conformance tests that are a part of the Vulkan standard to ensure that their properly implemented by each vendor.

One of the myths about standards body is that standards bodies move too slowly, but Neil says that it’s more about the time to ecosystem of a solution being implemented by multiple vendors. He also reassures members of the Khronos Group that your intellectual property is protected. Part of being a part of the Khronos Group is that members agree to not sue each other for proper implementations of Vulkan.

The Khronos Group is involved with helping to reducing latency in drivers, and they’ll be taking a lot of feedback from the VR community over the next couple of years to take those suggestions and integrate those into the APIs.

Finally, Neil sees that the future of VR will be driven by applications that help companies save or make more money. He sees that it’s an exciting time for the technology, and that VR will continue to push innovation throughout the graphics hardware industry.

Below are some of the presentations that the Khronos Group and various members gave during GDC.

Press Release: Khronos Reveals Vulkan API for High-efficiency Graphics and Compute on GPUs

Slides of Valve’s GDC 2015 talk “Vulkan: The Future of High-Performance Graphics”

Vulkan and SPIR-V session

OpenCL 2.1 Technical Overview Session

Here are the slides that Neil Trevett presented about the Khronos Group at the Immersive Technology Alliance Press Conference at GDC:

Theme music: “Fatality” by Tigoolio

Subscribe to the Voices of VR podcast.

Share this
FacebookXRedditEmail

Rough Transcript

[00:00:05.452] Kent Bye: The Voices of VR Podcast.

[00:00:12.136] Neil Trevett: My name is Neil Trevitz. My day job is at NVIDIA. I work in the Tegra mobile group, so we're bringing cool apps onto mobile devices, but I'm also serving as the president of the Kronos Group. The Kronos Group is an open standards organization, and open in this sense means a couple things. It means that any company is welcome to join to help the work that we do, And open also means we create open, royalty-free standards for connecting applications, such as VR applications, to cool silicon acceleration. Things like graphics, things like compute, sensor processing, vision processing, all these things that are very directly relevant to the VR community.

[00:00:54.980] Kent Bye: Great. And so what were some of the announcements that were made this week at GDC?

[00:00:58.898] Neil Trevett: So we've had a busy GDC and it's actually gone pretty well. We've had three main announcements. Probably the one that's getting most attention is a new API we're calling Vulkan and people are kind of caring about Vulkan quite a lot because it's the new generation OpenGL. We announced that kind of next generation OpenGL initiative back at SIGGRAPH. but here at GDC we've been able to disclose a lot more details, a lot of directional guidance to the developer community here at Game Developer Conference as to the direction that Vulkan is going. We've had some really positive feedback on it. We had two other actually pretty significant announcements too. The Kronos Group has done OpenGL for many years, G for graphics, but we also do OpenCL, C for compute. And OpenCL is a parallel heterogeneous programming framework. So if you have multi-core CPUs or lots of GPUs, DSPs, other kinds of processors, you can use OpenCL to program it. And we announced a new version, which is OpenCL 2.1. And the headline there is that OpenCL now lets you use C++ rather than just C for writing your kernel code that you can distribute across all these different processors. And then last but not least, actually in some ways I think it's actually the most fundamental announcement from a programming language ecosystem perspective was a new version of our standard portable intermediate representation. Sounds very wonky. It's called Spear, S-P-E-A-R, and we have a new version of Spear in the Spear family called Spear V, and this is an intermediate representation, so it's a low-level representation of shader programs for graphics and kernel programs for compute, and it lets you have many different languages targeting Spear, and then you can run that Spear code on many different pieces of hardware. So it's actually a very powerful, though geeky, standard to let developers write programs in a powerful, flexible way and have it run across many different vendors' hardware. So it's actually pretty fundamental.

[00:03:02.203] Kent Bye: Yeah, you mentioned that it's the most significant. So what is that enabling you to do that you were not able to do before then? And why do you think it's so significant?

[00:03:09.675] Neil Trevett: So Sphere is actually being used by both OpenCL 2.1 and Vulkan, so the three announcements, it's in the middle, it connects the two. And so, for example, in the older generation of APIs, OpenGL, that many people know and love in the VR community, The driver had to accept the source code of your shader programs, and OpenGL uses a language called GLSL, OpenGL Shading Language, which is like a C-like language. So the driver has to accept that source code, compile it, whilst the application is running. and then execute it. Now, with Vulkan, we have the opportunity to use SPIR-V. So the driver becomes a lot simpler because SPIR-V is a much lower level language. It's intended as a compiler target and as an ingestion format. So the driver suddenly, we don't need to have a whole front end of a C or C++. compiler. You just bring in Spear code, execute it. It's lots of advantages for developers. They don't have to ship the source of their shaders, which has been a big issue in the past, because often there's a lot of intellectual property in shaders in many cases, and they don't have to do that anymore. They can even use a constant front-end across different hardware vendors, so things run a lot more reliably. So Vulkan is taking advantage of Spear in quite a big way.

[00:04:28.674] Kent Bye: And so how do you see some of these sort of infrastructure, open standard type of cooperation and collaboration amongst all these different companies and organization and hardware and software vendors, with that collaboration with this new Vulkan announcement, how do you see that playing in and fitting into virtual reality?

[00:04:45.522] Neil Trevett: So, virtual reality is a very interesting area, as you know. Lots of different pieces need to come together and work seamlessly to create a compelling virtual reality experience. And Kronos, we're fortunate we have 120 companies. Everyone from Google and Apple and Intel all the way down to individual developers working together to solve some of these interoperability problems and some of these issues that are going to be vital for virtual reality and Oculus is a member for example and others. So, specifically, we work on the APIs to drive the graphics pipeline, and VR, I think, is going to have a fundamental effect on how we drive pixels to the screen. Low latency being the most obvious, but higher quality, faster performance. If we're going to generate compelling experiences on displays that are very high resolution, very close to our eyes, we're going to need to boost up the pixel power of these devices enormously. There's really no limit to the amount of pixel power that these virtual reality experiences are going to need. So we're going to need to be taking the feedback from the virtual reality display vendors and saying, okay, how do you want us to actually generate pixels for your display? What is the best way that we can reduce latency? What are actually the quality artifacts that are causing your users most pain and how can we best fix that? And then Khronos is the place where all of the GPU vendors, together with companies like Oculus and software developers, we can actually hammer out the solutions to those problems and just push the graphics pipeline and how GPUs are constructed and the architecture of the graphics pipeline to truly meet the needs of VR apps as opposed to just watching apps on a flat TV screen.

[00:06:36.665] Kent Bye: Yeah, in one of the slides that you had presented, you had kind of this tension between proprietary platforms versus like the open standard being able to be interoperable amongst all the different companies. You know, for example, you just make one binary, it works on all platforms and regardless of what your hardware or software is, it just works. And so that's sort of the dream and the vision. And obviously we're in a kind of a more of a fractured, you know, Mac, Windows, Linux. But you know, when you look at these types of standards, maybe we could talk a bit about like at a high level how we have this tension between platforms versus like this open standard interoperability.

[00:07:10.961] Neil Trevett: Yeah, everyone in the end, of course, is in the industry to make a profit for their shareholders. That's the fundamental drive. And everyone is always constantly and rightly searching for the right way to do that. So I think this is not talking about any particular one vendor at all. It's just a general law of the universe, is that the people that are creating platforms, they obviously want to bring value and applications in a sticky way onto their platform so they can differentiate against their competitors. But the independent vendors, I'm talking about like IHVs, independent hardware vendors, people selling GPUs or graphics boards, or ISVs, independent software vendors, people developing applications or drivers or tools, they want to be able to sell their products across the maximum number of platforms with the minimum friction, because that way they increase their market reach. And so there's a kind of a dynamic tension between the platform vendors who want things to be more proprietary and the vendors who want things to be more open and more portable. And we end up somewhere in the middle, in the Lagrange point between those two gravitational pulls. And it will swing backwards and forwards depending on the market dynamics of the day. But I think it's very interesting the way that standards in that kind of environment evolve. I mean, open standards will definitely play a key role in VR. There are so many moving pieces that need to work together. Standards is going to be the only sane way to make it all come together at some reasonable cost and in an accessible way for a mass audience. And we just need to be able to work together to create those standards, but not too soon. Personally, I think a common mistake of some standards in the past is that they try to come in too early before the industry really knows really what they want to do in a mass-market, cheap, consumer-friendly way. You need to go through a period of experimentation. I call it the chaos period, where there's a lot of Darwinian mechanics going on. People trying lots of different techniques, lots of different ways of delivering VR experiences. Some of them are going to fail. We'll find the right ways of doing things. There might be multiple ways of doing things. through that Darwinian phase and once it becomes clear and the industry kind of says okay this is the direction that the consumer wants and this is the way that's working but oh gosh we have so many vendors they can't talk to each other now it's become a real problem that these things can't talk to each other now we kind of know what we want to do and that that's the perfect time to have standards that come in and just remove those friction points that aren't adding any value anymore no one's really gaining from differentiating on those pain points, that's when we need standards. And that's, I think, when the industry accepts the needs for standards because people aren't losing their proprietary edge, they're just slowing themselves down because they're not working with the right partners in the industry. And so I think the search is on. And we're probably, in many cases, still in the chaos phase where we need to be, as people experiment without any hindrance. And then very soon, I think, some pain points. It's not just one big standard, it's going to be a constellation of small interoperability standards that make VR a reality. The search is on to say where are the pain points and who's the right standards organization that can help solve each one of these problems.

[00:10:35.736] Kent Bye: Yeah. And I think there's an interesting tension between, you know, having one small design decision making process from a proprietary company to do like something like DirectX 12 versus something that is more maybe open and designed by committee. There may be interoperability, but there may be compromises that come through that process. And so, you know, how do you see that tension between, you know, having an open standard and then with each open standard, there seems to be some sort of proprietary competitor.

[00:11:03.985] Neil Trevett: Yeah, actually, that's a really good point. In our experience, we've actually found things actually work best when an open standard has a really good, viable, proprietary competitor, too, because what tends to happen is the first platform to create a viable way of doing things on their own platform, they tend to create the de facto standard, particularly if it's a powerful platform. You mentioned DX12 on Windows, and obviously Windows is a very significant platform and DX12 is a really good API. It's going to be a really good API and it's going to be used obviously on Windows and Vulkan, you know, you can regard Vulkan in some ways as the competitor to DX12, but I think that's actually a positive dynamic. Things don't move forward. Can you tell I believe in Darwinianism? things don't move forward unless there's competition in the marketplace and now dx12 and Vulcan hopefully will have a long and happy competitive relationship that ends up being good for both of them and different developers will find different api's and different solutions that meet their particular business needs and If I was a developer just working on Windows 10, I didn't want to go anywhere else, then the advantage that DirectX 12 will have is it's tightly integrated into the platform, it's coming from the platform vendor, they can rev it how they want on their platform, and that can be a powerful thing. But for those developers where their business model means that they need to ship on a bunch of different platforms, and they want to not have to rewrite their app every time, then perhaps an open standard non-proprietary API will be a better solution for them. And it's good that both are existing in the marketplace. It's good for developers to have choice.

[00:12:41.568] Kent Bye: And so you showed a slide during your presentation that showed many dozens of different logos, over 120 different companies that are collaborating with the Khronos Group. Is Microsoft a part of the Khronos Group? Are there any other big companies that are notably absent from the Khronos Group?

[00:12:56.487] Neil Trevett: No, actually Microsoft is a member. They actually just recently joined and they're very welcome in the group. It's great to have cooperation. But each Kronos member, they don't have to participate in every working group. They can choose which of the working groups that they participate in. And Microsoft have stated publicly they're in Khronos primarily for the WebGL standard. That's the reason, at least the initial reason, that they've joined the Khronos group. And it's been great to have Internet Explorer adopt WebGL. So now we have WebGL everywhere. And actually, that's going to be significant for VR, too. Delivering VR over your browser is actually a very powerful dynamic, I think. But yes, I mean, if at some point, and I can't speak for Microsoft, I don't know what their plans are, but if at some point they want to participate in other Kronos standards, of course, they would be very welcome to.

[00:13:46.542] Kent Bye: Yeah, in talking to Brandon Jones, he's working on WebVR at Chrome, and he made the interesting commentary that, you know, there's the Khronos Group for all the sort of hardware and software vendors, and then, you know, for the web, there's the WC3 and other standards organizations that are kind of dictating how the web is being standardized and organized amongst all the many different browsers. And so WebVR is kind of caught in the middle, in some ways, between, you know, the WebGL component of it, but then, you know, all the browser components. Where would you see the most logical home for a standards body to kind of dictate the future of WebVR?

[00:14:19.208] Neil Trevett: Well, standards bodies don't dictate anything, ideally. Standards bodies are taking, are a place where the industry comes together to solve their own problems. I mean, and actually that's a very common misperception is that Chronos or W3C is some big floaty body on a cloud somewhere and they're sending down tablets of stone. It doesn't work like that. Khronos is us. Khronos is the industry. Khronos is just trying to be a place where the industry comes together in a safe place to cooperate. So that's an important point. But in terms of VR on the web, it is interesting. I mean, obviously the W3C is the primary body for web-related standards. So why did WebGL end up in the Khronos group? No, it's not a paragraph by Kronos. I think in the end, if you look at it, it's a logical place. Because WebGL is kind of interesting in a set of web standards. It's the one that's most tightly related to the GPU. It's not a typical web standard. It's much lower and exposes a lot more detail on the GPU hardware than a typical web standard like CSS. It deliberately tries to hide any details and gives you a page layout format, whereas WebGL gives you access to the GPU directly through JavaScript. But that's proven to be, I think, an interesting way to build the web ecosystem because we had some pushback at the beginning saying, you're crazy, this is not a web API, what are you guys thinking? But it's proven to be a powerful foundation if you give people access to the GPU through JavaScript at that very low level. Not many people actually use WebGL directly. Most people will use a JavaScript middleware package like 3GS. 80% of all WebGL content uses 3GS. And there's lots of other really cool JavaScript middleware. But by having that foundational layer, you're enabling a good, rich diversity ecosystem of middleware in the JavaScript language. So actually, I think it's an interesting dynamic. Perhaps some other areas in the web that are getting close to hardware might want to do something similar. But because WebGL is doing that, it is much lower and closer to the hardware, the primary challenge in defining and shipping WebGL is making sure that it actually works across all the different hardware vendors. So, you need the hardware vendors in the room. So, the best place to do that, where are all the hardware vendors sitting around the table? That's the Kronos group. So that's why I think it's ended up there.

[00:16:46.230] Kent Bye: And so if I get this correct, it sounds like, you know, the next iteration of OpenGL is called Vulkan. And then, you know, the original version of OpenGL was translated into WebGL by Vlad at Mozilla. And so now WebGL 2 is coming out. Is it true that the WebGL 2 is based on to the latest Vulkan standard then?

[00:17:07.497] Neil Trevett: Right, so it's a pipeline. And actually, at its core, WebGL is actually bringing OpenGL ES into JavaScript. WebGL 1 is essentially OpenGL ES 2. So there's the weird numbering thing going on. And there's a good reason for that, because OpenGL ES is kind of the mobile version of the larger desktop OpenGL. For WebGL to be successful, it needs to tap into functionality that is pervasive everywhere, not just on desktop systems, but also on your mobile, because WebGL runs on mobile just as importantly as the desktop. So OpenGL ES over the last 10 years has become the facto way of shipping 3D graphics on mobile and desktop. If you have the pervasive version of OpenGL ES, you know you're going to run everywhere. So when WebGL project was started, OpenGL ES 2 was the one that with version of OpenGL ES you knew was going to run everywhere. And WebGL 2 is going to take OpenGL ES 3, because OpenGL ES 3 is now the one that's becoming pervasive everywhere. So WebGL is able to lift itself up onto the shoulders of OpenGL ES 3 and deliver more functionality. So, there's a natural lag between... It is a pipeline, because Khronos creates a spec, then the hardware vendors have to implement it, then it has to get pervasively shipped into the market, then WebGL can expose it to the web community. Now, we all wish that would go as fast as we can, and we're motivated to make that pipeline as short as possible, but it is a series of steps you have to go through. There's no point in WebGL saying, oh, we can do all of this. Well, it doesn't actually run anywhere. That's not the way the web works. So Vulkan now is in many ways the successor to OpenGL, although OpenGL and OpenGL.js are going to continue to evolve as well. So I think WebGL has lots of headroom to go. Now we're beginning to expose Vulkan details. It's an interesting discussion that the industry can have. How much of Vulkan do we want to expose in WebGL? See, I don't think we'll have a web Vulcan. WebGL is in charge of its own destiny. And it can evolve with the functionality that it wants to meet the needs of web developers. And it can base itself over OpenGL, over DirectX, in many cases Vulcan. And we'll see how much of the Vulcan functionality is needed and is appropriate for the web. We have all the browser vendors now in the WebGL working group. They're the guys who are best able to decide. They're the ones that are talking to their developers every day.

[00:19:41.848] Kent Bye: Yeah, and I guess anybody who's been a web developer can know the pain of, you know, in the past of standards, but not all of the implementations of the standards sort of being the same. And so you get this sort of crazy like having to design to fit each of the browsers. And I think that's getting a lot better. But there's something that you had mentioned that you deliver the spec, but it's up to each vendor to kind of implement that spec. And so Why is that important in the case of the Kronos group then? Because you may get this sort of like issue where there's, you know, a lot of thrashing where there's, you have to kind of still debug things, but talk a bit about, you know, why it's important to allow them to do that. Yeah.

[00:20:16.819] Neil Trevett: So we're creating interoperability APIs for portability of applications across multiple hardware. So if we work hard at the spec, but then the implementations are all different, we've failed at the last hurdle. If the reality is that developers have to port between different versions of OpenGL, even though they're meant to be the same thing, then a lot of the reason why we exist is just evaporated. Now, of course, we're never in a perfect world. There will always be bugs and differences. But a group like Kronos, any standards organization, you have to push for reliable implementations. And one of the tools that we have, many people use it, is conformance testing. So actually the product that we produce is not just a spec in isolation like the Vulkan spec or the OpenGL spec. It's the spec plus its conformance tests. And the way the process works is that someone takes the specification and implements it. They also have to pass the conformance tests on their hardware, on their implementation. before they're allowed to use that trademark. You can't call it Vulkan or OpenGL until you've proven you've passed the conformance tests that go along with the spec. That's a really important part of the process. Without that, a spec by itself is kind of worthless because people will implement it every which way. And even if they're trying to, sometimes there's ambiguities and you need a bar that people have to cross. Now, have we always done good enough? No. Are we going to do better with Vulkan? We hope so. We're working hard with Vulkan. And one of the things that we're doing, that actually learning from WebGL. WebGL was the first of the Khronos specs to do this. We're actually going to put the conformance tests into open source. In previous generations of OpenGL and OpenGL ES, all the Khronos members were able to work on the conformance tests, but it was inside the Khronos membership only. WebGL opened their conformance tests and we got a lot of good, positive community involvement. And we've significantly increased the coverage. And people that are in the field developing applications and saying, ah, these two vendors, they never do this one thing the same. It's a pain. They can actually write, if they care enough, they can write a conformance test. And that conformance test, through the right approval, can actually get sucked into the official conformance test for that API. And so that means the vendors have to fix that problem and be conformant so they can directly influence the solution to the pain points that the developers are finding.

[00:22:57.513] Kent Bye: You had mentioned in your presentation some of the myths of standards bodies that you wanted to debunk. What were some of those common misconceptions about standards that you wanted to counter?

[00:23:07.224] Neil Trevett: The first one was that standards are way too slow. VR is interesting because everything is moving so fast. How could a standards body possibly keep up? Well, it's interesting. It's certainly possible for an individual company to write a spec and get something out there probably faster than a group of companies coming together to discuss and iterate on a spec together. But the key thing, I think, in many cases in the market is not time to a specification that people can read. It's time to an ecosystem. Time to ecosystem is the critical thing. And that means it's not just a spec. It's a spec that's implemented by multiple people reliably because we have conformance testing. and it's had lots of input from different perspectives, so it's actually genuinely meeting a problem, so it actually gets picked up and used by these multiple vendors. If you want fast time to ecosystem, a well-organized standards body I think is the best way to do it in many cases. And the other one I think we had on the slide was that if I participate in an open standard, I lose all my IP, all my intellectual property, because I'm having to give up my intellectual property and give it to a standards organization, give it to all my competitors. Why would I do that? And actually, again, in not just Kronos, any effective modern standards organization will have an IP framework in place, an intellectual property framework, which is the agreement that all of the members have signed and agreed to. So their IP is very strongly protected. But the spec is protected too. I mean, the Kronos one is very simple. I mean, it's a couple of pages, but in essence, All the members that come together to create a specification like Vulkan agree, if the other people create a conformant Vulkan implementation, they won't get sued by the other members for doing that. It's very simple. And it's a very narrow license, so all your IP for the members, it's not gone, it's still yours. You've just granted this very specific, narrow license, which is good for the industry.

[00:25:11.072] Kent Bye: And one of the things that I see in the context of virtual reality when it comes to hardware is that, you know, with the GPUs going directly to the HMD, with AMD, with the Liquid VR, and with NVIDIA, you have your own sort of VR Direct. And so, is that something that is falling within the purview of the Khronos group, you know, going direct to display, or is that something that's just separate and, you know, unique to VR?

[00:25:34.828] Neil Trevett: Yeah, that's a good question. And I think that it falls into two things, something like VR Direct. There are some categories of things that NVIDIA and AMD are doing similar things, as you say, that are just hidden beneath the drivers, like reducing latency. It turns out that we had the opportunity to reduce some latency in our standard drivers, and that will go everywhere that NVIDIA GPUs go. The application developer doesn't have to do anything. That just comes for free. That's just an internal implementation thing for NVIDIA. But it also adds a lot of value to VR. But other things will be tools for the developer to use, so turning on different quality modes. Yes, it's in the GPU, but the developer needs to have the choice on which one they want to turn on for their particular display, their particular application. And I think things like how can developers choose to generate stereo, because they want those different things you can do. The developers are going to need to have the choice and the control over things like stereo display, fast warping of displays for fast sensor input. they will need to be lifted up into an API to enable developers with that functionality because the developer needs to be consciously using it. So I think over the next year or two, I'm expecting quite a lot of kind of feedback from the VR community saying, hey, we actually need this in Vulkan and OpenGL. Let's put it in and Chronos will be a good place to do that. And Oculus are already beginning to make some of those suggestions, for example.

[00:27:05.461] Kent Bye: And finally, maybe you could comment on how you see virtual reality changing all these technological industries of kind of pushing the edge of the performance, but also what you see as kind of like the ultimate potential of where this is going and what it might be able to enable.

[00:27:21.452] Neil Trevett: Well, I think if the promise of VR is delivered, it will affect a bunch of different industries. If you can deliver presence and if you can deliver more immersiveness, then there are a bunch of different market opportunities that are going to arise and lots of existing markets are going to be fundamentally changed. Now, this is the third time I've seen VR go around, but it's interesting that there are more technological pieces in place this time. I agree with Mike Abrash. I think we can do enough now, well enough, that we're going to do something useful and we're going to be able to do something compelling and I think In many cases, though, it might be industrial uses that go first. I know we all want to be there in our living room doing it, and we will. I do believe we will. But in many cases, the industrial use case is where there's a more direct line to money. And it doesn't matter if it's kind of clunky and not quite consumer-ready yet, as long as you can save money or make more money in an industrial or enterprise. Context many cases that's where this kind of technology really gets smooth and polished until it's ready for my mom to use So no, I think VR is gonna have a fundamental impact. I think we are good enough to do some interesting things I think it's going to be enterprise use actually first and then consumer over the next few years. It's gonna come online Great.

[00:28:48.160] Kent Bye: Well, thank you so much.

[00:28:49.041] Neil Trevett: Okay. No, you're welcome. Thanks

More from this show

Menu

#104: Neil Trevett on the Khronos Group & the new Vulkan Standard for Next-Generation Graphics, OpenCL 2.1 & SPIR-V