I hope it will bring real performance gains besides just easier API that is abstracted away in most apps. I have 2 projects using Three.js and pure WebGL: https://bad.city (multiplayer browser game engine + editor) and http://fonted.io (shader toy + fonts)
A Taste of WebGPU in Firefox
71–80 of 80 posts
Re: A Taste of WebGPU in Firefox
#72I really dislike when these articles say "works on Linux" (Reminds me of people that say "works on PC" when it actually only runs on a single OS. Some Linux setups run Xorg, others run Wayland (with the world moving towards the latter). Yet, many times these new features (especially things related to rendering!) only work on older Xorg setups, but not on Wayland. For anyone Linux users out there: these updates only w…
Re: A Taste of WebGPU in Firefox
#73I hope it will bring real performance gains besides just easier API that is abstracted away in most apps. I have 2 projects using Three.js and pure WebGL: https://bad.city (multiplayer browser game engine + editor) and http://fonted.io (shader toy + fonts)
Re: A Taste of WebGPU in Firefox
#74And of course its another way to do unique profiling of users.
Re: A Taste of WebGPU in Firefox
#75I really dislike when these articles say "works on Linux" (Reminds me of people that say "works on PC" when it actually only runs on a single OS. Some Linux setups run Xorg, others run Wayland (with the world moving towards the latter). Yet, many times these new features (especially things related to rendering!) only work on older Xorg setups, but not on Wayland. For anyone Linux users out there: these updates only w…
I don't know why it wouldn't work on Wayland. We are currently using "software" presentation, which is a CPU roundtrip, as described in the article. This means we don't depend much on the actual Linux compositor. As long as WebRender can run on it, and you have Vulkan support, WebGPU will be available. If you are having issues, please file a bug!
Re: A Taste of WebGPU in Firefox
#76Earlier quoted context omitted.
I don't know why it wouldn't work on Wayland. We are currently using "software" presentation, which is a CPU roundtrip, as described in the article. This means we don't depend much on the actual Linux compositor. As long as WebRender can run on it, and you have Vulkan support, WebGPU will be available. If you are having issues, please file a bug!
Setting `gfx.webrender.all = true` makes sites like google maps render as just plain black (eg: no image). I'll try to debug in further detail and open a bug when I have clear reproduction details.
Re: A Taste of WebGPU in Firefox
#77Re: A Taste of WebGPU in Firefox
#78I know some people coded up raytracers with glsl texture shaders, but rayracers are massive parrallel with no shared state needed algorithms (the entire scene is tiny in those examples). Would this new API enable shared state (to some extent)? For example, someone may want to solve numerically the diff equation of the liquid flow. This usually involves dealing with big lattices where parts of the lattices can be upda…
Shameless plug of my own WebGL based ray/path tracer: https://github.com/apbodnar/FSPT Compute shaders will allow for some performance wins over my current fragment shader version by being able to do a ray binning/sorting pass to shoot rays coherently allowing for better cache behavior and shared shader state.
Re: A Taste of WebGPU in Firefox
#79Earlier quoted context omitted.
> Annoyingly Firefox is lagging behind in that regard. This has not been true since quite a while. Firefox has employed sandboxing even before the multi-process work (which culminated in the Quantum branches of Fx releases that added more and more sandboxing with each release). Before that, Moz went a different way than OS level sandboxing by principal containerization (I forgot the correct term, sorry), which worked…
Thanks for the reply, you know much more about it than I do. What could an attacker do if they were able to trick the JIT into emitting evil native code?
Re: A Taste of WebGPU in Firefox
#80Earlier quoted context omitted.
Thanks for the reply, you know much more about it than I do. What could an attacker do if they were able to trick the JIT into emitting evil native code?
I would say there is no simple answer to your question. However, I am not able to give you an authoritative answer to your question anyway. If you are interested, you can start here[1] or try and ping the moz-security people [1] https://wiki.mozilla.org/Security/Sandbox