how about WebGPU

It's being investigated. WebGPU is still in active development as a standard, it's implementations by browsers still in flux, so it's not something that can be released any time soon.

 

Sorry I can't give a satisfactory answer to that, it's complicated. I can say it's being investigated, and its importance is understood. And we have a close relationship with the standards committee and browser implementors to help make sure WebGPU will be as good as possible, especially for scaling up to Unity level assets and projects. It should also be known that, at least initially, there will be some things that WebGL can do that WebGPU cannot do (and vise versa, of course), due to the WebGPU API. But I can't say anything official about Unity's plans for it. Sorry.

 

WebGPU support is in active development.

 

Hi Zarod,

I'm not entirely sure what your rant is about, but I'll try to answer some of your questions / concerns.

The TLDR; is that WebGPU will not replace WebGL now or in the forceable future. Both will be supported and both have their strengths and weaknesses.

How can you say that you are rolling out this feature early " to get feedback and improve quicker", when the Android mobile platform, the only one truly in need for optimization was left out?

What do you mean Android is left out, and the only one truly in need of optimization? Both of those statements are not true, for either WebGL or WebGPU. For WebGPU, Google just released the early alpha testing release of WebGPU running on Android. Unity will support the platforms supported by WebGPU.

All other platforms can make use of much more powerful hardware and cheat by increasing power consumption.

That's always been true, for both WebGL and WebGPU. WebGPU won't magically make things faster. Developers will always be pushing the boundaries of hardware limits, and more powerful hardware and cheats will always help adjust those limits.

Plus, all the demos i hav seen show "problems" that can be solved by simple batching ... OR show scenarios that 99 percent of games won't even feature!

Again, WebGPU won't magically make things faster, and batching is always preferable for any graphics api. What WebGPU provides that WebGL does not, is compute shaders. While 99 percent of games might not care about that feature, there are internal uses in the Unity engine that will help improve performance. Animation skinning, for example, is calculated on the CPU for WebGL, and will use compute shaders to run on the GPU on WebGPU.

I can't say I'm interested in yet another framework that is "better" only by utilizing an already present and expensive hardware, instead of optimizations that increase speed and compatibily across all devices, while also reducing manifacturing costs.

That's fine, WebGL will continue to be available, supported, and improved.

Then, webgl 2.0 even in unity when you actually learn how to make it work is even more stable and rewarding than standalone, and FASTER than Playcanvas(wierd i know, but trust me it IS!!!) as you are forced to really optimize every aspect of your game, from garbage collection to shader operations to memory ... while also making development more chill and relaxed.

I'm glad you're having success with WebGL2. We work hard on it, and will continue to do so.

What is there in webgpu that forces developers to NOT be lazy?

I don't think there is anything in any of this that will force developers to be lazy. From the developer's perspective, there is little to no difference using WebGPU or WebGL. Some features in Unity that are not available on WebGL, like compute shaders, will be available with WebGPU, but there is no requirement to use it. If WebGPU is the current graphics api at runtime, some things will be able to utilize it, like animation skinning. But it will not be some new thing. It will be no difference than choosing the OpenGL ES graphics api, or the Vulkan graphics api, when building for desktop or Android.

Or at least fix enough problems automatically that the game doesn't become a memory hog running at 25 fps on a chip equivalent to a 1060 gtx?

We continue to work on the web platform with a lot of concern for memory and performance and start-up time. Developers will still have the freedom to pay attention to memory and performance of their own content, or not.

I stopped playing games for that reason

I'm sorry, games can be fun.

webgl 1, 2 and now gpu should be all maintained in my opinion.

I agree! Other than WebGL 1 is being deprecated because it really is very limited and continuing to support it means being able to support other things less, and the world is moving on to WebGL2. But in no way will we stop investing in supporting and improving WebGL, in addition to WebGPU.

The mobile market is just too diverse to start telling people "upgrade, or else" ... because that "ELSE" is quite litterally a button press and a 0.5 secons of load time away!

I agree, you can't do that, especially for the web. That's why projects can and should be developed to make use of hardware when available, and have a backup plan for low end. For example, you can check if compute shaders are available in the current runtime, and use them in the project if it's running on WebGPU, but have an alternative method if not. But Unity just provides the means for people to do that, developers still have the choice to do so or not.

Just ... keep working on that webgl2.0 support ... okey? ... pretty please?

Absolutely!

It's funny, as I see people complaining about webgl unity, while I am currently using a bugged version of the engine with a known memory leak ... but the actual build works at 30+ fps even on a huwaei from 10 years ago with no problems!

That's awesome. We'll continue working hard on the platform.

 

Hi KamilDA,

It will be implemented as a Graphics API. In the WebGL Player Settings (we really need a new name for the web player now), you'll be able to add WebGPU to the Graphics API list, and if WebGPU is available on the browser at runtime, it will be used, otherwise fall back to the other graphic api's in the list. There would be nothing "WebGPU" you would need to do in the project, but some APIs in Unity will work when WebGPU is running, that wouldn't work when WebGL is running, such as Compute Shaders. So in your Unity project, you can check "is compute shaders available", and use them if they are, which would be true for WebGPU and false for WebGL.

Our current plan is to get an early experimental version in 2023.2 (minus unforeseeable circumstances). Experimental means it will be labeled experimental, and will not be in the Auto Graphics API list, so it will need to be explicitly added to the project. It will also not be without bugs, and there will be a lot of things people will try to do, like copy projects that work on other platforms, that will not work because the WebGPU specification has more limitations than other platforms, at least initially. But things will improve over time. And running compute shaders on the web is fun!

 

You mentioned how WebGPU will enable running compute shaders. This is great and will benefit many projects. Are there other examples of 'low hanging' fruit where you see the implementation of WebGPU having a short-term impact? Without any engagement - just a wish list based on existing experimentation you've been doing?

It's hard to say. There are a number of performance issues we're still working through, with Google and the other WebGPU implementors to make sure browsers can handle data with the complexity of Unity.

For example, the quick & dirty approach to getting a WebGL project up and running is to use URP. Wouldn't WebGPU enable (in theory?) HDRP too? Or do you foresee maybe URP development be "unshackled" by WebGPU, in the mid-long term, as it possibly had been by WebGL2?

HDRP will not be supported, at least initially. It does not support mobile, and therefore uses features that are not available on WebGPU. But URP will be supported. I'm not sure what needs to be unshackled, but I know the SRP team is working on stuff to improve things.

You also mentioned that people will try to migrate projects from other platforms to WebGPU and fail. My understanding from your post is that WebGPU will be an optional "addon" (but not a replacement to be selected in the graphics API list), at least initially. Thus enabling additional rendering pipeline features that would had been disabled by default. Is the end goal to actually add it to the graphics API list and be able to do 'pure' WebGPU projects or will it be managed completely differently (forever just an add-on ?).

By "try existing projects and fail", I meant WebGPU has certain limitations that a number of existing projects will try, but won't work. Not that they would work on WebGL. Things like WebGPU does not support synchronous readback of buffers or textures. That means some projects might call something like GraphicsBuffer.ReadData, which wouldn't work. Only the AsyncGPUReadback api can be used to read buffers and textures with WebGPU. So if a project were calling ReadData, it wouldn't work.

WebGPU is an add-on in that it's a full graphics api, but with Unity you can choose which graphics api to use, and that will be one of the choices. In the same way WebGL 1 and WebGL 2 are two current choices. So it's no different than having a project with both WebGL2 and WebGL1 in the graphics api list in player settings. In that case, if WebGL2 isn't available, it falls back to WebGL1. With WebGPU, if you add WebGPU to the graphics api list in player settings, it would check if WebGPU is available, and if not fall back to WebGL.

The confusing part is that we call the web player "WebGL", which is also the name of the graphics api.

 

@KamilDA Making sure WebGPU has as little impact on build size, especially when not used in a project, is something we're paying attention to.

We're discussing the options for the web player name.

 

It is definitely a goal to get VFXGraph working with WebGPU. It may not be initially supported, because of some limitations of WebGPU, but it is a goal.

 

I just gave the update. Yes WebGPU has started, it's well under way in development and a lot is working. There are systems, like VFX Graph, that currently require things beyond what WebGPU as a standard is currently capable of, so those things are goals to find solutions for.

 

I'm frustrated by the lack of good information too, and especially the wrong answers. I'm nervous about people taking things like chat gpt for granted. A lot of times it "sounds good, it must be true", but is wrong in sometimes subtle ways. Guess we can just keep doing our best to make the web the best platform we can. If we can just keep Apple in line .

 

@KamilDA I have no idea what that is, but it sounds useful to have a web category for Package Manager.

 

Work progresses. As you would expect, it's a hugely complicated task integrating a new graphics API into Unity, especially one with subtle but profound limitations compared to other similar APIs, and one where the API itself is still a work-in-progress (WebGPU 1.0 has yet to be finalized). But it's coming along. As a teaser, here is Unity running on WebGPU...on Android! [disclaimer: this is just a test, not an announcement or promise from Unity]

 

@print_helloworld Besides the quite complex internal graphics api abstraction layer in Unity that needs to be implemented for WebGPU (and is largely working), there are a lot of graphics api specific code in places like URP and other packages that needs to be added to. The biggest hurdles is that WebGPU has a rather low end spec; it purposefully does not implement certain features (synchronous readback of textures and buffers, so synchronous read methods like Texture2D.ReadPixels don't work); and has arguably unnecessarily strict validation that breaks otherwise working shaders. The spec committee blames security necessary for the web for some of the overly strict limits and validation. Also the implementations (Chrome at the moment) are still fairly immature and have significant issues with performance for things like compiling shaders, which results in a lot of mid-game stutters. So there's a lot of work being done to try and make the out-of-box experience with WebGPU as good as it can be, and we're working very closely with the WebGPU specification committee and Google to make sure they take into account engines the size and complexity of Unity for WebGPU. The biggest pain so far is that a lot of existing projects use features that work on desktop DX/Vulkan/Metal but do not work on WebGPU because of the low end specification limits/features for WebGPU. But we're working hard to make it as fully implemented and pain free as possible, trying to work around as many of the limitations as we can.

 

Using the AsyncGPUReadback API (https://docs.unity3d.com/ScriptReference/Rendering.AsyncGPUReadback.html) will be necessary to copy texture or buffer data from the GPU to the CPU with WebGPU.

 

@atomikm The issue with DOTS/ECS/BURST on web isn't with the graphics API, it has to do with multithreading support. So unfortunately WebGPU will not affect those systems.

 

WebGPU Update: We are working as hard as we can to get an initial version of Unity WebGPU into the release branch. It will have a long list of caveats, and be far from perfect (both in terms of what we have implemented, and what Google has implemented), but I'm still excited for people to start playing with it. I can't give a time estimate because that would put too much pressure on me, but I can see the light at the end of the tunnel and really pushing to get it in a 2023.2+ release.

 

@AdamandEveStudios That's generally true of any new graphics API. What you get out of WebGPU that you can't get out of WebGL is compute shaders, which arguably can be done with vertex and fragment shaders, though often with a lot more effort and usually less performant, especially when storage buffers come into play. Currently Google is far ahead of the game with the implementation in Chrome. But Mozilla isn't too far behind, and Apple is investing a lot into it for an undetermined release date as usual. But there is definitely overhype, WebGPU will not suddenly let you create AAA games on the web, and will not automagically make everything better. In fact, initially, there will likely be less features and performance than WebGL. But in the bigger picture, WebGL is essentially dead as a standard, it's in maintenance mode and no longer updated as a spec, so WebGPU will play a very important role for graphics on the web.

 

We've been working closely with Google for quite a while now. They have been a great partner, helping work through issues with the spec, identifying areas where WebGPU will need extensions, and finding areas to improve performance. Any lack of bigger announcements is from Unity being conservative with unfinished features, which is a valid position.