They are, but they still need to communicate with the browser process to do privileged tasks and that code can still have errors. Also, a crash doesn't necessarily mean a vulnerability, it could be a purposeful crash due to an invariant being untrue, so Chrome will crash out of caution.
GPU processes are separated due to driver instability and unsafe code, so this means more than a GPU process crash, or a content process crash (tab crashed), something in the orchestration layer or main process crashed. There are probably massive amounts of memory being moved around which could easily be stressing the system or running into large limits. Don't think this is related to the security model or a compromise of an origin / content process.
Hi everyone, I'm one of the founders of Wonder Interactive, and we develop the SimplyStream platform. We're on a mission to bring compute-intensive games and applications to the web, and so for the past several years we've worked to port Unreal Engine to WebGPU and WebAssembly. We started supporting UE4, but quickly moved to UE5.
We also realized that there needs to be a smart way to deliver content in a performant and optimized way, so we start work on building an asset streaming system, that can load in game assets as needed. This is beneficial because you don't require the whole app binary to be download to the end user, instead they can just download a small chunk, and the rest can be streamed in the background at runtime.
We're very excited to have received an Epic Megagrant from Epic Games last year, to support our efforts.
Here's a few links you can check out to learn more:
It's neat, but I have a feeling this will result in very large downloads and long load times. Like the Unity WebGL exports of the past.
The car example https://car.tiwsamples.com/ took 120 seconds to load, making 1820 network requests, and transferred 392MB of data / 487MB decompressed.
You can deliver a significantly better user experience by building for the web directly.
There are definitely pros and cons, just like there is for using web-first 3D frameworks and engines. In terms of Unreal, asset streaming is a must and helps significantly here. Also, these demos are going to continue to be optimized for file size/load time, so you can expect speedups over what we've currently made available.
This represents a way for Unreal developers to export their authored content to the web. It is an option, but is by no means the only way to do 3D in the browser. What web native frameworks lack is the rich functionality that comes with game engines such as Unity and Unreal.
There has been a chicken and egg problem for gpu intensive media on the web. WebGL overhead limits complexity -> demanding applications remain native -> tooling for WebGL/WebGPU is limited or lags behind.
I bet these are some of the most complex WebGPU programs.
Congrats on the launch! Good luck on the optimization.
The shooter example worked great when I tried it a few months ago, and didnt take forever to load either. It really is a massive improvement over how ue4 official was handling html5 builds.
22 comments
[ 3.3 ms ] story [ 51.0 ms ] threadIn this case, Chrome is the only one that supports WebGPU, others are at very least one year away.
All of all them do WebGL though.
Needs some work still I guess, but looking forward to it.
We also realized that there needs to be a smart way to deliver content in a performant and optimized way, so we start work on building an asset streaming system, that can load in game assets as needed. This is beneficial because you don't require the whole app binary to be download to the end user, instead they can just download a small chunk, and the rest can be streamed in the background at runtime.
We're very excited to have received an Epic Megagrant from Epic Games last year, to support our efforts.
Here's a few links you can check out to learn more:
https://www.youtube.com/watch?v=TI3KVJFz2L0
https://simplystream.com/create/blog/an-update
https://www.youtube.com/watch?v=TI3KVJFz2L0
The car example https://car.tiwsamples.com/ took 120 seconds to load, making 1820 network requests, and transferred 392MB of data / 487MB decompressed.
You can deliver a significantly better user experience by building for the web directly.
This represents a way for Unreal developers to export their authored content to the web. It is an option, but is by no means the only way to do 3D in the browser. What web native frameworks lack is the rich functionality that comes with game engines such as Unity and Unreal.
I bet these are some of the most complex WebGPU programs.
Congrats on the launch! Good luck on the optimization.