Live from Toronto, Canada, it's theCUBE. Covering Global Cloud in Blockchain Summit 2018. Brought to you by theCUBE. So welcome to the Global Cloud and Blockchain Summit. I'm about to hand you over to John Furrier, who is the co-founder and co-CEO of SiliconANGLE Media and executive editor at theCUBE. He's about to do a fireside chat with Alan Matthew. I'll let him introduce them to you as well. He's also involved in a major blockchain project himself, so he's gonna get into that with those guys as well. So, and tomorrow we start at nine. In the meantime, enjoy the evening, enjoy the food, enjoy the chat, and I'll let you go. Okay, hello, thank you, really appreciate it. Thanks everyone for being part of this panel, fireside chat, I wanna make it loose, but high impact for you guys, I know having some cocktails with good time. If there's any questions during the end, we're happy to pass the mic around, but we wanna have a conversation, kind of like we always do down in the lobby bar, just talking about crypto and cloud. We end up talking about cloud computing and crypto a lot because those are two areas that are kind of converging and the purpose of this event. So we really wanted to share some thoughts around those two massively growing markets. One is already growing, it's continuing to be great, the cloud and blockchain certainly is changing everything. So these are two important topics, we wanna flesh them out. Albergio is the serial entrepreneur founder of Digital Bits. He's founded companies both in cloud and blockchain, so he brings a great perspective, and Matt Rosak, leading crypto investor, entrepreneur and advocate, well known in the crypto space, going way back. I think he would give a couple of bitcoins to some very famous people early on, we'll get into that a little bit later. So guys, thanks for being part of the panel and fireside. For first question is, we know how big the money is. I mean the money in crypto is flowing around the world in cloud computing, we've seen specifically, and certainly in the coverage now with Amazon success, Amazon web services, and Microsoft and others, trillions of dollars being disrupted in the traditional kind of the enterprise and data center area, and blockchain is doing that too. So we wanna get into that. But first before we get into it, I want you guys to take a minute to explain for the folks, just to set the context, the kinds of projects you're working on now, Al, you have Digital Bits, and Matt, you're investing and you're inviting a lot of interesting token dynamics. So let's take a minute, I'll start. Thanks, John. Can everybody hear me? Okay, all right, perfect. Well, thanks for that lovely intro. Yeah, so my name is Al Bergio. I'm founded a few companies, as John mentioned. Before the cloud, there was the internet, and so it started for me in the late 90s in the e-commerce era, but more recently, I pioneered what's known as Interconnection 2.0, and I did that with a company called Console, and it was, for those that may know, PCCW, recently was acquired by PCCW, and with that, we disrupted the way networks at the core of the internet connected together. More recently, I founded the Digital Bits project, and now the Digital Bits blockchain network, and with that, you can kind of think of that as the trading and transaction layer for the points economy and other digital assets. And you can do a lot of interesting things with that, and it's really about bringing blockchain to the masses. Matt, what are you working on? So, Matthew Ozak, co-founder and chairman of Block. Block is an enterprise software company. We do two things. The premise is the tokenization of things. We think the money, identity, new layers of the internet are going to be tokenized, and so we go to market in two ways. One is through Block Enterprise, and these are all the software layers you need to connect to tokenized networks, so I think a wallet, a node, a router, et cetera. And then on Block Labs, we build and partner with some of the leading tokenized networks and applications, so we build a connective tissue, and then we actually build these new networks. I started this space as an investor over five, six years ago investing in some of the best entrepreneurs and technologists in the space, built a great network, but I love building companies, and so my co-founder and I, Jeff Garzik, built Block two and a half years ago. And then lastly, also serve as chairman of the Chamber of Digital Commerce, so if you believe in these new tokenized money layers, identity layers, et cetera, regulation comes into play, certainly today from an institutional adoption level, and so if you care about this space, you need to spend time to kind of help that dialogue improve. This technology moves way faster than folks in DC and elsewhere, so. And the project that we're working on, Silicon Angles, we've tokenized our media platform and we're opening it up to a token model and to kind of change the game, and so all three of us have projects. We want to put those in context. We build everything on Amazon web services, so we have a view of the cloud. We also cover it. The cloud computing market is booming. We see that Amazon's web services numbers continue to power the earnings for Amazon as a company, obviously Apple's trillion dollar valuation, those are clear case studies, but blockchain potentially could disrupt it all. And Al, I want to get your thoughts because even today in the news and Microsoft Azure, which is their big cloud provider, announced blockchain as a service. And folks that are in either the data center business or in cloud know the shift that's happening in the IT world, but no one's really connected the dots on where blockchain intersects and also is it an opportunity for the cloud guys and what's the landscape look like? So what's your thoughts on that and how are they connected? What does it mean? How does a cloud company maintain their relevance and competitiveness with blockchain? Well, just pointing on the fact that today we had that news with Microsoft and the Azure cloud and their support and evangelism for blockchain. You know, a company, I think it's very important that this isn't an ICO, two kids in a garage saying that they're doing something in blockchain. This is a massive multi-billion dollar company. And they, in making a decision like that, it's not trivial. It's many, many departments, a lot of resources before such a thing as an ounce. So that's a, not only is it validation, but it's a leading indicator as to this trend that this is clearly something that's important in a lot of people. If you're not paying attention, you need to be paying attention, including if you're in the cloud industry because many companies obviously do compete with Microsoft and AWS. So it may be still early, but it's not that early. It's in light of the news that we saw today. With that, I would say that a lot of parallels, I like to kind of, if I was an infrastructure provider, I'd look at this from the standpoint of the emergence of Linux when it first came on the scene. What was important for companies like Red Hat to be successful, they had competition at the time. And you had shortages of Linux, let's say engineers and what have you. And so a company like Red Hat built a business around that. And they did that by, and how they kind of surfaced and validated themselves to the enterprise of that era was partnering with hardware companies. So it was Intel, IBM, and then Dell, HP, and they all followed. And then all of a sudden, which version of Linux you wanna use, it's Red Hat and who you're paying for that support, you're paying Red Hat. And then they had their hockey stick moment. Today, it's not about hardware companies per se, it's about the cloud, right? So the cloud is the new hardware per se and many enterprises obviously are looking at cloud computing companies and cloud computing providers, infrastructure providers as the company that they need to support them with the infrastructure that they use. Sorry, the technologies that they use, right? Because they're not necessarily supporting these things and making sure that they're always on within the basement of that enterprise, they're depending, they're outsourcing to depending on these managed IT providers. And so it's very important that whatever technologies they're using in the lab that ultimately their infrastructure partners are able to support the implementation, the integration, the ongoing support of these technologies. So if you think of blockchain like an operating system or a database technology or whatever you wanna call it, it's important that you're able to really identify these key trends and be able to support your customer and what they're gonna need. And ultimately for them, they can't have a clog in their digital supply chain, right? And so it's clearly emerging, Microsoft is validating that today, clearly they have the data that they're seeing from their existing enterprise customers and they don't wanna lose them. But I remember when Cloud came out, you and I have talked about this before many times, Al, that it wasn't easy to use. I remember when Amazon Web Services came out, they, it was just basically, it was hard to, you know, command line, basically you had to use it. So it became easier now, it's so easy and consumable. Blockchain, similar growing pains, but we don't wanna judge it too early with the opportunity that it has. It's gonna get easier in your thoughts. And that's the scale as well by the way Amazon had large scale. So Blockchain has to scale and be easier, your thoughts. Another kind of way to think of it is to not necessarily think of cloud computing, but the evolution of the internet went, you know, in internet 1.0, we went through this dial-up modem era, things are very raw back then. Great visions we had in the future. Like it's gonna be amazing for video one day, but, you know, not during the dial-up modem era. And it eventually, it eventually happened. And user interface has improved and tool sets improved and so forth. Fast forward to today, we have all of that innovation to leverage. So things will move a lot faster with Blockchain. It did start very raw, but it's moving much faster than anything we've seen definitely in the 90s and in the last decade. So that's just, you know, it's a matter of moments, not years. And I think Al brings up a great point on leverage because Amazon has leveraged its infrastructure to a point where it's larger than Google, Azure, and IBM's public cloud combined. And so you got massive leverage there. And so when these big cloud providers provide this Blockchain as a service, it is instrumented and built on top of their existing infrastructure, not necessarily on Blockchain infrastructure. So it's an interesting dynamic where they're putting it on top of existing infrastructure that's there. But what's being built right now is a decentralized Amazon web services. So you have every layer of Amazon being reimagined, and incentivized. So you have distributed compute, and access, and storage, and database. And so what will be interesting to see is that given this massive opportunity, will Amazon and some of these other incumbent cloud providers become the provisioning networks of the future of all this new decentralized resources that get, you know, again, if you want storage, you have to start having smarts to say if I'm gonna go to C or Filecoin or Genaro or StoreJ, compute, et cetera. You have to start being a provisioning layer on top of that to kind of, you know, make that Blockchain essentially work. So it'll be interesting to see the transition because today the lightweight version is to say, yeah, I have a Blockchain as a service strategy, and that's like, well done, and check the box. Now the question is how far in this new world will they go down, and as it gets more decentralized, as universities and governments, corporations, plug their access utility into these networks to see how that changes. That is much bigger than the Amazon of today. I think that's an interesting point. I wanna just drill down on that, if you don't mind, because I think that's a fundamental observation that every layer is gonna be decentralized. The questions I think I'm asking, I'm seeing is, what hasn't all worked together? And then what's the priorities? And the old model was easy. Gotta get the infrastructure, gotta get the servers, and you work your way up to the top of the stack. What cloud brings also is that a software developer could whip up an application, maybe a D app on a test network, and go viral, and next thing you know, they have a great opportunity, and then they gotta build down. So the question is, what are you seeing in terms of priorities on stacks, portions of the stack that are being decentralized and tokenized? You see it patterns, trend, and as an investor, is there a hotter area than others? How do you look at that? Well, I think it's in motion right now. Like I said, every layer of AWS is getting thought through on how to create these digital cooperators. I have access storage. I'm gonna contribute it to this network, and I'm gonna get paid in tokens when a user uses that storage network and pays for it in those native tokens. And so that, coupled with all the other layers, is happening from a user perspective, we may not want to be going to pick a database provider, a storage, a compute, et cetera. We're likely going to say, I want a provisioning layer and provision this and execute this, much like if we, you know, there'll be new provisioning layers for moving money. I don't care if it routes through Lightning or Litecoin or Doge or whatever, as long as the value gets across the pond or the app gets provisioned appropriately based on time, security and cost and whatever other tendons are important, then that's all I care about. But given the depth and the market for all that, I think it'll be interesting to see how these are developed with the provisioning layers. And I would think Amazon or Azure, the future of that is more provisioning than actually going and doing all that at the end of the day. That's great. I want to get your thoughts, guys, on innovation. My good friend Andy Kessler would have opted in today's Wall Street Journal around an article around the US government getting involved in this Twitter, Facebook, the big platforms in terms of how they're handling their media. But it brings up a good point that with more regulation, there's less innovation. You mentioned some things outside the United States. This is a global cloud. Clouds operate globally with regions. It's a global fabric. Startups are really hot in this area. So how do you view the ecosystem of startups in terms of being innovative, the things happening that you think that are good and things that aren't good? I see regulation. I'm not a big fan of the government getting involved in managing startup ecosystems. But blockchain has a lot of alpha entrepreneurs jumping in. You look at all the top ventures, the legit ventures. They're all alpha entrepreneurs, multi-time serial entrepreneurs. They see the opportunity and they go for it. Is the startup environment good? Is there enough innovation opportunities here? Your thoughts on the opportunity to be innovative? Yeah, Al and I were just talking about this before the panel here. And we're talking about our travels in Asia. And when we go there, it is 10, 100 acts of energy and get-it factor and capital and the markets are just wildly more vibrant than going to some of the typical pockets here in San Fran and New York, it's in North America. And so it's interesting to see that when you heat map the world, what's really happening. People are always saying, oh, this FinTech or InsureTech or whatever tech is going to make a dent in Silicon Valley or Wall Street. This technology, this new frontier is definitely going to do that. I think some of that will get put into more focus based on regulation and there's two things that will happen. There's obviously a lot of whipper snapper countries that are promoting a safe place to innovate with crypto. I think Malta, Gibraltar, Barbados, et cetera. And there will be- You're just getting into the mix now. Yeah, I mean, so there'll be no shortage of that. And so, and obviously this ecosystem outpaces the pace of regulation. And then we'll see like the US doing something or other fast followers to try and catch up and say, hey, we're gonna do the cryptocurrency act of 2022. Binders get free power, tax-free crypto trading, just to try and play catch up because it's kind of hard in the last year or 18 months of seeing this ecosystem go from this groundswell to this now institutional discussion and how do you back end the banking, the custody, all these form factors that are still relatively absent. And so, we're right in the middle of it. It's a whole new way. You gotta follow the money, right, Al? You know, I talked about this. Capital markets, entrepreneurs need to raise money and that's a good thing. You need to get capital to do stuff. Yeah, this is a new phenomenon that the world has never experienced before. It's awesomeness when it comes to capital formation. And without capital formation, there is no innovation, right? So, the fact that more capital could be raised, it's the ultimate crowd sourcing. In such an efficient period of time, capital being able, the ability to track capital from various different corners of the world and deploy that capital to try to fuel innovation, of course, not all startups would have you succeed, but that was true yesterday, right? And 90% of startups fail, but they all were given some meaningful amounts of checks and people were employed and innovation was tried. And every once in a while, something emerges that's amazing. If you can do that faster, right? We have the opportunity to produce more and more innovation. And of course, with something so new as cryptocurrencies and things like ICOs and what have you, people may kind of refer to it as the Wild West. It's not, it's an evolution. And you have- It's still the Wild West, but you gotta- Well, it is, but we're getting better at it, right? As a world, this isn't the Silicon Valley community getting better at venture capital or some other part of the United States or Canada getting better at venture capital. This is the world as a whole getting better at capital formation. Yeah, that's a great point. A new way of capital formation. I want to just get an observation on that. I moved to Silicon Valley 20 years ago and I love it there for venture capital and doing startups is the best place in the world. And I've seen people try to replicate Silicon Valley. We're the Silicon Valley of Canada. We're the Silicon Valley of the East or Europe. And it's always been hard to replicate because it was a venture model. And you needed venture capitalists, you needed money, you needed community, the culture of failure and starting over and just getting back on the horse kind of thing. Crypto is the first time that I've seen the replica of that Silicon Valley dynamic in a new way because the money's flowing and there's community involved in crypto. Crypto has a big community aspect to it. You guys see that as well. I mean, I'm seeing outside the United States a lot of activity. Is that something that you're seeing? The first time we saw, well, last time we saw everybody trying to replicate Silicon Valley was the first internet. There was Silicon Swamp, there was Silicon Alley, there was Silicon This, and every city was a Silicon version of something. And then the capital evaporated. We had a mass correction happen. What wasn't being disrupted was value exchange. And so this has been created now. It is now possible for this to happen. And it's happening. We're seeing amazing things as Matt said in Asia. It's a truly awesome force. If anybody has an opportunity to go, they should go. It's unbelievable to experience it and it really opens your eyes. Matt, you've lived through a lot of investments during those dot-com days and through history now. You've seen a lot of different things. Your observations of the current state of the capital formation, startup landscapes, the global ecosystem around crypto and how it's different from say venture or classic rolling up companies and those kinds of things. Yeah, you hear a lot of this. It were in a bubble, speculative, et cetera. And I think when you look back at history of infrastructure, whether it's railroads, telephony, internet, and now crypto and blockchain, it's interesting, like if you said it would take this amount of money to innovate and come out the other end of the internet with this kind of infrastructure, with these kind of applications, with these kinds of lessons learned, nobody would sign up for that number, right? It needs this fear and greed and all the effervescence of markets to kind of come out the other end and have innovation. I think we're going through a very similar dynamic here with crypto and blockchain where everything's getting tokenized, everything's getting decentralized. Although we're talking about fundamental things like money. It's not like we're talking about pet food and women's shoes and airline tickets. We are talking about money, identity, things that will enable like other curves to really come into focus like internet of things and the kind of compounding of intersections if when some of these things get right is pretty extraordinary. And so, but I like what Al said in terms of capital formation and that friction to get from idea to capital to building, it's getting compressed. Yes, there will be edge cases of people taking advantage of that, but at the other end of this flow will be some amazing innovation. What do you guys think about the, if you had to be pushed to one answer the question with one answer of what is the high order bit of why blockchain is so important? I mean, for me, I see it from my standpoint, I'll just start. I see it making inefficient things more efficient for any use case that's being reimagined, which is everything from IOT or whatever. Efficiency is a big thing, at least I see that. What do you guys see as a high order bit in terms of the one thing that you say blockchain really impacts the world in terms of impact, financial, et cetera? Well, I think with decentralization and all these things that we're seeing it's kind of even the playing field. It's allowing for participation where parts of the world were unable to participate. I mean, it's doing a whole lot of things in that area. And that's truly awesome to really grow the economy, grow the global market and the number of participants in that market in all areas. I mean, that's the ultimate trend of what's happening here. Yeah, you're up for an agent. Absolutely. I think there's two things. There's this blockchain dialogue and then there's this crypto decentralization, tokenization dialogue. And on the blockchain side, you have lots of companies engaging in a blockchain and trying to figure out how it applies to their business and hear everything from McKinsey and Goldman saying financial services will save $100 billion in operating expenses by applying blockchain technology. And that's great. That is probably low in terms of what they'll save. It to me is just not the point of the technology. I think that when you kind of distill that down to say, hey, for a group of folks to use this technology as a shared services thing to lower OPEX at trading and settlement and decrease that, that is great. That is a step stone to creating these tokenized economies, these digital cooperatives. Meaning you contribute something and then you get something back and it's measured in the value of this token. It's like a barometric kind of value of how healthy that ecosystem is. And so regulated public enterprises and you see consortiums around insurance and financial services and banking, that is all fantastic and that gets them in the pool, gets them exercising on what blockchain is, what it is and how they apply it. But at the end of the day for them it's cost reduction. The minute there's growth or IP or disruption on table, they're all going back to their boardrooms to say, hey, let's do this, this or that. But if there's a way, my favorite class in college was industrial organization. Sounds weird, but it was. To kind of told you how to dissect an industry, what makes them competitive, who the market leaders are and then if you overlay blockchain networks with tokens, with incentives, interesting things could happen, right? And so that future is gonna be really interesting to see how market leaders think about how to tokenize their network, how to say, no, I don't wanna own this whole industrial network, I have to engage with some other participants and make sure everybody is incentivized to climb on board. So that I think is going to be more of the interesting part than just blockchainifying a workflow. Let's just quickly drill down on that. Token economics, what you're getting to, so let's assume blockchain just happens, is evolution of technology, just assume for a second it's gonna happen in a big way, is private, public, hybrid chains, what all that good stuff happening. But the token economics is where the business value starts to be extracted. So the question for you is how do you describe that to someone, how to look for, what are the key elements of token economics, when does it matter, when is it in play, and how should they be thinking about it? Yeah, I mean, token economic design and getting a flywheel going to create a network and network effects is really important. You could have great technology, but Al could be a better marketer and he gets tokens adopted better and his network will do better because he was better able to get people to adopt and market a particular layer application. And so it's really important to think about how you get that flywheel going, how you get that kindling going on a particularly new ecosystem and get users adoption and growth. That is really hard to do these days because some people don't even know what Bitcoin is, let alone to say I'm gonna tokenize this layer and every time you contribute, every time you take an action, you're gonna get rewarded for it and you're gonna share in the value of this network. Can you give a good example of what's happened today? You can point to it, that's a great example of token economics. Well, you see, I mean, the most basic one is shared file storage, right? You know, it's like the FileQuency genero model where you contribute the unused storage in your laptop or your university data center or corporate data center and you say I'm gonna contribute this and when it's used, I get these tokens and at the end of the day or week or year you see what these tokens are worth and was that worth your contribution and so as these markets develop and as utility develops, we'll see what that holds. Al, you got an example you can share? Yeah, digital bits is a good use case, actually.  This is one that Matt will know very well, definitely better than I, but the simpler something is, the easier it is for people to understand and it's like, oh, that makes sense. Binance is one that's very simple. It's a payment token. If you pay with some other currency, you pay price X if you pay in the next few years with their token, you'll get the service at a discount and in addition to that, they're using percentage of profits. I think it's every quarter to buy back up to ultimately up to 50% of token's are in circulation. So it's driving value and driving return in essence to if I can use that word. So for a user, it's simple to understand for someone that likes to speculate, it's easy for someone to understand in terms of how the whole model works, right? So it's not some insanely complicated mathematical equation that we can, yes, we can trust the math. And so in some cases, some adoption is gonna just be adopt, you know, will attract participants based on simplicity. In other cases, the math is important and people will care about that. So, you know, not all things are necessarily equal and not necessarily one method is right, but there are some simple examples out there that have proven to be successful. That's awesome. One last question before we open it up, if anyone has any questions, if anyone has any questions, they wanna come up, grab the microphone and ask three of us for anything on your mind. While you're thinking about that, I'll get the final question for these guys is, a lot of people ask me, hey, I wanna be in the right side of history. What side of the street should I be on when the reality comes down that decentralization, blockchain, token economics, decentralized applications becomes the norm and that reimagining actually happens. I don't wanna be on the wrong side of history. What should I be doing? How should I be thinking differently? Who should I be following? What should I be paying attention to? How do you answer that question?  It's the best advice I could give to buy some crypto. Once you kinda have crypto on your phone and your wallet, something changes in your brain. I think you just feel like- You share the prices every day. Yeah, yeah, you lose a lot of sleep. And then after that, you know, I think you start engaging in this space in a very different way. So I think starting small, starting basic is an important tenant. And then what's amazing about this space is it attracts the best and brightest out of industry and law and government and technology and you name it. And I'm always fascinated with the people that show up and they're like, yeah, I've been a 20-year veteran in this space and I wanna get into blockchain. It just attracts some of the best and brightest. And I think we're gonna see a lot of experience coming into the space. This has been a, you know, what I'd say, a bottoms-up groundswell of crypto and blockchain and the evolution of the space. And I think we're starting to see more, some more mature folks come into the space to add some history and perspective and be helping to build out of this and the build out of these networks. I think the kind of intersection of both is gonna be very healthy for the space. Al, your thoughts? I definitely agree with Matt, you know, definitely to lock yourself up and just try to absorb information. You have, everyone has access to the internet. There's plenty of information. If you don't like to read, go watch a few YouTube videos and just people explaining this stuff. It's really fascinating. There's various different use cases and so forth. You definitely have to buy some. And, you know, whether it's $5 worth, just go through the whole experience of being able to trade something of value that, you know, a few years ago didn't exist and to be able to trade it for something else of value is a pretty phenomenal experience. Then try to go buy something with it. It's even more of a fascinating experience that you just bought something that used, again, something that didn't exist a few years ago. But what I would add to that as well, it's you really have to get out there.  And so coming to conferences, obviously, a future conference can be a lot of interesting, great people and that consistent experience, you'll learn something every time.  And we had first movers, we had the willing followers and then the unwilling followed. You don't want to end up being- The unwilling followers. Yeah, the unwilling, yeah. All right, does anyone have any questions that I'd like to ask? Okay, come on up. We're recording, so I want to get it on film. So I have two questions. The first one is for you, Al. Two years ago, I interviewed with IIX before it was console and I want to know why you didn't hire me. No, I'm kidding, that's a joke. Actually, I thought each of you brought up some good points minus you, Al. But I'm just kidding. But what I really wanted to ask you guys is, so you talk a lot about the tokenized economy and kind of the roadmap and the things to get there. You talk about settlement layer, right? Fiat to crypto settlement layer, your identity protocols, your dApps, XYZ, right? The whole Web 3.0 stack, I want each of you, or I want at least input from both of you, or all of you, what are the hurdles to getting to a full adoption of a Web 3.0 stack and make a bold prediction on the timing before we have a full Web 3.0 stack that we use every day? That is a awesome question, actually. Timelines, being in technology, being an adventurer, you could be right and you could be off by three, five, seven, 10 years and be so wrong, right? And then at your retirement dinner, you could say, hey, I was right, but timing wasn't great. So this is really hard technology in terms of building systems that are distributed, creating the economic models, the incentive models. It takes a lot to go right and the intersection of all this. But it's not a question of like, is this happening? No, this is happening. This is like, it's in motion. The timelines are gonna be a little lucid. I'm way more pragmatic. I was one of the early guys in the early internet and everything was gonna be dot com and awesome and fantastic and but the timelines were a little lucid then, right? It's like, when was... People were thinking of today's Amazon was gonna be the 2005 Amazon. It's like, that took about another decade to kind of get there, right? And people could easily just buy stuff and a drone or a UPS guy would just deliver it. And so similar things apply today and at the same time, we all have a super computer in our pocket and so it's a lot different. At the same time, we're dealing with trusted mediums, right? The medium of money, the medium of identity, the all these different things. There are things that if I say, hey, download Instagram and let's share cat pictures or whatever, it's not a big deal. Our trust is really low for that. Let's do it. For money, it's a different mental state. It's a different dynamic, especially if you're an individual, a government or an enterprise, you go through a whole different adoption curve on that. So it is at grand scale, it is five to 10 years, right? In any meaningful way. And so we still have a lot of work to do. My answer to that question is a good one because your question was a good one. My answer is a little bit weird because it's multi-generational. The first generational pivot was when the internet was born, it was because of standards, right? The government had investments. The OSI model, Open Systems Interconnect, actually never happened, the seven layers didn't get standardized. Only the few key ones did. That created a lot of great things. And then when the web came out, that was very interesting protocol development there, the TCPIP stuff, I mean HTTP stuff. I don't see the standardization happening because cloud flipped the stack model upside down because Amazon, these guys, let the software developers drive the value. It used to be the infrastructure drove the value of what software could do. Then software became so proliferated that that drove the value of the infrastructure. So the whole cloud computing equation is making the infrastructure programmable for the first time, not the other way around. So the cloud phenomenon is all about software driving the value and that's happening. So it's interesting because with blockchain you can almost do levels of services in a cloud-like way with crypto, I mean with blockchain and token economics and have a partial stack. So I think that this whole web 3.0 might be something that no one's ever seen before. So that's kind of my answer. I don't really know if that's gonna be right or not, but just looking at the future connecting the dots is probably not gonna look like what we've seen before. And the clouds and indicators is probably gonna be some weird looking stack where certain sections are working and then evolution might fill in the other one. So I mean, that's my take. But standards will play a role. Someone, the communities will have to get involved around certain things. And I think that that's a timeless concept. And what's the timing? Oh, timing. I think it's gonna be pretty quick. I think if you look at the years it took for internet and then the web, everything's being compressed down. So I think it's gonna be much shorter if it was 20 year cycle in the past that gets shortened down to 15 with the internet and then this could be five years. So five to 10 years, that could be the impact in my mind. I mean, the question that I always ask is, what year will banks no longer be involved in anything? Is that 20 years or 10 years? Exactly, so follow the money. So I would say that in terms of trying to keep your finger on the pulse with things and how you kind of things, see things evolve, things are definitely moving a lot faster. In the past, you would probably say seven to 10. I'm not sure if I would say five, sorry, five to 10. It definitely feels to me that it's five max so we can start to see some of these key things that fall into place. So. What was the first question? Why did you hire me? Oh, no, no, no, no. We've mapped it for? Sorry. I have a question, this is Dave Vellante, co-host of theCUBE. And I want to pick up on something John, you just said and Matt, you were talking about Goldman Sachs and Morgan Stanley, it's not about them saving hundreds of millions of dollars, it's really about them transforming businesses. So, and John, you just asked the question about banks. I want to actually get your answer to this. Will traditional banks in your opinion lose control of payment systems? Notwithstanding your bias. Yeah, I am definitely biased on this. But I mean, I've been in front of the C-suite of banks, credit card companies, et cetera. And I said, in about a decade, the center of what you do and how you make money is going to be zero. And because there will be networks and ways to transmit money that'll be by far cheaper or will be subsidized by other networks, meaning, and those networks are Apple, Amazon, Alibaba, Tencent, whatever networks that are out there that are engaging in collaboration and commerce and everything else, they will give away payments as just a courtesy, like people give away messaging or email or something, as a courtesy to that network and will harden that network and it'll be built and based on blockchain technology and cryptocurrencies, so they don't have to necessarily worry about how to kind of settle payments. But these new networks will start to encroach on banks. The banks are not worried about other banks today. The banks should be worried about these new networks that are being developed. How many people still have a home phone line? Yeah. That was elegant, Alibaba. I mean, there's a generation of people that still like going to banks. They'll keep them in business for a while. But I think that comes to an end. I mean, I think that when we covered a lot of the big data market when it started, the argument was mobile will kill the banks' outlets. And now with ATMs, there's more banking branches than ever before. So I think the service piece is interesting. And also, if you look at even the cloud basis, software-to-service SaaS space a decade, decade and a half ago, you would ask SAP, Oracle, what have you, what's your cloud strategy? And they'd be like, cloud, that's just more efficient delivery model, not interested. 90-some billion dollars of M&A later, SAP, Oracle, et cetera, are cloud companies, right? And so if banks kind of get into that same mode to say, well, yeah, we need to play catch-up and buy digital currency exchanges and multi-currency wallets and some of this infrastructure and plumbing to be relevant in the next world, that would be interesting. But I think technology companies have as much an advantage to do that as financial services companies. So it'd be interesting to see who kind of goes into that, it goes into the crypto ecosystem to make that their own. It's interesting that I was, we were talking before we came on, and the OSS market operational support systems is booming and that's traditionally been these big operational outsourced companies would manage big projects. But if you look at in the first half of 2018, it's been a 20 million, greater than 20 billion dollar commercial exits of companies through private equity emergency networks, IPOs around OSS. And that's where we see operational things happening. CoreOS, Al fresco, MuleSoft, Pivotal, and Public, Magneto, GitHub, TreasureData, Fastly Elastic Data Stacks, they're all in the pipeline. These are all companies that aren't cloud. They're like running stuff in cloud. So this could be a tell sign that potentially the blockchain operating market is gonna be potentially a big one. Yeah, and then even look at Bitmain, the world's largest miner in crypto. So they did it about a billion dollars in profit last year, they did about a billion dollars in profit just in the first quarter going public, just raised a billion dollars last month at a reportedly 50 to 70 billion dollar valuation in Hong Kong in the next month. And the amount of money they'll raise will eclipse what Facebook raised. And so I think the institutional, the hardware, the cloud computing, the whole ecosystem starts to resonate and think about this space a lot differently. And we need these milestones. We need these, whether they're role models or data points to kind of like think about how this is gonna affect your business and what you do tomorrow morning. Any more questions from the crowd audience? Okay, great. Well, thanks for attending. Appreciate you guys watching and listening. And guys, thanks for the conversation, cloud and blockchain convergence collision course or is it gonna happen nicely, Al? What do you... I think it's gonna be a convergence. I don't see it necessary as a collision course. And a lot of money to be made on this opportunity these days than cloud convergence with blockchain. Yeah, no, I concur with Al. I think there's gonna be convergence. I think as the most smarter players will engage and figure out their models in this new crypto and tokenized era. Thanks so much, guys. Appreciate it. Give you guys a round of applause. Thank you very much. Thank you.


Hello, Fosnum. I'm Dmitry Malyshev. I'm a graphics engineer at Mozilla, and I'm going to dive into the history of WebGPU with you, fortunately, and if you survive, I'm going to show you how we use Rust in it. So there's also quite a bit of bright colors here. Beware, you have a history of epilepsy or something. So this is a fairly long agenda. I hope we are going to get at least 2.4 here. The most interesting stuff is at 0.5. So we'll try to keep the pace. This is the screenshot from Red Hat Redemption, and what I want is for us to be able to write code, graphics code, which would produce a similar picture on all platforms including the web. Today is not impossible at all. If you use a commercial engine like the one that Rockstar uses, then you may be able to reach consoles and some of the desktop platforms, not all of them, and you will not reach the web by that. So this is a very, very unreachable goal today, and this is what we are trying to fix in the WebGPU working group. The API that is today that is portable is OpenGL. Unfortunately, OpenGL is dying, and every vendor tries to implement their Vulkan drivers in such a way that OpenGL is just an afterthought, and nobody optimizes for OpenGL, and it has very many limitations that I try to express. The only good thing about OpenGL is that you can target the web with it today, with some limited subset of it. Many concepts of OpenGL survived through the beginning, and they are very far from either the way hardware works or the way we think about graphics programming. So it's not a protocol for us graphics engineers to talk to the modern hardware today. Microsoft is not officially supporting OpenGL, and it's forbidden in the Universal Windows platform. WebGL actually works via D3D11 on the most popular platform and Apple officially deprecated it. So you can make conclusions from here. This is a more technical slide. We can't use multiple cores. We can't predict where the driver is going to try to freeze us for hundreds of milliseconds. Optimizing for mobile is a challenge. Data transfers is an art, and WebGL 2 is not even portably supported. OpenGL evolved in such a way that allows you to skip it and do more on the GPU, and that path that does not allow rich roles like the one that I showed you in the beginning where there is like thousands of small objects with different materials. This is just not acceptable. So the first question, has anyone heard the fact that Apple started WebGPU? Yes, two people. Great. This is not correct. It couldn't be further from truth. The only thing that Apple started with WebGPU is the name which the group took from Apple. So this is how it started. Summer's 16, Vancouver. We gathered around the browser vendors, Intel, a few more folks, and we didn't know what we were doing. We were trying to figure out, is there a way to design an API that wouldn't be as complex as Vulkan while still be portable and maybe target the web? Because WebGL is technically a Kronos project, and OpenGL and Vulkan are both Kronos projects. So this was in the Kronos meeting, and browser vendors came with their own proposals on what this is going to look like. We, Mozilla, brought something called Web Metal. It worked on top of Vulkan. Apple brought something that's worked very similarly like Metal, and they quickly implemented it in Safari Preview. Now all of that code that they prototyped is gone. Our code was implemented on top of Servo and it's also gone. Google brought something original that they called NXT, and there were some heated discussions on where do we go from there. The main conclusion was, we couldn't work with Kronos because reasons. Those are something that we cannot explain. So Apple created a W3C group and invited pretty much the same people as have been working on that. So we moved to the group and started debating basic principles of how API should be designed. In 2017, we agreed on the binding model, which is critical for us because we didn't want to agree on the shading language and having the binding model allows us to decide that later or never, I don't know. Maybe even next week, we'll see. So in 2018, we agreed on implicit barriers, which is important for setting the direction of how the API, how simple this is going to be used. Because Vulkan and D3D12 require you to explicitly transition your resources between states and synchronize between pipeline stages. In 2018, we started Rust project called WGPU, which implements WebGPU for native platforms. In 19 a year from there, we started integrating it into Gecko and use it as the basis for WebGPU implementation in Gecko. Gecko is the engine for Firefox in case. I haven't seen that. The basic principle is we try to intersect the APIs and see which parts are portable, which parts can be executed on all of them. In the end, we converged to basically metal with Vulkan binding model. But again, this was not coming from a single API. This was coming from outside and trying to find the sweet spot. You know the comic about the 15th standard? That was the main feedback we got from developers. Please don't do any more APIs. We're, there's too many. Sorry, we did. And it is going to happen and we believe in it and we believe that that new API is actually needed because it's going to be the new era OpenGL sort of thing. It's going to be something that you would be able to target all of the platforms with not much effort, which you can explain to your kids and they can understand your code. So today, as I said, only OpenGL is close to that, but it's dying. So that's what WebGPU is trying to be. Principles we followed for designing it. Obviously, performance, everybody says performance. Nobody knows how to judge it between the others. So security means that we validate all the inputs. We don't allow anything to come to the driver that the driver doesn't know what to do with. So in case of Vulkan validation, we require the workloads to reach the driver with zero validation warnings or errors. It also means that we need to sanitize the shader, without bound access and lots of things, which may potentially make your programs slower, but we're trying our best to reduce this overhead to the minimum. Importability is the most tricky part. At least it took me a while, maybe a few years to understand what this means. So this means that programs are not only compiled in old platforms, they behave similarly. Like if you have a use case and your API tells you that there is an optimization for your use case, then you can expect that it's not gonna be slower on some platform because of that optimization. So this is not the case for any other APIs. Any other APIs require you to discover the features on the platform you are running on and use those features. So we expose features in such a way that if it matches your use case and you use it, we can guarantee that it's gonna be not slower or likely faster. And obviously we want it to be usable as a side. We want it to be a teachable API. We want people to understand what they write. These are early native benchmarks of the Aquarium demo. Many people may have seen it in WebGL world. Done by Intel. Not very convincing, but it's basically 10 to 30%. It's very early. Benchmarking is one of the areas where we are lacking and we're gonna catch up to that. So the other numbers Apple gave us are more convincing but I don't know if we can seriously take them. You can see like sometimes performance on number of triangles. And I'm not sure why number of triangles would be different because it's anyway reaching the GPU and GPU is gonna do this, the work but that's the numbers they have. Now we're gonna go through a example of arrest program in written against WGPU-arrest, explaining what this means and how it works. So this is initialization. Which means we create an adapter and we create a device. An adapter represents sort of a physical instance of your hardware, you can say. And the device is a logical instance that you work with that owns all the resources. So we can say we want no power preference and we want any kind of backend which the backend can be D3D12, Vulkan or not all. And we request the device with some features and we get the device. These operations are in the API they are asynchronous. In our wrapper so far they are synchronous, we're gonna change that. Now the swap chain installation is completely separate from the device. This is for any of you who only know OpenGL can be weird because you don't have to have a swap chain. You can do compute only workloads without even caring about presenting anything. So this is optional. If you need to present something you create your swap chain based on the surface that you get from the window. We create the data and the important bit here for buffer creation we specify what this buffer is gonna use it to, in which case the vertex means it's gonna be used as a vertex output buffer. And this is a descriptor of the vertex data that we're gonna use later on. Know that the descriptor is separated from the actual data. In OpenGL where you provide those layouts you provide the pointer to the data which doesn't make sense for the hardware. Explicit APIs is a long topic but I guess by this point you realize that the answer is no, like all the headlines. This is an example in Vulkan in order to create an image you have to go through four steps or five. You figure out what the requirements are, you create logical image, you find your memory pools, allocate memory and then bind them to image. So there's a lot of going on and this is not something simple. People make mistakes all the time in that. And in WebGPU is just one command. Of course, by hiding this we introduce some level of uncertainty. Maybe you will not have enough memory and we will have to allocate more. This is the balance that we've reached so far. And this is a highly subjective scale that will allow you to reason about what WebGPU is and why we are doing this. The most performant versus the ease of use API is Vulkan. It's close to the hardware, it's not exactly hardware. And OpenGL is sort of neither, it's easy but it's not performant. Bentle is pretty good, it's both. And I can talk more about metal after the talk. And WebGPU is sort of trying to get the best of the world here. So we're separating data from the layout of the data. And this is the bind groups. Bind groups is sort of a descriptor set in Vulkan or a range of descriptors in D3D12 which has a number of resources that you bind at once. That's why it bound as a group. And we create a bind group by providing the exact buffer that we just created. And this is the explanation of why we need the bind groups. The shaders communicate with bind groups at the bottom. They get input from the vertex buffers at the left and they render to render targets at the top. Now we're gonna talk about pipelines. Why do we need pipelines? If you ask, if you were used OpenGL only, historically the graphics hardware was just having fixed function pipeline. It knew how to shade simply some triangles. And then some of the stages became more programmable then they became even more programmable and then they became united into compute stages and then more and more fixed function stages that were left. Internally, the driver started to convert to code and link to the whole shader stages that they have. So when you switch your blend mode in OpenGL, this is not a simple switch. The driver may need to internally rebuild your complete program, reallocate registers and do crazy amount of work just to let your next throw call to pass. So the pipeline is a concept that gets the shader with all the dependent structures that it needs to work with and forces you to declare them in advance. So when you create the pipeline, you expect it to be slow and you have to specify what your vertex buffer layout is but not the data, what your render target format is but not the data. And again, what your bind group layouts is. Finally, the vertex buffer thing is something that we consider to not have. Try to imagine yourself programming model without vertex buffers. Maybe you will have to. I don't know. The problem is that it's very difficult to make them secure. Out of bound access is not covered by out of bound extensions for vertex buffers and it's complex. So we're still trying to figure this out. We will try to keep them. This is how we create pipeline. As I said, we have to specify all of the state that your shader depends on, which is the your render target information, vertex buffer information, your shaders and pipeline layout, which includes all the resources that your shader sees based on the stages. So you declare all of that at once. Again, this is Rust code. It uses enums. It uses references. For me, it's pretty readable to work with. Now we have rendering has rendered passes, which means that you don't just bind a target and draw render passes are needed because mobile devices where there is fast memory and they don't want to work with the whole screen at once. Loading pixels into this fast on chip memory is heavy. It's slow processing them is cheaper. And so, typically it would go tile by tile and it would load all the pixels that you have in the target. It would run your shaders on it and then it would store them back into the tile. Loading and storing is memory intensive operation that is very slow. And therefore, you can control it. You can say, don't load anything for me. Don't store anything for me. Just clear it to this color, which means you're saving a lot of memory bandwidth. This is a thing that is acknowledged by all of the native APIs today. It was from the beginning in both Vulkan and Metal and lately it will be added to D312. The latest version also has render passes. And you can see here how we are creating a render pass and we're specifying the load operation to be clear, which means we don't want to be loaded. We just want the clear. We specify the clear color. Inside the render pass we do all the rendering and we set all the state, which is the pipeline, the bind group, index vertex buffers and issuing the draw call. The beauty of this setup is that by the time we call draw indexed, all the state that it depends on is already set. Draw index is blazingly fast. There is nothing that's going on in the draw index other than maybe some vertex buffer validation that I mentioned. And you are supposed to be able to issue tens of thousands of draw calls in big, fat render passes. This is the goal that would allow us to produce those shiny pictures. See that multithreading is something that all of the new APIs support. In this example, there is three threads involved. On the first thread we record this big render pass that we just talked about. On the second thread we record some compute work and at this stage where we compute it, we don't know when exactly it's gonna be executed. We just tell it what to do. But then we send it to the thread that owns the queue and we say submit first and then second. This is where the order is set up. So all of these can be on separate threads. This is especially important again on mobile devices where we have lots of threads but maybe not so powerful threads. This is how it's done in code. You create an encoder, the encoder can then have some compute or render passes. You finish encoder, you get the command buffer which you can send to the queue or just provide to the queue directly and submission is getting an array of them. Implicit Bediars is something I mentioned as well. So here you can see that we have four different pieces in the command stream and the usage of texture and the buffer changes between the operations. Some of the usages can be combined. These are really only usages like in this 3D12. Mutable usages cannot be combined if you try to combine them within a render pass which is the synchronization scope for us. We will trigger an error and you will not have what you need. WSL, is that our shading language? I mentioned that we haven't figured out yet. No, it's not. It's just a proposal from Apple. Mostly we're discussing whether we can accept it or not. We don't have shading languages I mentioned. We don't support multiple queues which would be important for a sync compute which you kinda can do already but multiple queues make it nicer. And our data transfers between CPU and GPU are not optimal yet. It's hard to figure those out in terms of the security, not allowing CPU and GPU to race to change and inspect the data because this racing introduces non-portable behavior, potentially unsecured behavior. This is the main question. You think it's only for the web? Who thinks it's only for the web? Nobody. Great, because that's the main point of confusion I've seen. Every person that has heard of WebGPU says, oh, it's another web thing. I'm not gonna touch it. Okay, so the working group is designing it for the web. But what we realized, as in Mozilla and Google at least, is that it's a very good API for native platforms as well. As I mentioned, the new kind of OpenGL thing. So we are working on shared headers, the C headers, that you will be able to link to so that you can use interchangeably either our implementation or Google's implementation on native platforms. In fact, people have already shipped applications on App Store using our implementation on native only without any web stuff. So, oh, this is supposed to be demo time. Oh, oh, oh.  Okay, here. So this is G-Rating Meetmaps where I will explain why it's complex later. This is some two shadows. You can see some validation errors which were discovered to be validation error, validation layer bugs, which is fun. And this is, I wonder if it's, oh, it's loaded on my machine. Great, how do I show it to you? Yeah. Oh, great. It didn't go well. Okay. So this is like 10,000 objects with some ray tracing and a lot of other good stuff and physics and it's all running on Vulkan on my machine. It's equally well running on D312 and Metal. Thank you. Now I hit something that I wasn't supposed to. If you don't know what GFX is, I encourage you to rewind back time two years before where on this track, me and Marcos from GFX R&S team were describing what this is on a very similar slide. So one problem that we had with GFX that is solved here is that if your rendering depends on the backend and we use genetics for the backend, then it becomes contagious and you have to have all of your game depending on the backend type, which is very inconvenient and you can switch back ends at runtime if you want to. What we came up with is a macro. So there is a EC function and we expose the C API that guess the ID, figures out what the backend it needs and just checks the backend in a match and calls the appropriate genetic function device create buffer here. So this is what we use internally. This is just a means. For your perspective, nothing is genetic. You just work with web, you don't even know what backend it is until you ask. So it will choose one that works best for you automatically. This is what ID looks like. You can see the last three bits is the backend. In the middle there is epoch so that we can reuse indices in case your resources perish and we need to recreate them. And those tables of actual data that we have, they are backend specific. So we have a table of buffers for Vulkan table of buffers for metal and so forth. Usage tracker helps us to figure out how resources transition from one usage to another. In this scheme we came up with this that each tracker knows about correspondence to indices to states and the state is again a map of sub-resources to usage. And why do we need sub-resources? Sub-resource, a texture can have many MIPMAP levels. Each MIPMAP level can have many layers. Each of those can have its own states. If we go deeper, depth and stencil in some variations of APIs can also have different states. That's the third dimension. This sounds trivial but it's fairly complex to implement. At least Google hasn't yet and we have. And that's why I mentioned that MIPMAP generation is sort of hard because you change the usage and one MIPMAP does not equal to the usage of another MIPMAP when you generate it. So this is how we define the scopes. The errors I inserted is where we try to insert synchronization in the command stream. And the interesting bit here is that render pass is a whole scope, copy operation is a single scope but confused pass is not a whole scope. And that matches behavior by default in metal and it's really tricky because we are trying to minimize the risk of races and what we do, we synchronize between dispatches if there is the same resource used as a storage, for example. And you can use resources for different usages within a pass but you can argue that within a single dispatch call there may be multiple races on the GPU and we don't protect you from that. So there's always this scale of where to draw the line and in this particular case we decided to draw it between dispatches. We may introduce an option to have compute pass as a single scope. It's not a big deal for us but it affects you. So that's how it looks today. And when we patch between those scopes we know where each scope expects the usage to be and that's the expected value and we patch between those between those. So the bind group and render pass usages are all combined, they can be mutated inside and the command buffer and device usages are transitioned one from another. So this is a different logic and what we were trying very hard to express is using the Rust type system, right? Between this is different logic. Why don't you use genetics, you ask. So we had three attempts to implement it using genetics and you can get it to work but it's not looking pretty at all. So what we ended up doing, this slide should not be here. I think I explained it before about NeapMaps. So what we end up with is just runtime thing. As you can see the initial state is an option which means if you want to transition it to a different one we remember what the initial state was and you may wonder why it's so simple what are you showing me here? As I mentioned there was like multiple tries to use Rust type system. They ended up being very complex, hardly maintainable code. So this solution is super simple. It's straightforward, everybody can see what it's doing. It's more generic. It's an example of how solving a more generic problem gives you a simpler solution and I think it's a good example of that. We track resources for the user. So user has one link to a resource, device has one link to a resource and then everything else like commands and bind groups have different links. Once those other links including the user one go away and device is the sole owner of the resource, we figure out what was the last submission the resource was used and we associate it with the submission. Then periodically we check the submission to see oh is it done yet? And if it's done then that's the time where we actually release the resource and try to recycle its memory. This is all done automatically for you. This is the structure of WGPU. Many ways here, I'm trying to explain the main ones. So the one that we have now is the only one going from WGPU-RS which is our Rust wrapper to the native which is a C implementation or C API implementation that goes into core which goes into GFX. What we will have is that WGPU-RS will call websites and will allow you to target the web directly without going through M-scripten or anything. Alternatively, you can use M-scripten to target the web or you can use the shared path between the WGPU-native and Dawn because they share the same C headers and you can run on top of Google's implementation. In AMS are beautiful, I think everybody understands that and they work very well for us. Render pass resources, the problem we have is that within a pass we don't want to reference resources but the API requires us to hold them alive and that's tricky because we don't want that overhead. As I said, you can have 10,000 draw calls in the same render pass. We don't want for each draw call try to lock those resources and keep them alive. So we enforce the lifetimes. They give it to us or at least for us for free but you pay for the headache because you're gonna use that and lifetimes is not something that people love to see errors about but actually it's fairly straightforward. So what we ended up with is a system where Rust allows us to express those optimization guarantees with you and if you need them to be held, you do it on your side. Typically you don't, so you don't pay anything for that. Command encoders are, they have special marker that does not let them to be moved or synced automatically because send and sync are auto trades. So this prevents those auto trades and this allows us to enforce the guarantee that when you're encoding, you're not moving between threads or you're not doing it unsynchronized. We use a lot of borrowing and the pretty thing is that when we generate the C header, we can still use extern C functions with borrowing. It translates to a pointer but not slices, just regular things. This is one of the most complex bits we have. So as I mentioned, our low level structures are placed in arrays and we lock those arrays in order to access them. And you can imagine a case where the locks go in the wrong order, that did happen. So we ended up with type level lock order protection which is here the talk and I try to highlight including the one that failed to highlight. These are all different types as in they depend on the different genetic and that genetic changes, it shows the code what is accessible to lock. So if you're trying to lock something weird, your code will not compile. If your code compiles, it doesn't have phrase conditions and deadlocks. We use parking lot which was mentioned already, great stuff, various arrays, C bind gen that I mentioned. For example, we use winnit and of course we based on GFX and a bit of Frendy, just the descriptor and memory stuff of Frendy. As I mentioned, you can have externity function with the borrowed pointer but you can't have slices and that's very annoying. We have a lot of slices and always converting between slices and pointers is not pretty. So I would love that to be better. And the one lesson that I want to tell you as like Rust community is that we concluded that genetics are not always good. Maybe it's obvious for you, we used a ton of genetics in GFX and on WebGP we're trying to minimize that. Genetics slow down the compilation time and they limit the user quite a bit. They make it difficult to work with the code. So we're trying to do less of them. So I mentioned we are gonna target WebCs directly. That's one of the things. Error handling is bare bones. We have asserts somewhere results but all of that is gonna be replaced by the proper error model in the API which is the internal nullability. Which means if you're trying to do something illegal to an object like you created a buffer with the wrong descriptor then it may be internally invalid. You can ask it whether it's valid or not but you might as well just continue your recording and pretend that it's valid only to discover it later. And the reason it's done is because we can't give it to you synchronously and we can't let you block.  On our side we're not gonna do any invalid work of course. If we see during command buffer encoding that used in valid buffer your cool command buffer becomes invalid. We very much would like to target OpenGL as well. It's technically a target for us but it's rough. We don't recommend people to use it. We don't even expose it via the Rust wrapper yet. So more work coming. There is a summer of code project that is related to that. So maybe in half a year the situation is gonna be better. Ideally we would target WebGL 2.0 by WebGPU which is gonna be fun as well. These are some links of the projects. At the top there is a spec repo. I'm one of the editors for the spec and there is a WebGPU headers at the bottom and there is our previous talk about GFX at the bottom. So now we have time. We're gonna talk about browsers. This is how GACO is structured today. You can see it in Nightly. We have a small crate which is called WGPU remote which allows you to record passes and create IDs and allow the content process to manage IDs and passes and the GPU process to actually execute them. So this is a fairly simple structure but the point is WebGPU is used across multiple processes. This is an example of how it's done. So the client creates an ID. It sends it to both JavaScript and the server and the server will only after wise actually create the buffer. Render pass recording as I mentioned is completely on the client side. So while you create your render pass it's super lightweight. It doesn't take anything. We use Peakpoke serialization library. I know everybody uses Serdei so Peakpoke is a kind of dark horse alternative. It's not recommended to be used. It's only used by WebRender today and WebGPU. We'll try to make it more accessible. It's just slightly faster. And then when render pass is done we send the whole thing via shared memory to GPU process which actually executes commands. There is a lot going on here that you don't see. Imagine that the barrier between processes involves a code generation change in C++. The barrier between JavaScript involves a code generation phase in JavaScript bindings and between each of those there is a C to Rust boundary. So we cross like four different boundaries across this stack. It's fairly annoying and we're trying to get it better. This is subjective measure of completeness between browsers. Chromium is fairly good.  We just got the compute working. You can get the nightly, go to the Prefs enable WebGPU and run the compute example that Chrome does. We will work on presentation and rendering next. And Servo is also catching up. For Servo, catching up is fairly simple because it's pure Rust. You don't have as many barriers that I mentioned but it's using the same infrastructure. It's using WGPU. And I'd like to thank some people, my GFX team, WGPU community, Josh especially, and Karensin from Google for helping out on the spec and with the slides. So that's it. I think we've even finished early. You mentioned that you don't have any final proposal for shading languages. So what are the proposals, the most possible ones, that you use instead and which models, which proposals are for shading languages? The question is what are the proposals for shading languages? So we are considering three different things. WSL is what Apple is proposing and it was originally called by two different names. I think they call it whistle now. It was based on WGLSL originally. Now it's something not original. Oh, now it's something original. And the other alternative is PRV. The problem with PRV is basically the same problem as why we are not doing it in Kronos. So because it's a Kronos thing and we are concerned about fork in PRV and whether it's gonna, we will be able to like synchronize with the main development of PRV, how our interests are gonna be represented and so forth. And we are exploring something that would be like PRV or it's semantically close to PRV, but it's gonna be textual so that you can see the text but you can do a single pass and convert it to or from PRV which may be the compromise that we are looking for. Yes? I guess if I was seeing a bungee or something and thinking about writing the kind of thing at the beginning, like destiny or something where you've got multiple passes to do all your lighting but I'm gonna ask you where the diff sets are. The metal doesn't allow you to do the different sets right which Vulcan does and that's one of the key performance things for generating your next frame, your pipeline and you don't have any of those. Sorry, is your question about descriptor sets? Yeah, but the diff, you know when you can take the diff sets so you can just say which state has changed and what hasn't and then you can update that without having to sync the whole thing. Metal doesn't have that, metal too doesn't have that but Vulcan does and yes. Oh, your question is about the diff sets for the pipeline? Yeah, yeah, exactly. Oh, no, we don't have the diff sets. I think that's a very, very like low level thing that is not exactly, we would need to go through the process of doing the benchmarks and seeing what platforms is effect, how we can port it to other platforms and we have much more bigger things on the table now than this one but yes, we kind of keep that in mind. The API is not finished, it's working progress still. The later this year we are hoping to get the minimal viable product of the API that people can try and is implemented in three browsers or maybe four with servo. So we're still working on that. Is there any interest in standardizing texture formats? We are gonna have a list of supported formats but all of the compressed ones are going to be extensions because they're not supported on any particular on all the platforms and we are interested. We are going to be looking at more elaborate texture formats as a follow up. What would be the alternative API for providing versus data? So we have the shader sees resources in bind groups and you can technically just bind your buffers inside some bind groups and read them directly which is no worse. In fact, we did some benchmarking and on many platforms this is what the drivers actually do. So we don't see any performance penalty but on some very few especially older platforms which still have some fixed function hardware this is slightly slower. And the main problem is that it's just inconvenient. Nobody is used to that workflow that you don't have third six buffers. The GLSL for WebGL 2 is much simpler than probably whatever we're going to make for WebGL 2 and the compilation performance is still absolutely terrible and usable pretty much. How do you, I mean I talk to people from Chrome and Apple and they are promise is going to be solved but do you think it's real progress being mad? Because I know you have a lot of validation for the compilation but do you think there's new discoveries or ways of how to actually implement that because that's in my opinion the biggest linear on doing something quite large on the web. So that's my question. Okay so the first note was about the number of bind groups and we have the limit structure that you have from the adapter and you can see that the adapter supports more and you can request more. So you can design your application so that it's not gonna run on mobile if you want to. But if you go by default you only get four bind groups. For another question was how do we handle slow pipeline creation performance because of the shader building and because of the fact that we need to transform the shaders to do bounce checking and a lot of other safety transformations. So our measurements so far show that at least in case of SPRV the time spent on doing the transformation passes on our side even converting from a whistle to SPRV is negligible compared to the time that the driver spends that building the actual microcode for our shader. So measures that we are gonna take internally like aggressive use of pipeline caches and that stuff. But the other thing from the API side we will have it asynchronous. So you request the pipeline to be created but you don't get it right away. You get a notification where you can use the pipeline. I don't think there is much we can do besides that like once we pass the SPRV or MSL to the driver there is nothing we can do. But we have very good relationships with vendors from Kronos. So we are gonna be talking to them as well. Thank you very much. Let's see.


Item Number- SCP-4089 Object Class- Keter Special Containment Procedures Foundation operatives active in both para-dentistry and anomalous multi-level marketing communities are to suppress knowledge of SCP-4089. A Foundation-operated bot, codename IOUs, is to monitor internet traffic for markers associated with SCP-4089. The task force MOU-4, codename D-Buggers, is to expunge all digital media, including forum posts, essays, and instructional videos that reference as its existence. Description SCP-4089 is an investment strategy in which the extraction and consumption of teeth produces increased returns on certain stock portfolios. Although the precise mechanism by which investments profit from this appears coincidental, analysis correlates each tooth consumed with an approximate value of $250 USD, $350 USD in the case of deciduous teeth. SCP-4089 has several secondary anomalous effects, the most prominent of which is the rapid emergence of secondary and tertiary teeth. New teeth may vary from their predecessors in position, shape, or number. Codename-4089-1 Podcast Audio Log Date July 17, 2017 Note Excerpt from a podcast Kai Sanchez, Positively Rich The podcast host Kai Sanchez is a leading figure within anomalous multi-level marketing and investment communities. He is currently under Foundation surveillance. His guest is Lucien Marchand, an investment broker from Philadelphia. And you rich people cringe when you talk about this, tell people about this. Oh yeah, when you- Yeah, yeah, I get that a lot. My friends are always telling me, don't tell them that, don't let them know, keep them poor! Ha ha, because this is the thing Kai. This is what the richest people don't want you to know. The poor will always be among us. But so long as you stay hungry, you won't be among them. As long as you're hungry, you'll think. Yeah, yeah, that's really it isn't it? I think it's amazing how many folks just don't know about this. All you need are some ordinary tools you can get at any hardware store. And the right investment plan. We've got a kit you can purchase it on our website. Has all the tools you need. Link will be in the description folks, tell them Kai sent you. The kit includes a packet of pure ocean sea salt, my own choice blend. Once you're done, mix it with a little mineral water, gargle and spit. It helps the blood clots settle, gives them a chance to develop, and they grow right back.  Hell, I've lost cavities. At this rate, you'll put dentistry out of business. We just might. Now your site includes a kit for kids. Well it's... And some people, some people get a little squeamish about that. It's more for the parents than the kids. We don't, we're not saying you should push your kids into this. It's just that, you know, when you're that young, they're coming out anyway. Oh right, yeah. And I mean, this is the real world, you know.  Kids need to learn that. They'll grow back. There's topical anesthetic in the kit. We even offer different flavors. Cherry, grape, whatever. Right, yeah. And it's a good way to get them involved. Help them learn how the world works. Teach them, teach them the right values. Yeah, but look, I understand some people aren't willing to. This isn't for everyone. Some people, it's so easy though. Yeah, but some people can't do it. Some people, they just don't have what it takes, you know. And those people, I mean, maybe that's just how they are. It's a self-fulfilling prophecy.  It's genetic. That's so hard for people to understand. Yeah, and that's a shame, but you know, we'll always need people to clean the toilets. For the rest of us, for the entrepreneurs, for those who stay hungry, you just gotta be willing to pull some teeth. 35-year-old retail clerk and practitioner of SCP-4089 was brought to Our Lady of Peace Hospital in Birmingham, North Carolina. He expired shortly after his arrival. Doctors discovered the presence of several genetically exogenous teratomas. These tumors were chimeric and included partial reconstructions of complex human tissue, most notably of the mouth, jaw, and brain. The tumors had consumed adjacent tissue, including other tumors, which was then replicated and integrated into their own internal structure. Each tumor operated independently, at least one persisted for some time once removed. In the ensuing Foundation investigation, Timothy Baker, Mr. Baker's 7-year-old son, and Amanda Baker, Mr. Baker's wife, were found to have similar but less developed tumors. These were removed and destroyed without incident. Incident 4089-538 Date February 4th, 2019 At approximately 3 p.m., Lucien Marchand was involved in a fatal car crash while driving on his private track outside of Philadelphia, Pennsylvania. Foundation investigator seized his remains for examination. The ensuing autopsy discovered no tumors. An examination of his teeth and dental records found that, since 1985, Mr. Marchand has worn dentures.