URP is the pipeline for all devices but only in Forward it seems as it says this for Deferred:
What are the reasons for the shader model limitations and will it support WebGL/WebGPU in the future?
WebGPU likely because requiring Shader Model 4.5 means Compute Shaders for the most part. And WebGPU introduces Compute Shaders for web apps, WebGL doesn’t and will never support them.
The exact differences don’t really matter, suffice it to say that the requirements exist for good reason and there’s just no way to have deferred rendering for APIs that do not support the necessary features.
Whereas forward rendering is quite lean and simple and thus works well for low end hardware and doesn’t demand much from the hardware or API.
WebGPU supports Shader Model 4.5 and has no problem with deferred or forward+.
With WebGL, because of the technical limitations (use of other function in SM 4.5, not compute), deferred will likely fall back to Forward for WebGL. I say likely because I haven’t gone in and looked at what it’s doing with WebGL yet, and I’m sometimes wrong.
Forward+ does work with WebGL, with the exception that there’s currently a bug (due to a bug in Chrome) that will cause the shader to crash the page if Extra Light Shadows option is enabled in the URP renderer settings. WebGPU does not have this issue. We are working to get this resolved for WebGL.
With both WebGPU and WebGL, Forward+ does have some CPU overhead because of the web platform’s lack of burst multithreading. In my unscientific measurement, I found in general it adds about 1ms to do its tile light soring. It also shares the same 32 visible light limit as mobile platforms.
Don’t know about how good it works, but once i’ve build WebGL with Deferred instead of Forward in URP and everything seemed okay the FPS was about the same too.
Was no difference to Forward in a scene with bunch of lights (10-20? Not in the same place though, at the same vision there was like 3 at max) (except i forgot to use the postfx, but it has nothing to do with deferred i guess and will work same on return)
Ed.
It was Unity 6, btw
It probably looked the same because it was falling back to Forward when Deferred was used for WebGL.
seems like it, as i know deferred is to be able to make many lights in one place and don’t lose FPS, but i didn’t see an increase, so probably yeah. (had FPS counter script in that build)
By the way it would be nice if such fallback was for Forward+ also, as once i fell into situation with it and WebGL (just freezes but sound goes and you think problem is in something else not the renderer)
Deferred will typically take a hit on mobile platforms with their tiled memory GPUs, and transparent objects will still need to be rendered with Forward. There’s just no winning with lights, there’s a cost to be paid somewhere for them.
The freezing issue with Forward+ and WebGL is important to get sorted out, will be a priority for the near future. I was hoping Google’s ANGLE (Chrome, Edge, WebKit) could fix the problem properly, but we’ll probably need to do a work-around before they’ll be able to get to it.
yes ok, it is really the maximum realtime light limit that is painful on webGL with 16 per camera it seems. The ‘unlimited’ (Forward+) per object count seems irrelevant therefore if I am reading it correctly. But I can understand it being a shader model based restriction.