Open xue-blood opened 1 year ago
Hi,
I have looked into WebGL support already, but the unfortunate truth is that WebGL in Unity does not support compute shaders and compute shaders are a requirement for FSR2 to work. All of FSR2 is written in compute shaders, so there is no easy way around that either.
Work has been done to add compute shader support to the WebGL standard, but that work has been halted some time ago in favor of the new WebGPU standard. You can read more about that here: https://registry.khronos.org/webgl/specs/latest/2.0-compute/
Unity apparently is working on WebGPU support and whenever that gets released, I'll be sure to test it and update the README if FSR2 works with it. It's unsure when exactly that will get released though and browser support for WebGPU is also still a mixed bag, so don't hold your breath just yet. You can read more about their progress here: https://forum.unity.com/threads/how-about-webgpu.1277615/
Thank you for you work and reply. Yes I see. I find it FSR2 writen in compulete shader, so I try to rebuild it in posteffect shader. But it's too hard.
They say WebGPU support is in active development.
.We will wait for Unity to Complete.
WebGPU support is now in Early Access on the latest Unity 2023.3 alpha release: https://forum.unity.com/threads/early-access-to-the-new-webgpu-backend-in-unity-2023-3.1516621/
I gave the FSR2 project a quick look with the WebGPU graphics API enabled, but right away I'm getting shader compilation errors concerning unsupported image formats and storage classes. So we're not quite there yet, but I'll keep an eye on Unity's progress.
I had a deeper look at the WebGPU errors and I'm pretty sure I know where the problems are. Looks like WebGPU does not support RWTexture2Ds (UAVs) with anything other than a float4 argument in compute shaders. FSR uses several UAVs with float, float2 and uint32 arguments. The image format errors refer to float (R8) and float2 (RG8) texture formats, while the storage class error seems to point towards the uint32 texture format.
Unity's own Post-processing Stack V2 already had to make several changes to work around these limitations in order to support WebGPU: https://github.com/Unity-Technologies/Graphics/commit/d2eccfee9a56f764199bddb8ff30ca727c5b09f6
So it should be possible to work around these issues, however all these extra checks and fallbacks for WebGPU are going to make both the C# and HLSL code rather hacky and ugly. I'm not a fan of the idea, and in my opinion it's also a failing of Unity's WebGPU module to provide a good platform abstraction. Hopefully Unity will improve compatibility in WebGPU, or make it so that it can automatically fall back to compatible formats behind the scenes.
Oh, thanks for your attention to this. Yes, I don‘t think writing hard-check code is a good idea. WebGPU is too new, and some browsers need to open development args to enable it. And the computer shader does not work fine even on Android devices. So I prefer to make a native PC application. If the WebGPU makes a uniform rendering platform, it'll be amazing.
Some HLSL code don't support in gles3.